How to track Micro-Sites with Vanity URLs

Let’s be constructive again. After telling you to say “no” and indulging in some scifi-geekery, I feel it is time to go back to solid technical advice.

Let’s look at micro sites with vanity URLs.

Analysts usually treat them one of two ways:

1. as a marketing channel — concentrating on how they bring traffic / people to the main site
2. as part of the (or a) main site — integrating them just like any other page

The marketing channel approach is often used for single-page micro sites that are used in TV ads or for specific marketing campaigns, whereas the latter approach is preferred by those who think more in terms of SEO or branding.

As a developer, you need to know which way your marketer and analyst are thinking. That’ll allow you to tag the page up properly and handle the intricacies of the two approaches, specifically the second one.

Vanity URLs

Say you are responsible for abcdefg.com. Your marketing department put up this one-page micro site for a print ad under the URL weareabcdefg.com and you are supposed to track that like it’s part of the site.

Easy, you are thinking, where’s the problem?

Well, it depends.

Say you’re tracking your main site using 3^rd-party cookies (i.e. the tracking URL is on 2o7.net or omtrdc.net) — you are lucky and you can just tag the page like any other on your site.

But if you are tracking using 1^st-party cookies (i.e. your tracking URLs are on something like metrics.abcdefg.com), you will have to do some work.

Two issues:

• If you use the same tracking on the micro site, the tracking cookies will be 3^rd-party just on the micro site. That means some users will not accept them, which in turns rips their visits apart: they are one visitor on their first touch on weareabcdefg.com and another on all further hits on abcdefg.com.
• If instead you use standard 3^rd– or proper 1^st-party cookie tracking on the micro site, all visits will be broken up when people move over to abcdefg.com.

Ouch.

You can understand now why treating the micro site as a marketing channel is easier: in that case we do not care that much whether visits continue across the boundary, just like we don’t care for PPC or emails.

You also understand now why there is no issue if you’re tracking with 3^rd-party cookies: visitors will either accept them in which case they’ll work on both, site and micro site. Or they won’t in which case the fall back(s) will kick in on both, in the same way. Either way, the visitor ID will be the same and the visit will therefore be fine.

Handover

But what can you do if the main site is using 1^st-party cookies for tracking?

You have a couple of options:

1. Change the main site to 3^rd-party cookie tracking.
2. Ignore the issue
3. Handover visitor IDs

The first solution is likely not going to be popular with your marketer, even with recent versions of the s_code and the s_fid fall back. I think we can safely discard that option in this scenario.

Same goes for option 2.

The third option is a special solution for exactly this use case. It only works if it is practically a given that any visitor movement from micro site to main site will be via a link on weareabcdefg.com. It also means you will have to put some script on the micro site as well as the main site.

Here is what you do.

1. when the visitor clicks the link, read the visitor ID from the s_vi cookie
2. amend the URL with a parameter that carries the visitor ID
3. let the browser follow the URL
4. on the main site, before tracking it, grab the URL parameter
5. still before tracking, write an s_vi cookie containing the visitor ID
6. track the page as usual

You are basically copying the visitor ID from the s_vi cookie on weareabcdefg.com over to a new s_vi cookie on abcdefg.com via the link.

When the page on abcdefg.com is sending the tracking call, it will send the s_vi cookie in the HTTP headers, as usual, and that s_vi cookie will contain the same visitor ID that was assigned when the visitor landed on weareabcdefg.com. Sorted.

One interesting edge case: what if there is already an s_vi cookie on the main site? Should we overwrite that? Probably not a good idea — that visitor might be someone who interacted with the site a lot! We’d rather lose visit continuity here once than a long history, right? Your analyst or friendly marketer has to decide that.