Measuring visitors across multiple domains in SiteCatalyst.

Share this article

If you’re trying to measure visitors across multiple domains, you’ll be aware that it’s a bit of a challenge. But with the latest Analytics code you’ll be really happy to hear it is possible.

It’s not often that I find myself doing a technical article these days…but I thought I’d put together an ingredients list and method so that you can cook up a measurement storm in SiteCatalyst.

Ingredients.

The following core ingredients are essential to your success:

  • a couple of dashes of CNAMEs
  • one measure of the Visitor ID Service version 1.3.1+
  • one measure of AppMeasurement version 1.4.1+
  • a couple of shakes of new variables

Method.

Now you’ve got your ingredients sorted, next comes the fun bit. In order for you to see the results you’re going to need to complete each of these steps. Ready to get your hands dirty?

Step 1 – Data collection CNAME entries

Firstly, you need to have your DNS CNAME entries correctly mapped to Adobe’s tracking servers (either omtrdc.net or 2o7.net).
These should look something like:

metrics.mydomain.com.au CNAME mydomain.d1.sc.omtrdc.net

If you’re also running a site under SSL, you’ll need to have the relevant SSL certificates in place with Adobe, and you’ll need to CNAME that subdomain over as well, such as:

smetrics.mydomain.com.au CNAME mydomain.d1.sc.omtrdc.net

There’s plenty of additional help to do that within the Adobe help docs. However, using CNAMEs is crucial to this solution.

If you’ve got a 3-part domain (mydomain.com.au) you’ll also need to set visitor.cookieDomain to configure where the cookie is set. This needs to change depending upon which domains the visitor is on. For example if they’re on www.mydomain.com.au and then they jump over to www.myotherdomain.com.au then you’ll need to use something similar to the following to switch the cookie domain values:

if(location.host.match('mydomain.com.au')){
 visitor.cookieDomain = "mydomain.com.au";
}else if(location.host.match('myotherdomain.com.au')){ 
 visitor.cookieDomain = "myotherdomain.com.au";
}

Step 2 – Update your Visitor ID Service code

The next thing you have to do is update your Visitor Service code to the latest version, 1.3.1.  You can download the latest versions from your code manager inside the Admin console.  As always, be sure to test the upgrade before just publishing it out.  With DTM, that’s really easy to do – you don’t even need to approve the change – just save it, use your DTM Switcher to switch over to Staging and view your site.

Step 3 – Update your AppMeasurement code

You also need to update your AppMeasurement code to the latest version 1.4.1.  Again this can be sourced from the code manager.  Again, test it.

One thing that we noticed with this version was the new HTTP POST capability…and this threw us enough to roll it back…before we published it again.  We thought we’d broken something…turns out it was a feature not a bug.

ADOBE on the new HTTP POST capability:

AppMeasurement for JavaScript and Flash now send image requests using POST in some circumstances to avoid request truncation that occurs at 2000 bytes in some browsers. After this update, Internet Explorer 8+ will no longer truncate request data at 2000 bytes, reducing errors and data loss for some variables. For example, if the browser is Internet Explorer 9 and the image URL is 1900 bytes, then the request is sent using HTTP GET. If it is 2100 bytes, the request is sent using HTTP POST.

Note that the Adobe Debugger does not inspect hits sent using HTTP POST. If the Adobe Debugger doesn’t show data in Internet Explorer, use a packet analyzer or the built-in network tools to examine the network traffic directly, or inspect the hit in a browser that does not truncate URLs, such as Chrome or Firefox.

This functionality requires AppMeasurement for JavaScript 1.4.1+ and the visitor ID service 1.3.2+.  

To get your image requests smaller, use Dynamic Variables (D=c1 etc) which can dramatically reduce your request size.

Anyway…now you’ve done that…

Step 4 – Add a couple of new variables

You’re going to need to set a couple of additional things – but only do this if you are using CNAMEs:

var visitor = new Visitor("yourmarketingcloudID@AdobeOrg")
// Normal Servers
visitor.trackingServer = "metrics.mydomain.com.au" 
visitor.marketingCloudServer = "metrics.mydomain.com.au";
// Secure Servers
visitor.trackingServerSecure = "smetrics.mydomain.com.au" 
visitor.marketingCloudServerSecure = "smetrics.mydomain.com.au";

Notice the new visitor.marketingCloudServer…?  This is required if you’re using CNAME’s.  These should be the same as your tracking servers, which should be a subdomain of your Top Level Domain.  Don’t worry about your other domain (myotherdomain.com.au) at the moment.

Alright, so that’s pretty much it. Got it?

It’s just these 4 things:

  1. CNAME
  2. Visitor Service
  3. AppMeasurement
  4. visitor.marketingCloudServer

Well done you can sit back and enjoy the fruits of your labour…well not quite, now it’s time for the fun part of testing to begin.

What does all this do?

Ok, so your visitors land on the main site (mymainsite.com.au) and the cookie is set as a First Party cookie. This is first party because of the Visitor Service. Now jump over to your other site (myotherdomain.com.au).  If everything is set up correctly, your Visitor ID will be the same across both sites, even if your browser is set to decline 3rd Party Cookies.

Multi domain visitor tracking

 

The above example can be found on our site at http://www.digitalbalance.com.au/multidomain.htm

The reason that this happens is because you’re using First Party Cookies in a Third Party context – and the browsers (including Safari) allow it. So if the visitor lands on the main site first, and the First Party Cookie is set, and then they go to the second site, the first party cookie is used in a Third Party context and still accepted by the browser – meaning you get the same Visitor ID across both domains.  Adobe explains it a lot better than me though.

A strategy for big brands?

Another trend emerging is the move to branded subdomains and country directories. Disney and Gap have recognised how important it is to understand the full customer journey across all brands, and now use subdomains for their brands:

  • http://www.gap.com
  • http://oldnavy.gap.com
  • http://bananarepublic.gap.com

This clearly took a brave new digital marketer and brand marketer to come together and realise the value and importance of this change. To whoever you were, well done!!!


Share this article