Two Steps to Correctly Tracking Subdomains in Google Analytics

/

subdomain-tracking
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 checkout.example.com.

This blog post will focus only on subdomains that share a root domain, like shop.example.com and checkout.example.com. If you have multiple root domains, like www.example.com and www.widgets.com, then you should check out our posts on cross-domain tracking.

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 the recommended JavaScript snippet that Google Analytics provides you, this is already set for you!

Google Analytics Tracking Code

If you use Google Tag Manager, you have to add this yourself to your Google Analytics tag.

gtm-auto

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.

Referral Exclusion List

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:

  1. User arrives at: http://www.example.com/
  2. Clicks to learn more about widgets: http://www.example.com/widgets
  3. Wants to know more about Widget 1: http://widget1.example.com/info
  4. How much does it cost? http://widget1.example.com/pricing
  5. Lets go back to all widgets: http://www.example.com/widget

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

Subdomain Google Analytics Example

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.

Logan Gordon is an Analytics Engineer with seven years of experience in Web Analytics, where he has helped many companies become more data-driven organized. He drove to Pittsburgh from California, and is making up for not playing in the snow as a kid. His interests include Bulgarian language (due to his wife), cooking, Bulgarian cooking, and science fiction. His only pet is Bob, a dead shark in a jar.

  • Stephen M. Harris

    Thanks for this superb breakdown!

    I’d also recommend a third step: Use a GA Filter to prepend the hostname to the request uri, so different pages that have the same url path on different subdomains do not appear as the same page in GA. Optional, but generally a good idea when tracking multiple domains/subdomains to a single Property.
    Custom Advanced Filter config:
    Field A > Hostname > (.*)
    Field B > Request URI > (.*)
    Output > Request URI > $A1$B1

  • urbanphotogeek

    I’ve set the referral exclusion list as well as cookieDomain=auto but it GA keeps showing source=(direct). Is there a step that I’m missing? Root domain and sub domains are using the same UA ID

    • http://webstrategist.co.za/ Wiehan Britz

      I also find the same problem even after following many different tutorials on how to set cross-domain and sub-domain tracking. I can’t seem to keep the original source to track throughout the user flow. Also tested using custom URL parameters. Let me know when you’ve found a solution to the problem.

      • johnnytodero

        I am having this exact same issue of not being able to get the original source for conversion tracking. It is showing up as direct when the original visit to the subdomain was Adwords. Hoping someone has a solution to this.

  • http://webstrategist.co.za/ Wiehan Britz

    The article comes at the perfect time (so thanks for the write-up) since I’m busy working on a GA-cleanup.

    My scenario:

    Domain 1: example.com
    The user starts his/her session on example.com and register/login on secure.example.com.

    Domain 2: example.com.au
    The user starts his/her session on example.com.au and register/login on secure.example.com

    So, the user flow takes place across three areas: example.com, example.com.au and secure.example.com.

    I’m thinking the fact that we are driving different users from source (.com and .com.au) to the destination (secure.example.com) is not the best strategy.

    How would I go about setting up effective tracking for the above scenario?

    Cheers and thanks a lot once again

    • Logan Gordon

      Because example.com and example.com.au are on different root domains, you will need cross-domain tracking in addition to cross-subdomain tracking. We have another blog post about that here: http://www.lunametrics.com/blog/2015/06/16/cross-domain-tracking-with-google-tag-manager/ .

      • http://webstrategist.co.za/ Wiehan Britz

        Thanks for taking the time to reply to my question. I will try and apply it. Will also be using the real-time activity in GA as well as the Tag Assistant (by Google) recordings to track the cross-domain cookie share.

  • Ed Truman

    Good article with much needed clarification as the google help centre is misleading on this. Some further explanation on
    tracking the cross-subdomain traffic as a single session in one view, and as a referrer in another view (as mentioned above) would be helpful

    • Logan Gordon

      Unfortunately, it’s more complicated to have different session policies for two Views in the same Property. The Referral Exclusion List is a Property-level setting, so you can’t tell two Views to treat it differently.

      In order for any View to see the cross-subdomain traffic in the Acquisition report, the Referral Exclusion List for the Property must not contain the root domain. For any Views where you want to see a single session, you will need to use Filters to remove the Referrer information from each hit.

  • http://www.ganotes.com/ Maggie

    I also have a question: session gets broken between web and mobile subdomains despite having Cookie domain = auto and exclusion referral. I have two different GTM containers one for web and another for mobile. Is this the reason – different Tracker name? Do I need to set a tracker name for one of the GTM containers?

  • Mike

    Hi – probably stupid question, but in these examples, is each sub-domain being treated as a separate analytics property with its own tracking code?
    Thanks!

    • Joshua Kinney

      No, he mentioned that you’d usually want to be tracking subdomains in the same property as the domain.

  • http://www.linktorank.com/ Link To Rank

    thanks for sharing.
    http://www.linktorank.com

  • Tales Buonarotti

    For those whom be asking about which code should you use on main domain and it`s subdomains, here is another article for helping with this implementation: https://www.optimizesmart.com/cross-domain-tracking-in-universal-analytics-demystified/

    In terms of using the same code, it says: Use the Universal Analytics tracking code of the primary domain on all of the pages of the sub-domains.

    Hope I could help you.

    Thanks for the great article, Logan 🙂

  • Terrence Jennings

    This is a very informative post! Very helpful for beginners like me!

    Metrixa-Data Driven Digital Marketing | http://www.metrixa.com/

  • Shane

    Thank you for the article. What if you had a scenario where example.com and another.example.com were using two different UA ID’s, but another.example.com was excluding example.com from the Property level setting?

    Would it also be necessary to exclude another.example.com to avoid self-referrals because of the separate UA ID’s?

  • Peter Fisher

    Hi Logan – many thanks for this article. I have a question about GTM and the gaCrossDomains ‘constant’ there – as per https://support.google.com/analytics/answer/6164390?hl=en. Helping out on a three subdomain website where analytics.js is part of the Data Layer via GTM, and where this constant was set incorrectly (only two subdomains declared, one of those wrongly as well). I have corrected this as per the Google guide. I have set up a different View for each subdomain and a fourth ‘global’ one without specifying a subdomain. Can you confirm that (a) this constant is actually required and the setup is sound, and (b) that with my current configuration the ‘global’ View will have the correct visitor / session totals, because each of the subdomain Views might count the same visitor twice (or three times) if they visited the other one (or two) subdomains as part of their visit?

  • Austin

    Do you recommend updating the request URI to include the hostname too since subdomains may have the same request URI?

    ex: hostname/requesturi as page dimension

  • Natalie Winslow

    Thanks for the post. I am a little confused about this part “The same implementation should be present on all the subdomains that need to be tracked together.” For the subdomain, what would go in the cookiedomain field? I have a site with 2 subdomains and we’ve had a tough time getting proper tracking. As an example, we have domain.com, secure.domain.com and connect.domain.com. Thoughts?
    https://uploads.disquscdn.com/images/a759688e9dfe0d7da485aa17d340fc7641d1b27a4a1dd9938a6c1fed741980f7.png

    • Justin Atkinson

      Hey Natalie – I think I can help you with this one. Logan is just referring to making sure that the same GTM container script is embedded on each one of your sub-domains. The “cookieDomain” with the value of “auto” will not need to change. How Logan has it captured above is literally what should be in your “All pages” tag in GTM. From there, as Logan advised, you’ll want to make sure that the root domain is accounted for in the referral exclusion list, within the related GA property. You can validate that your implementation is working correctly by looking at the “Client ID” portion of the _ga cookie as you navigate from domain to domain. This will be the 3rd and 4th fields in the _ga cookie. You will want them to be the same as you navigate from domain to domain – if they are different, you know you need to work back through your setup to see where you may have gone wrong…here is a link to a break down of the _ga cookie in case it helps. http://stackoverflow.com/questions/16102436/what-are-the-values-in-ga-cookie.

      I hope this helps.

      -Justin

Contact Us.

LunaMetrics

24 S. 18th Street, Suite 100,
Pittsburgh, PA 15203

Follow Us

1.877.220.LUNA

1.412.381.5500

getinfo@lunametrics.com

Questions?
We'll get back to you
in ONE business day.