It could be a small business with a separate shop domain for its eCommerce store, or a sizable enterprise with a multitude of brands and websites.
Many situations call for precise tracking and analytics across multiple domains!
Cross-domain tracking plays a vital function in accurately measuring user sessions across more than one domain. It’s an essential component for analytics/dashboarding and helps tell a complete story of a user’s journey from one domain to another. Not to be confused with subdomain tracking (e.g. shop.brand.com vs www.brand.com vs brand.com), multi-domain scenarios are common – especially for large organizations, online retailers, and corporate enterprises with a portfolio of brands. But in many cases, correctly deploying cross-domain tracking can present analytics challenges.
Fortunately, there are parameters that can be put into place to effectively measure a user’s journey across those many domains. But for those of us who don’t spend every working day in Google Analytics or Tag Manager, setting up cross-domain tracking can seem like a daunting undertaking.
That’s where we come in, and that’s why we’ve assembled this guide – to simplify the process on how to install cross-domain tracking in a way that makes the most sense to you and your situation.
Table of Contents:
What’s Cross-Domain Tracking?
Setting Up Cross-Domain Tracking
Google Analytics Installation
Google Tag Manager Installation
Final Thoughts and Cross-Domain Tracking FAQs
Before we get into the how-to’s behind cross-domain tracking, let’s first cover some fundamentals and scenarios.
What’s Cross-Domain Tracking and Why’s It Important?
Sometimes simplified as “site linking,” the intention of cross-domain tracking is to unify a user session across different domains in one single duration. Without cross-domain tracking, a user who arrives at your site and later proceeds to another domain is counted as two independent users, with two separate sessions of different durations.
Cross-domain tracking gives digital marketers a clearer view of an organization’s traffic, engagement, and overall web performance. It’s most commonly used by businesses that operate a shopping cart or booking platform separate from their primary domain, or by large parent companies with multiple brands/audiences.
Accurate user tracking across more than one domain is especially useful when considering the reporting implications of paid media investments, such as Google Ads and social media ads. But it can also serve great importance for multiple domain SEO, email marketing, and content marketing.
Getting Started: How to Set Up Cross-Domain Tracking?
Google Analytics and Google Tag Manager are the two most common platforms for setting up cross-domain tracking.
This guide is intended to show you how to set up cross-domain tracking using these two industry-leading tools.
Coming soon: Cross-domain tracking guides for WordPress and Shopify. Stay tuned!
Installing Cross-Domain Tracking with Google Analytics
Depending on the stage of the project (e.g. starting new vs taking over an existing account), there are a few different routes you can take to set up cross-domain tracking in Google Analytics. We’re going to take you through some of the most common scenarios and what settings need to be in place within the Universal Analytics profile (Google Analytics 4 is a different setup.)
This example is a classic eCommerce case with two separate domains – one containing general product information and the other used for final checkout. The desired outcome is to accurately track a user’s entire journey from one website to another — like when making a purchase — and be able to attribute transactions to campaigns/landing pages, etc.
When each domain is set up as its own dedicated property
When we’re talking about different domains in Google Analytics (GA), it’s often the case that each website will be set up as its own unique property (a primary domain, and a destination domain, if you will) within the GA account.
That’s totally fine. In such cases, we recommend keeping each website as its own individual property, especially if you have meaningful historical data from each site.
Analytics screenshot of Properties drop-down selection, conveying separate properties for each domain
Our preference is creating an aggregate view, which combines the activity of both websites in one place. This approach is typically only advised when starting on brand new projects, where we would simply create just one single aggregate view and later add Segments to track individual domains.
But for this example, dedicated properties were already established for each website when we arrived to fix the Analytics account. So, our first move was to get our aggregate view established where we could then integrate/cross-track data across each domain.
A major caveat about building new aggregate views is that historic data will not be available. Sure, there are ways you can import data. But unless you have Google Analytics 360, the process can be very tedious and painful. Oftentimes setting reporting expectations (e.g. true year-over-year metrics won’t be available) is a safe bet, especially considering brands are usually not even tracking (or properly tracking) in the first place.
aggregate/master view Analytics screenshot
Steps for Creating an Aggregate Property
The creation process is the same as any other Google Analytics Universal Property (view Google’s Analytics Help for reference). The decision to also create a GA4 is completely up to the user.
Include the property tracking script on every site and every page that you want included.
Global Site Tag Code Snippet
Sample of Standard Google Analytics Universal Installation Snippet
If using ONLY Google Analytics and not planning to add the tracking script through Google Tag Manager, then the script will need to be updated to include all the domains that will be tracked. (Source – we’re using the bidirectional method as it’s easier and less likely to get messed up.)
Global site tag code, with cross domain linker text included
Sample of Google Analytics Universal Installation Snippet with Linked Domains
Establishing a aggregate view for cross-domain tracking
To get started setting up cross-domain tracking from an aggregate property, first access the Property Settings (available from the Admin link/small gear icon in the bottom left corner). From here, the Default URL field is often the biggest question. And yet, this setting is not as important as one might expect. The Default URL can simply be the primary domain of the website/property.
Here, the most important step is to ensure both domains are set as Referral Exclusions. This is done by going in the Property Admin under Tracking Info and listing each domain to the Referral Exclusions List. Doing so prevents your cross-domain traffic (or one user going from the main site to the eComm store site) from being recorded as referral traffic, which ultimately defeats the purpose of this tracking exercise.
Referral exclusions list screenshot from Google Analytics
Once we’ve set up the excluded referral domains in Google Analytics, the next step is to establish and enable dedicated views into each domain. This way, we can review and analyze the performance of each website individually, all within the aggregate view property.
There are a few different ways we can accomplish this. As mentioned above, it’s often most efficient to create one primary aggregate view when starting fresh, and segment individual domains from that view to track each website’s performance. Again, this method does not inherit any historic data.
To retain the data integrity of your property’s previous performance, the best practice is to create different views for each domain. This enables us to add filters and see data-specific information from each website.
Creating dedicated views with “traffic to the hostname” filters
In this example, this eCommerce brand that has two unique websites for specific markets, the U.S. and Canada. To track each domain separately, they’ve established dedicated views for each website/market, along with predefined filter types in place to gather “traffic to the hostname” of each domain only.
screenshot of hostname filter in Analytics
You’ll see they’ve configured the filter’s options to include only traffic to the hostname that contains the website specific to the given country. So for the Canada view named “Filtered Data – CAN Site,” this filter will only show data according to the hostname “domain.ca.” The same applies to the U.S. view which is filtered to show only traffic from the primary example.com domain as the hostname.
This is just one way to go about this, and it’s not particularly necessary or required unless you have clients who specifically ask for it. In fact, unless it’s already established, we’ll typically skip creating filtered views and instead create the separation of domain-specific tracking through Google Data Studio.
Also note when creating new views – if you have a property that’s been around for 4 years and you create a new view, that new view will not inherit the data from the previous 4 years. This is important to keep in mind when you’re looking to segment data from two separate websites AND you have accumulated substantial historic data. Creating new views may not be the best way to go.
Creating segments for cross-domain tracking
Another option for viewing different website performances individually in the Aggregate property is creating Segments within a Google Analytics property. To do so for cross-domain tracking, you can establish a condition within a given segment to capture data from a specified domain.
screenshot of creating a segment condition in Analytics
For this example, we’ve added a condition in which the hostname equals the domain we wish to track. It’s pretty simple; this condition will segment data by sessions in which users visit the specific domain.
However, Site Content data might not appear as filtered as you’d expect and can still show activity from both domains, despite this condition. This is because some users may visit both domains in one session, which does in fact fulfill the specified condition, but also includes the other visited domain in the data.
screenshot of both domains showing in Site Content in Analytics
While this method of segmentation allows us to see domain-specific data within a single property, it’s not always a clear portrayal – because we’ll still see some cross-over between both domains.
Again, this is just one method that can work fine for some situations. But it might not be the absolute best solution, especially if you’re using Data Studio for reporting. With Data Studio, we suggest custom dashboards that create this data separation. In turn, you can spend less time sorting through Analytics segments to find what you need, and instead focus on meaningful data in a more readily available format.
Creating a view filter to show all domains in Analytics
Based on the scenario above – if you noticed how both domains are showing up under the Site Content page column (rather than only the URL path which is typically displayed), then you’re already keen on what’s going on here (and yes, you’ve probably already guessed it!) It’s a simple view filter that’s set to include both domains.
This custom filter, which is aptly named “Add Full Domain Names to Analytics Reports,” uses an advanced feature that extracts the hostname and the request URI (usually the path), and combines the two to rewrite the request URI field.
screenshot of filter to show both domains in Analytics
We’ll leave a screenshot for reference, but keep in mind this filter’s implementation is slightly more advanced in technical matters. We recommend not tinkering with these settings unless you know what you’re doing or have hands-on guidance from someone who does.
This particular custom view filter is very handy for customers and clients who are going to be accessing Google Analytics and will find value in seeing the different domains very quickly and easily. For example, if you have a /pricing page URL on each domain, you might not know the exact website Analytics is showing without this filter in place.
Installing Cross-Domain Tracking with Google Tag Manager
Another alternative to using only Google Analytics for cross-domain tracking setup – and our A-1 recommended setup! – is Google Tag Manager. Think of GTM as the reliable liaison of analytics implementation, allowing you to deploy tags (code snippets or tracking pixels) that track desired events (e.g. a user going from one domain to another).
Please note that using GTM does not mean you won’t need Google Analytics. Instead, you’ll use these two products together.
Determining How Many Containers to Use
This is one of the most common questions that come up when using GTM to track multiple domains; the number of containers needed will ultimately depend on the use case.
Even when tracking analytics data to the same property, it doesn’t mean you need to have the same Tag Manager container.
With Tag Manager, having separate containers for each website is not required – but it can be used out of preference depending on the use case. Some situations that might call for dedicated containers for each website include:
tracking websites that are totally different in terms of their content and functionality (e.g. online store, a blog, and a support page),
running a wide range of paid media campaigns that need to be tracked across multiple websites, or
similarly, brands have multiple agencies running campaigns across their websites, thereby requiring different tracking pixels and possibly different access needs.
Conversely, if you’re looking to track websites that are very similar or related, then we would recommend using the same container for all of the websites. Most likely, you’ll be tracking related activities across all websites. It can also make things easier to maintain when applying changes.
Configuring GTM Tags & Variables
The next step involves configuring our variables and tags within GTM. In our example shown here, we’re establishing cross-domain tracking between two sites that support the business’s eCommerce platform. Here’s what we’ll want to look into: how the container should be set up.
The first thing we’ll need to do is create our Google Analytics variable. In Tag Manager, we’ll create this as a User-Defined Variable with “Google Analytics Settings” as the Type.
screenshot of primary Variables interface [with user-defined variables showing] in GTM
This variable should contain the same Tracking ID from the associated Google Analytics property. Just below that is the Cookie Domain, which defaults to “Auto” in Tag Manager. You’ll want to keep it that way.
screenshot of Variable Configurations showing Tracking ID and Cookie Domain in GTM
Now for the important stuff. Under More Settings, we’ll want to add a couple of Fields to Set. The first field name should be “allowLinker” set to value “True” and the next is “CookieDomain” set to “Auto.” The field names should auto-complete.
screenshot of two set fields mentioned above
Next, click the setting a bit further down for Cross-Domain Tracking. In the Auto Link Domains field, add all of the domains you wish to track, separated by commas (the spaces do not matter but can help with general readability).
screenshot of cross-domain tracking field with different domains added
Configuring Triggers to Accurately Track via GTM
Near the bottom, click References to this Variable and Firing Triggers to configure how the tag is triggering. This will open the trigger configuration, which defines what type of event or action is required for the tag to fire.
In this case, our tag is set to trigger on “Pageviews.” It can also be helpful to specify the hostname that fires the trigger, so as not to encounter any issues with ghost traffic or rogue dev environments.
screenshot of trigger configuration with page hostname shown
To summarize, our Pageviews trigger is configured to fire when our hostname contains the specific domain we’re tracking. This greatly reduces the chances of inflated data and tracking conflicts. You can also exclude elements you do not want triggering your GTM tags, such as certain sub-domains, help and support pages, or documents.
Final Thoughts and Frequently Asked Questions
While cross-domain tracking may come with its fair share of setup complexities, it’s a necessary process to accurately measure users between more than one domain. Without it, the session count will be inflated as a new referral session will trigger every time a user moves from one site to another.
To help bring clarity to some of the common concerns on this topic, below we’ve addressed a handful of the most pertinent questions that often get asked.
What are the most common problems with cross-domain tracking?
In most scenarios when there are cross-domain tracking problems present, you’ll notice that direct traffic (and conversions) is/are generally inflated. Conversely, data from other channels may appear deflated. When users hop around from site to site, instead of tracking that activity as a single session, user data is getting duplicated and registered as direct traffic.
Some of the most common problems that contribute to faulty cross-domain tracking include:
Referral Exclusion List not properly set up – the most common issue here is the same session getting counted twice (the first coming from the true source and the second being a referral from itself). Not limited to cross-domain tracking, any multi-domain tracking strategy can run the risk of traffic ‘referring itself’ and sessions being recorded inaccurately if referral exclusions are not utilized.
Collecting data with multiple Google Analytics Properties – when you track cross-domain traffic across two separate domains, it’s important that both domains are collecting data under the same Google Analytics Property. Each Property has its own unique ID, tracking configuration, and table of data. Additionally, client IDs (cookies) can’t be shared between two properties.
Client ID doesn’t track link URL parameters from one domain to another – For basic cross-domain tracking to work, the URL of the source page needs to have the GA link parameter in the URL so that GA knows that it’s the same user navigating a single session.
If you’re running into issues getting your cross-domain tracking to work, be sure that your website isn’t automatically stripping this parameter! You’ll likely need to partner with your development team to further investigate this issue.
“allowLinker” or “Auto Link Domains” values are not properly configured – Any associated target domains in Google Analytics need to have the allowLinker field configured for cross-domain tracking to work.
Does setting up cross-domain tracking cause you to lose historical data?
No. As long as you’re setting up cross-domain tracking with an existing Property (versus creating a new Property with each site being newly added), you will not lose historical data.
How can you tell if your cross-domain tracking is working?
There are a couple of simple ways you can confirm whether your cross-domain tracking is working properly.
The best way to check a cross-domain setup with Google Tag Manager is to use Tag Assistant Recordings. This tool is helpful in validating your tracking so you can ensure you’re properly collecting the data you want. When you encounter a session that crosses domains, Tag Assistant Recordings can tell you whether it worked or not.
With Google Analytics, you can use the real-time report (Real-Time > Traffic Sources) to tell if your cross-domain tracking is working. This may not always work for sites with significantly high volumes of traffic but it’s a reasonable solution for many sites.
Enter your site from organic search and open the real-time report in another window.
Click locations and filter down by the city you are in so you can watch yourself journey around the site in real-time.
Use a cross-domain link from the source domain to visit the target domain while watching in real-time (perhaps even click back and forth a couple of times).
If your medium goes from organic to direct in the report, then it’s likely you have a cross-domain tracking issue and things aren’t working the way they should. The Chrome extension WASP.inspector is a handy tool that helps confirm that a problem exists. Using the tool, view the visitor identifier, or the GA cookie ID that’s been assigned to you, and record the string of numbers.
When you navigate from the source domain to an alternative target domain, check your cookie ID again. If the string of digits does not match your original cookie ID, then it can be confirmed that you have an issue that needs further troubleshooting and fixing.
How do you QA cross-domain tracking?
Running quality assurance on your cross-domain setup will depend on whether you used Google Tag Manager or Google Analytics. While the process can be somewhat investigative, the general approach can be simplified by these steps:
Scan/crawl your site to pinpoint the cross-domain links
Ensure all cross-domain links are properly decorated
Make sure “allowLinker” is set to “True” on the receiving, target domain(s)
See that the property ID matches both the source and target domain(s)
Check Referral Exclusions List and ensure cross-domain visits are not trigger new sessions
Issues with cross-domain tracking are often unique to your situation and websites. In addition to using this guide and getting help from a professional, Google offers Analytics documentation that can be helpful in resolving issues you encounter with QA.
Can you set up cross-domain tracking when you don’t own the other domain?
Generally, no. If you do not own or have access to a target domain you wish to track, then you lack the capabilities to install the tracking code and modify it for cross-domain tracking.
However, if you’re able to work with someone who owns or has access to the target domain and they are willing to add your GTM container, then yes, it is possible to install cross-domain tracking without ownership. You will need to follow the directions mentioned above for GTM implementation and provide the code and instructions so that the individual or team you’re working with can properly install the tracking for you.