Do I need to set up cross-domain tracking in Google Analytics?

*This article is about Universal Analytics which will sunset on 1 July 2023 and be replaced with Google Analytics 4. You can find our GA4 content here.

“To cross, or not to cross? That is the question.”

Deciphering whether you need cross domain tracking in Google Analytics (GA) can be a minefield! If you’re reading this article, you’ve likely already realised that this isn’t always a simple question to answer. Many of the existing guides out there are either unnecessarily complex or woefully out-of-date, making a tricky problem trickier still!

In this post, I’m going to give you everything you need to answer this question quickly.

What are domains?

What is a domain breakdown diagram

Before we get started, it’s vital to understand the difference between sub-domains and root domains. For that matter, it’s also beneficial to have a grasp of all the components of a URL, including TLDs, eTLDs, hostnames, protocols, paths, and parameters! Study the diagram above and follow the links underneath to learn more about the specific parts you’re unsure about.

When we talk about cross domain tracking, we are referring to a user crossing from one root domain to another. By ‘root domain’, we’re referring to the eTLD+1 (or ‘effective top-level-domain plus one’), which in our case is builtvisible.com. If we were on a .co.uk, the TLD would be .uk, the effective TLD (i.e. public suffix) would be .co.uk, and our eTLD+1. would be builtvisible.co.uk.

This portion is variously referred to as the domain name, the root domain, or the eTLD+1. Doesn’t matter what you call it, as long as you understand what it is!

Subdomains sit under the root domain. Once you own your domain, you can create as many as you like. An example of a subdomain would be blog.builtvisible.com or shop.builtvisible.com.

What tracking do I need?

Now you understand the difference, you can determine what type of tracking you need by using this flowchart.

Do I need cross domain tracking flowchart

A) Cross-Domain Tracking

For a user to move from one domain to another and be recognised in GA as a single user, the client ID needs to be passed from one root domain to another. The Client ID, which is typically stored in the _ga cookie, is used to stitch all the hits together into a session. The problem arises because first party cookies cannot be shared across root domains.

So, how can we pass along the client ID as the user moves between domains? The answer: we include it in a parameter which we’ll add to the URL that a user clicks on, and tell GA to ‘listen’ for it at the other end. This process can be automated by using the Linker plugin, which will dynamically append the Client ID to the outbound URL whenever a user clicks on a link to a root-domain that has been specified by the tracking code.

Okay, so how do we enable the Linker plugin and tell GA which domains the client ID should be appended to?

The approach will differ based on whether you’re using hard-coded (i.e. snippet-based) GA or a GTM-based implementation. There are also various edge cases to consider, such as instances where you have multiple trackers running at once, or snippet-based and GTM-based running side-by-side. We won’t be exploring those today (although links to suitable tutorials are provided below). Instead, we’re going to focus on a scenario where we’re using standard GTM-based implementations of the modern Universal Analytics syntax on both sites.

First we’ll create a new variable of type Constant containing a comma-separated list of the domains which are part of our cross-domain setup. We will use this variable in our Google Analytics Settings Configuration to instruct the Linker Plugin to append the Client ID to all links to pages on these domains.

It’s also important to remember that specifying a domain in this list will mean the client ID is appended not just to links to that hostname, but to its subdomains too. To enable the plugin for a specific subdomain (e.g. myshop.external.co.uk rather than external.co.uk), enter the subdomain in this list rather than the root domain.

Next, open your Google Analytics Settings variable. Ensure that your Cookie Domain is set to auto (see Point D for more on why). Then head to Cross Domain Tracking, and set the Auto Links Domains field to use your new variable. Then open Fields to Set and add a new field called allowLinker and set it to true.

Once you’ve tested and published your changes, the Linker Plugin will be active and should start appending the Client ID as a parameter to all links to pages on the domains specified in your Auto Link Domains variable.

As I said before, these steps only apply to what we might call ‘typical’ setups. Crosss-domain tracking is complex and error-prone, and thorough testing is required for a robust setup. If you’re firing hits to multiple GA properties (e.g. a rollup property with cross-domain tracking and a individual site-specific properties), you’ll need to take extra care. It’s very easy to accidentally set the Linker plugin to overwrite an existing client ID, so in this instance you’d need change your cookie name so that each different property is using a different name. Simo Ahava has a great blog post on how to do this.

It’s also worth noting that WebKit (the browser engine which powers Safari) has recently announced Intelligent Tracking Prevention (ITP) 2.1, which is going to impact all forms of cross-domain tracking in the very near future. Our Head of Analytics Tom Bennet has written up a great post exploring what ITP 2.1 means for digital analytics platforms, and how to minimise the impact this is going to have on your tracking.

Now you have set-up your cross-domain tracking in your code, it’s vital that you finish the job by enabling it within your GA property too. To do this, you will need to go to the next adventure: “B. The Referral Exclusion List!”

B) Referral Exclusion List

Whether you have arrived at this section from point A or D, or landed here straight from the flowchart, welcome to the end of your journey!

The referral exclusion list is used by Google Analytics to determine which domains you don’t want to count as referral traffic. Contrary to widespread misconception (and its somewhat misleading name!), the referral exclusion list doesn’t actually exclude anything, per se. Hits following a referral from a domain on the list will still be processed and included in your reports. All the list does is ensure that when a user arrives via a domain on the list, it doesn’t trigger a new session (as per normal processing rules). If there’s an existing session, it will simply continue where it left off, and if there isn’t, it will be bucketed as Direct traffic.

By default, the domain you enter when setting up the property (i.e. your own) is included in the list. You can add and check these in the Admin section.

referral exclusion

Referral exclusions are critical for cross-domain situations, even if you’re not actually tracking the user on the secondary domain (such as a third-party payment provider). If the user returns to the first domain, then it’s important that the secondary domain is not treated as a referral; we want GA to continue processing hits as if they never left, preserving the original source/medium. In full cross-domain tracking setups, where we track the user across both domains, it’s likewise important that a new session is not triggered when the user moves between sites.

It’s important for subdomain tracking too. If your own domain isn’t present in the referral exclusion list, then moving between subdomains will trigger a new session.

One final note: given that the Page dimension in GA only includes the path, and not the hostname / domain, you might want to set up an advanced filter to prepend the hostname to the URI. Just remember that this will not take effect retroactively, and so both versions of URLs will appear in your reports. You might want to consider setting up a new view.

C) External Click-out Tracking

When there is no possibility/need to track users on another domain, there is still the option to measure click outs. For many sites, measuring the points at which users leave your site can be as insightful as tracking the sources via which they enter it.

The easiest way to do this is using GTM. I’m going to assume you’re not a novice, so rather than giving you detailed step-by-step, I’ll arm you with the trigger and the variable you’ll need to complete this task yourself: the ‘Click URL Hostname’ variable and the ‘Outbound Link Click’ trigger.

First, our variable. We need a variable which returns the hostname of the link which has been clicked, so we can test whether it’s an external page or not. To do this, configure a variable like so:

clickurl

Note that we’re inputting the built-in Click URL variable (under URL Source) and outputting the hostname with ‘www’ stripped out. We can then feed this variable into our trigger as a firing condition, like so:

outbound

This Link Click trigger is enabled on all pages (you can narrow it down to just a specific site section if you wish) and is set to fire when the Click URL Hostname – our new variable – doesn’t match our own hostname. All you need to do is create a GA event tag and set this new trigger to fire it. Easy!

D) Cross-Subdomain Tracking

As discussed in section A, the main challenge for cross-domain tracking arises because the cookie which contains the client ID (used to identify users) cannot be shared between root domains. It can, however, be shared between your subdomains.

There are only two things needed for subdomain tracking to work: first, the cookieDomain field on your tracker must set to ‘auto’, and second, you must exclude your own root domain in the Admin area (see point B).  The reasons are simple: by setting cookieDomain to auto, you’re instructing analytics to drop the cookie on the highest-level domain it can (i.e. the eTLD + 1), rather than the current hostname (for example, on builtvisible.com rather than www.builtvisible.com, blog.builtvisible.com, or help.clients.builtvisible.com). The referral exclusion list simply ensures that users moving between hostnames don’t trigger a new session to begin.

If you are using Universal Analytics (i.e. the modern GA syntax) and have hardcoded your tracking code, then by default the cookieDomain field should be set to auto. To check this, look at the page source and look for the following line:

ga(‘create’, ‘UA-XXXXX-Y’, ‘auto‘);

If you’re using GTM, you need to check the Google Analytics settings of your tags. If you’re using a modern settings variable – which you should be, since it ensures a nice tidy single-source-of-truth for your tracker settings – make sure that the cookieDomain field is configured as follows:

Next, you just need to configure your Referral Exclusion List. Head to point B to continue your journey.

FAQ

What happens if I don’t set up cross domain tracking but have the same tracking code on 2 sites?

Without cross domain tracking you will inflate the session count, since a new referral session will be triggered every time a user moves between the two sites. If you set up the referral exclusion list, you’ll likely see high levels of direct traffic and an artificially high user count.

What about if I want to track users from an iframe?

The Linker plugin is slightly different when it comes to tracking users interacting with an iframe within a webpage. Check the advice on Google Developers here.

Is there a report in Google Analytics that breaks down the different domains from which my property is receiving hits?

There is! Head to Audience > Technology > Network and set the primary dimension to Hostname.

How can I get the Page dimension to include the domain in Google Analytics?

This can be done with an advanced filter to prepend the hostname to the URI. Just remember that this will not take effect retroactively, and so both versions of URLs will appear in your reports. You might want to consider setting up a new view.

If you get stuck or have any questions, please don’t hesitate to get in touch with the team!

Join the Inner Circle

Industry leading insights direct to your inbox every month.