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, GA4 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.
Before we get into the how-to’s behind cross-domain tracking, let’s first cover some fundamentals and scenarios.
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.
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.
Cross-domain tracking in GA4 is relatively simple compared to Universal Analytics. That’s because it’s all configured within GA4.
To set things up, the same GA4 property should be installed on both sites, whether directly (gtag) or via GTM. From here, it’s a breeze.
Step one — Navigate to Admin > Google Analytics > Data Streams and select your primary data stream.
Step two — In the Google Tag menu, choose Configure Tag Settings.
Step three — In the Settings menu, choose Configure Your Domains.
Step four — Add any relevant domains using conditions, all of which are “or” statements (vs. “and” statements).
GA4 handles cross-domain tracking by passing a URL parameter. So once it’s set up, you should see _gl appended to the URL when clicking from one domain to another. If not, Google has some suggestions for common issues with cross-domain tracking.
Note: No need to mess with the referral exclusion list, because GA will handle it automatically. Although, you can set up unwanted referrals if you’d like to see the other domains as traffic sources.
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 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.
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.
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.
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.
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.
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 Looker 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.
Another option for viewing different website performance 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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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).
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.
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.
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.
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:
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.
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.
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.
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:
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.
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.
While sometimes a hurdle to implement, cross-domain tracking is often a necessary mechanism to collect relevant, precise, and meaningful data that informs strategic decision-making. For brands, enterprises, eCommerce sites, and other organizations with multi-domain tracking scenarios, tracking cross-domain links is an integral component to data storytelling and ensuring an accurate analytics dashboard.
For more support and guidance on this topic, contact our team to see how we can help.