Two Steps To Correctly Tracking Subdomains In Google Analytics
Editor's Notes: Google has announced that all Universal Analytics properties must migrate to Google Analytics 4 by July 2023.
Subdomains are a common fact of life on the web, and that means they’re a common fact of life in web analytics. Unfortunately, Google Analytics has a few hoops to jump through in order to track sessions across subdomains on the same domain. More unfortunately, the Google Analytics documentation is unclear on what hoops you need to jump through. If you have subdomains, it’s possible that you are tracking them correctly, but there are several reasons why your implementation may be less correct than you thought.
Review: What Is a Subdomain and How Should I Track It
If you have a webpage whose URL is www.example.com, then example.com is the “root domain” or “parent domain,” and www.example.com is a “subdomain” of example.com. A single root domain can have any number of subdomains (even zero!), and website owners can use them however they want.
Most of the time, if a user moves from one subdomain to another on the same root domain, you would want to view their behavior as a single session in Google Analytics. This allows you to easily connect interactions that take place on the two different subdomains. For example, it allows you to credit a product promotion on
shop.example.com with an ecommerce transaction on
This blog post will focus only on subdomains that share a root domain, like
checkout.example.com. If you have multiple root domains, like
www.widgets.com, then you should check out our posts on cross-domain tracking.
Published: August 1, 2016
How to Properly Implement Subdomain Tracking
There are two required steps to track a user across subdomains as a single session in Universal Analytics (these steps are different than Classic Google Analytics). One setting causes hits from different subdomains to properly be credited to the same user, and the other setting causes those hits to be processed as part of the same session.
There are two steps: 1) Set the Cookie Domain and 2) Update Your Referral Exclusion List.
Step 1: Set the Cookie Domain
On-page, set the Cookie Domain to ‘auto.’ This is the default setting for Universal Analytics, but must be explicitly set when implementing with Google Tag Manager. This allows hits from all subdomains to share the same first-party cookie, which allows Google Analytics to tell that they came from the same user.
If you use Google Tag Manager, you have to add this yourself to your Google Analytics tag.
(Update: We highly recommend using a Google Analytics Settings variable, which now has this value set by default!)
Published: May 18, 2017
The same implementation should be present on all the subdomains that need to be tracked together.
Step 2: Update Your Referral Exclusion List
In the Admin Panel, the root domain must be added to the Referral Exclusion List. This is probably already set up correctly, but it’s worth double-checking.
Let me explain why this matters. When the user moves from one domain to another (including subdomains of the same domain), the Universal Analytics code will send referrer information to Google Analytics. When Google Analytics sees a new referrer that is different from original source/medium information, it will start a new session with the new traffic source information. The Referral Exclusion List prevents this from happening and will let the original session continue.
Let’s See It in Action
Suppose we have a visitor flow that looks like the following:
- User arrives at:
- Clicks to learn more about widgets:
- Wants to know more about Widget 1:
- How much does it cost?
- Lets go back to all widgets:
Scenario One: Cookie Domain not set to auto, no referral exclusions – 2 Users, 3 Sessions
Scenario Two: Cookie Domain set to auto, no referral exclusions – 1 Users, 3 Sessions
Scenario Three: Cookie Domain set to auto,
example.com set as referral exclusions – 1 Users, 1 Session
Why You May Not Have Implemented Subdomain Tracking
Many references to subdomain tracking only mention the first step listed above, setting the cookie domain. These sources do not mention the Referral Exclusion List.
The Google Developer site for Google Analytics has very few references to subdomains. A search for “subdomains” points you to documentation for cross-domain tracking, and cookie domains. The former makes no mention of sessions or subdomains. The latter describes tracking users across subdomains, but makes no mention of connecting sessions across subdomains. It also highlights the following quote:
When using automatic cookie domain configuration, your users will be tracked across subdomains without any extra configuration.
While technically true (it only mentions “users,” not “sessions”), this statement is misleading because extra configuration is needed to track sessions across subdomains, which is a common goal. The subheading on self-referrals mentions the referral behavior of analytics.js, but requires a close reading to determine whether it applies to subdomains, or only root domains.
The Analytics Help site is similarly uninformative about subdomain tracking. A search for “subdomain” yields no information about the Referral Exclusion List until the fourth search result. Meanwhile, the first result on Common uses for cross-domain tracking highlights the following quote:
If you have updated your tracking code to analytics.js, then no additional configuration is required to track subdomains.
Only in the support page for the Referral Exclusion List does it explicitly state the configuration needed to track sessions across subdomains. No other easily-accessible official documentation states the need for this piece of configuration, or points towards the documentation that does.
Here is the official information labeled under “Cross-Subdomain Tracking.”
When your domain is in the exclusion list, then users can cross from one subdomain on your site to another without starting a new session. Without your domain in the exclusion list, when a user goes from one subdomain to another on your site, Analytics sees that as a referral from one hostname to another and starts a new session. As a result, your reports can have artificially inflated session counts.
Why You May Have Correctly Implemented Subdomain Tracking
By default, the Referral Exclusion List is pre-populated with the domain that you gave Google Analytics when you first created your property. This means that the majority of Google Analytics users will have their Referral Exclusion List configured properly for subdomain tracking, even if they didn’t realize the need.
There are four common reasons why something may be missing from your Referral Exclusion List:
- You have multiple domains. Google Analytics only lets you enter one domain when creating a property, and only populates the Referral Exclusion List with that one domain. Any domains beyond the first being tracked in the same property must be added manually.
- The original domain that you gave Google Analytics is not correct. This can happen if your website has moved to a new domain since your Google Analytics property was set up.
- You migrated your property manually from Classic to Universal, and did not updated the Referral Exclusion List. Automatic migrations had their Referral Exclusion List updated automatically, but manual migrations did not.
- You intentionally removed the entry from the Referral Exclusion List, because you want your data to include self-referrals. For example, if you want to view your subdomains both combined and split apart, you will probably have subdomain-specific views where you want to include cross-subdomain referrals.
What to Do Next
In most cases, the fix for this issue is simple: Check the Referral Exclusion List in your Google Analytics property, and makes sure that it includes all of the domains where you want to track cross-subdomain traffic as a single session. This will only affect data after the change is made; for better or worse, historical data cannot be updated.
If you have a particular scenario where you want to track the cross-subdomain traffic as a single session in one view, and as a referrer in another view, then there’s a special solution just for you. Because the Referral Exclusion List is a property setting, the view that combines subdomains will also receive the referrer information, breaking sessions. In this case, the root domain must be absent from the Referral Exclusion List, and the referrer information must be removed with a Filter on the combined view.