Google Analytics Cross Domain Tracking

Google Analytics cross domain tracking can be confusing and frustrating.

It’s relatively straightforward to install your tracking code, set up some goals, and look at basic reports. Things get pretty unruly, however, when you have a couple different web properties you need to track.

Google Analytics cross domain tracking could be necessary for a variety of reasons (we’ll get into them below), or you may just need to set up subdomain tracking (easier, but still often an issue with implementation).

This article will cover what cross domain tracking actually is, when you would need it and why, and then how to set it up. We’ll also cover some common mistakes in implementing Google Analytics cross domain tracking.

Google Analytics cross domain tracking exists so you can see sessions on two related sites. Often, this will set up to tie together data from an ecommerce site and a shopping cart site, but it can be used for any related domains that you own. Sometimes, this is also called sitelinking.

So, let’s say you have two domains, example.com and mysite.com. Both are related and you’d like to track the user experience across both of them. Going with a common case, like I mentioned above, maybe one is a shopping cart and one is your actual ecommerce site. Or perhaps, one is a mini-site and you’d like to track purchases to the actual store. Whatever the case, this is what you’ve got with a normal Google Analytics setup -- two separate properties:

Cross domain tracking, or site linking, is when you rope them together and you can view the Google Analytics reports for both of them in a holistic way. It would look more like this:

With a normal setup (picture one), you’d record all traffic to your site and subdirectories (e.g. example.com/blog or example.com/shop) as a group. In this way, your analytics reports show relationships between this set of pages and will record things like navigation paths between pages, total time on site, unique users, and unique sessions.

In general, and for a large part of use cases, that’s sufficient and the right way to do things. You wouldn’t necessarily want data from an unrelated website to show up in your analytics reports. For instance, if you had a personal website and an ecommerce store, maybe you wouldn’t want them together in the same analytics report.

The most common use case for cross domain tracking is with ecommerce platforms. Let’s say you’ve got mystore.com as your main site, but you use an ecommerce shopping cart that brings you to ecommercehost.com/mysite to check out items. In that case, cross domain tracking becomes imperative. Otherwise, you’d lose essential user behavior data.

And to complicate things further, what if you have a blog that sits on blog.mysite.com? Well, in that case, you need subdomain tracking, and your setup would look something like this:

Let’s quickly cover subdomain tracking.

Subdomain tracking is a little bit different, and it’s much more straightforward to set up. In the example above, I said if you had an ecommerce site (mystore.com) and a different shopping cart domain (ecommercehot.com/mysite), you’d need to set up cross domain tracking. But what if, SEO concerns aside, you had a blog that sits on blog.mysite.com? Or a knowledge base that sits on support.mysite.com?

That’s where subdomain tracking comes in.

Follow me here for an example from 3dcart.com. Pretend you’ve landed (via a Google search) on their knowledge base (support.3dcart.com), but you’ve found your answer and now you want to head back over to their main site to log in. Your experience is connected, and should be reflected by analytics that way:

Without getting too in the weeds, a quick tutorial on subdomain tracking.

There are two steps:

• Set the cookieDomain.
• Update your Referral Exclusion list.

In Google Tag Manager, the first step is quite simple. You just need to set the following field:

Then, go to your Google Analytics Admin section and find the referral exclusions under tracking info:

Then, just make sure your root domain is excluded.

Finally, it’s probable that you’ll want a separate View in Google Analytics to report on data from your subdomain, so you can set up a new View with a filter to do that. Here’s a great guide from Vertical Rail on how to do that, specifically (and we’ll also do a short walkthrough on hostnames and filters later in the article).

Okay, that’s a quick primer and brushed over a bit of nuance. More info. can be found on these great blog posts:

• Two Steps to Correctly Tracking Subdomains in Google Analytics (LunaMetrics)
• Cross-domain Tracking Across Subdomains (Simo Ahava)
• Cookie Settings And Subdomain Tracking In Universal Analytics (Simo Ahava)

Now, before we dive into how to set up Google Analytics cross domain tracking (for separate domains), let’s walk through the benefits and see if you actually need to do it.

First off, let’s cover whether you, in your specific context, even need or will need cross domain tracking. If you don’t need to worry about it, you can just go on auditing and analyzing your data, oblivious and free from the troubles of cross domain implementations.

Since cross domain tracking is implemented for the purpose of centralizing data from multiple domains, you can ask a few questions to see if you actually need to set it up. First, obviously, do you have more than one domain? If not, you don’t need cross domain tracking.

Next, ask yourself if users will generally have a connected experience across multiple domains (also, ask yourself if you’re using the same GA code on the domains in question). For instance, a user on an ecommerce site will necessarily use your shopping cart application to convert, so you’d want to connect those data sources to view a single session.

The domains needn’t be simply conversion related sites, either. From the perspective of cross domain tracking, site.com and site.org are two separate domains. So, also ask yourself if users may be hopping back and forth between sites.

Spotify has a few campaigns that use microsites, and while they don’t use cross domain tracking (they use UTM parameters, which is almost certainly the best practice in their case), they probably could use cross domain tracking if they wanted to. For example, with their 2017 Wrapped campaign:

The short answer here: if you have the same tracking code installed on multiple domains and you’d like to track a single user as they visit those domains, you need cross domain tracking.

Centralization of data is important. Analysts and marketers are always talking about getting a “single view” of the customer (however idyllic and impossible that may be)--and the more fractured your data sources are, the less holistic your marketing data will be. Cross domain tracking is one of many ways to tie together your marketing data in a way that creates a more holistic picture.

Let’s set up a semi-hypothetical situation to serve as a step-by-step walkthrough.

Say, I have a main website, alexbirkett.com. The vast majority of user activity happens here, to the tune of millions of visits a month (of course).

But let’s say that, for some reason, users can only do their purchasing on a subdomain, get.alexbirkett.com. We already walked through how to set up subdomain tracking above, so all is good so far.

Now, let’s say that for some odd reason, I decide to build a campaign to acquire users that enjoying traveling and partying, mostly at the same time. For this reason, I buy rowdytraver.com and start decorating the site with decadent guides on debauchery abroad.

Let’s venture further to pretend that, somehow, the user journey will overlap substantially between those landing on rowdytraveler.com and alexbirkett.com (and, hopefully, later get.alexbirkett.com). It’s part of a conversion path, and we’re obligated to reflect that in our data collection.

You know what that means: we need to set up Google Analytics cross domain tracking.

Like subdomain tracking, cross domain tracking is somewhat simple in theory, yet often contains a bit more nuance in specific scenarios.

Here’s the gist of the technical challenge: Google Analytics collects a Client-ID value in every hit, which are stored in cookies. Cookies are stored on a per-domain basis, and websites on one domain can’t access cookies set on another domain.

But when you’re tracking multiple domains, you have to transfer the Client-ID value from one domain to another. To accomplish this, Google Analytics has a linking feature that lets the source domain place the Client-ID in the URL parameters of a link, where the destination domain can access it.

We’ll walk through a real example here--but generally, here’s the process for cross domain tracking:

• Modify your tracking code.
• Set up referral exclusions.

Looks familiar, yeah?

Before we start, I want to recommend implementing this via Google Tag Manager. Things are much easier to control and update there. But if you’re hard coding GA on your site, here’s how you set things up.

• Set up one property in your Analytics account. You’ll use the same tracking code and ID for all your domains (get.alexbirkett.com, alexbirkett.com and rowdytraveler.com).

• Edit your tracking code snippet. You’ll need to add a few lines of code. Find the “create” line, that looks like this:

  ga('create', 'UA-XXXXXXX-X', 'example-1.com');Then, create the following changes (additions in red):

  ga('create', 'UA-XXXXXXX-X', 'auto', {'allowLinker': true});

  ga('require', 'linker');

  ga('linker:autoLink', ['site2.com'] );

  Of course, you’ll use your own Tracking ID and domains in your own implementation.

  This is the code you’ll put on your first domain. You can add that to your site now (instructional video on how to do that here).

• Now, do the same thing for the tracking code on your second domain, except replace the domain in the code (use site1.com instead of site2.com).

  ga('create', 'UA-XXXXXXX-X', 'auto', {'allowLinker': true});ga('require', 'linker');

  ga('linker:autoLink', ['site1.com'] );

• Set up referral exclusions and filtered views. We’ll cover these two things later, because they both apply to Google Tag Manager setup as well.

Now, here’s how to set up Google Analytics cross domain tracking in Google Tag Manager. All of this does assume you’ve already set up your Google Analytics account and placed your tracking code (same Tracking ID) on all domains you want to use for cross domain tracking. Once that’s done, enter Google Tag Manager and take the following steps...

First, we’re going to set up a Variable in Google Tag Manager.

You’ll want to select a Constant Variable from the allowed list of Variables.

Then, write in the domains you’d like to link in your setup. Separate them with commas:

The next part is simple, you’re just going to add the variable to the Pageview tag you’ve set up on your property.

Find the “Cross Domain Tracking” menu underneath the “More Settings” dropdown menu. Place your Constant Variable in the “Auto Link Domains” field.

Set the allowLinker field to “true”.

Stay where you are in Google Tag Manager and find “Fields to Set” just underneath “More Setting.” Set the Field Name to “allowLinker” and set the Value to “true.”

This step is now applicable both for the Google Tag Manager setup as well as the hard coded version we reviewed earlier. We’re all caught up and on the same page now.

This part is super important--because if you don’t set up exclusions, you’ll get “self-referrals,” or basically a bunch of duplicate sessions when users jump back and forth between your properties.

As with subdomain tracking, you’ll first need to jump into your Admin section of your Google Analytics account and find the “Referral Exclusion List” underneath “Tracking Info.”

Now, just add applicable domains to your exclusion list. In our case, I’m adding alexbirkett.com and rowdytraveler.com:

Before you pop champagne and celebrate your setup, you need to audit it to make sure it’s set up correctly. Boring, maybe, but necessary.

The best way to do this is with the Google Analytics Debugger Chrome extension. Install that if you haven’t already, and head over to your first domain (alexbirkett.com, in my case). Fire up the console and note your client ID and tracking ID.

Then, navigate to your second domain (rowdytraveler.com for me). Do the client IDs match? In this case, we’ve got a match:

Finally, might as well check our subdomain (get.alexbirkett.com) out. Client ID and Tracking ID match? Yep.

Good to go.

Another high level way to audit your setup is to navigate from one domain to another and look at the URL. It should include a new parameter to transfer the clientID. Here’s how Johannes Mehlem, Senior Web Analyst at HubSpot, explains it:

“There is a simple way of auditing whether cross-domain tracking is set up correctly. Open the referring domain in your browser and click on a link that leads you to the other domain. Now, you can check if in the URL path of the other domain in your browser a URL parameter starting with "?_ga=" has been appended to the regular URL.

If so, you can see that a Google Analytics clientID related identifier has successfully been carried over from the referring domain and cross-domain tracking is working as intended."

If you have multiple domains tracking under the same property, you’re probably going to run into problems with reporting. Specifically, if you have two similar URLs, such as alexbirkett.com/about and rowdytraveler.com/about, they’re both going to show up in your reports as /about.

What can you do? Set up a filtered View.

This walkthrough from Annie Cushing explains really well how to set up a filter to list the full URLs in your reports. Give the article a read, because there are a few caveats and extra notes-- but this is what your filter should look like:

You may also want to set up new Views in your Google Analytics account to exclusively report on a subdomain or another domain. For instance, if you have blog.site.com, you may want a specific view for that, especially if you want to give access to people who shouldn’t see other business and financial information (freelancers, for instance).

To do this is a bit easier, I’m going to share a screenshot from a Search Engine People article. This is to set up a blog View:

And then you can separate out based on your regular domain as well. Here’s another screenshot from Search Engine People:

Setting up Views and Filters is a bit more of a strategic and organizational decision, though. So definitely have a conversation about how you should view data and who should view what data.

You can study as much as you want in analytics, but I’ve found it’s still probable you’ll run into mistakes. That’s why I like to consider the top mistakes seen by expert practitioners, and plan to avoid or mitigate those from the start.

According to Johannes Mehlem, Senior Web Analyst at HubSpot, these are the two most common mistakes:

“There are two common mistakes when setting up cross-domain tracking.

First, using exactly the same setup for tracking across distinct domains and tracking across various subdomains as the setup has to slightly differ (e.g. cookieDomain settings in Google Tag Manager).

Second, not adding the referring (sub-)domain to the Referral Exclusion List under Tracking Info of the Property settings in Google Analytics.”

According to Jeff Sauer, Founder at Jeffalytics, the biggest mistake really comes back to the fundamentals of good analytics practice: you need to have a plan.

“Most companies will set up Google Analytics without a plan. They think that the default one account getting one property getting one view is going to magically track everything properly in Analytics. They don’t understand the purpose of each of these aspects of an Analytics account, or plan for how to use them properly.

The most important decision to make when setting up an account is to consider the purpose of properties. Each property is designed to track a unique aspect of your website in a unique place. Many companies will put all website domains, subdomains and other assets into one property without thinking. Then, they wonder why their views are showing traffic across domains, reporting things incorrectly or inflating their numbers.

A simple planning exercise could eliminate the need for cross-domain tracking up front by using multiple properties to track all aspects of a site.

Cross domain tracking issues (i.e. self referrals) are the result of trusting defaults and not having a tracking plan. Fortunately, they can be resolved in future tracking if you address the problem head on.”

Following that, another common mistake is simply trusting that you’ve set things up correctly right away. Chris Mercer, founder of measurementmarketing.io, uses a phase, “trust but verify,” to explain how he approaches analytics:

“The biggest mistake and the single most crucial thing when setting up cross domain tracking falls under "trust but verify.”

That is, trust you have set it up correctly, but go back to your implementation and test it to verify you set it up incorrectly. Yep, you read that right!

When you go back to look for where you screwed things up, you're more likely to find your mistakes. Use UTM's to tag your session and go through a test purchase that takes you through your different domains. After a bit of time, look up that purchase in Google Analytics. Was the purchase attributed to the UTM's you used for the test or did it get assigned to some other (incorrect) traffic source?  

A few minutes spent "TBV'ing" (trust by verifying) can save hours of frustration later.”

The following tip isn’t regarding a mistake, but rather it’s another way to accomplish cross domain tracking. It’s called browser fingerprinting, and it’s quite a bit less common, though worth noting. Here’s how Joao Correia, Solutions Director at Igloo Analytics, explains it:

"Cross-domain tracking requires a low level of effort for implementation, and is the most reliable way to ensure channel attribution across different domains. Another technique, although less common is browser fingerprint--but it requires full data ownership, which most businesses do not have."

If you’re interested, it’s a bit more advanced, but here’s a good guide on browser fingerprinting.

Google Analytics cross domain tracking isn’t the easiest thing to do, especially if you’re new at Google Analytics. However, most of the time when you’re just starting out with Google Analytics, it may not even be necessary to set up cross domain tracking. It’s usually when a company and its website properties grow in complexity and quantity that you need to start looking into it.

So, remember, if you’re strapped for resources, the simplest route tends to be the best way. In that regard, make sure you ask yourself what kind of implementation you need to best understand your user data, and go from there.

Of course, there’s some nuance and probably some fringe cases that will slip through the grasp of this blog post--but hopefully, my walking through a semi-hypothetical travel site for those who like to party helps you understand how you’d set things up, or at least gives you a framework for approaching cross domain and subdomain tracking.