Subdomain Tracking with Google Analytics and Google Tag Manager

Note: In July 2023, Universal Analytics stops working. It is no longer recommended to do new implementations with Universal Analytics (GA3). Use Google Analytics 4 instead. GA4 also automatically handles subdomains.

If you are working with a business that operates on multiple subdomains (e.g. blog.business.com, support.business.com, www.business.com, etc.), you will most likely want to track website visitors with Google Analytics across all these websites.

If yes, what kind of configurations do you need to have a proper setup? The good news is that this is usually much easier to implement than cross-domain tracking. But nevertheless, there are several things to keep in mind.

In today’s blog post, I’ll show you how to implement subdomain tracking with Google Analytics and Google Tag Manager.

 

Table of Contents

• Before we start: Subdomains DO NOT require cross-domain tracking
• Subdomain tracking with Google Analytics and Google Tag Manager: The Short Version
• Subdomain tracking with Google Analytics and GTM: The Long Version
• It’s all about the cookie
• #1. cookieDomain parameter
  • #1.1. Universal Analytics (analytics.js)
  • #1.2. gtag.js
  • #1.3. Google Analytics via Google Tag Manager
  • #1.4. Check the actual cookie and its domain
• #2. You must use the same GA property across all subdomains
  • #2.1. What about VERY large businesses?
  • #2.2. What about the GTM container?
  • #2.3. How do you decide which subdomains should be tracked in a single GA property?
• #3. Check the referral exclusion list
• #4. Showing full URL in your GA reports
• Bonus: Create a GA view just for a particular subdomain
• Test the entire implementation
• Subdomain Tracking with Google Analytics and GTM: Final Words

Before we start: Subdomains DO NOT require cross-domain tracking

Sometimes I see forum threads or chats where people are asking how to implement cross-domain tracking for their project/websites when it turns out that the business operates on a single domain (just different subdomains).

So before we dive deeper into the actual details, here’s a public social announcement:

YOU DO NOT NEED CROSS-DOMAIN TRACKING FOR SUBDOMAINS OF THE SAME DOMAIN

If you are dealing with subdomains like:

• www.example.com
• blog.example.com
• support.example.com

Then you DO NOT need to implement cross-domain tracking because all of them belong to the same example.com domain

However, you WILL HAVE to implement cross-domain tracking if you’re working with separate domains, e.g.:

• www.mainwebsite.com
• blog.example.com
• support.someotherdomain.com

And that’s about it. Now, let’s move to the subdomain tracking with Google Analytics.

 

Subdomain tracking with Google Analytics and Google Tag Manager: THE SHORT VERSION

There are several things to check/configure (and keep in mind) while tracking subdomains with Google Analytics. Let’s start with the short version (for those who are in a hurry). If you find some tips confusing, please read the long version).

1. First, configure/check the settings of cookieDomain parameter (set it to auto). By default, Google Analytics Settings Variable in GTM already uses that.

2. Then you will need to make sure that you use the same GA tracking property across all subdomains you are interested in.

3. You will need to add your main domain to the GA referral exclusion list. Go to GA Admin > Property Column > Tracking Info > Referral Exclusion List > Add Referral Exclusion. Enter your top domain there (if it isn’t there already).

4. Finally, you will need to (optionally) implement the Show Full URL filter in the GA view. This way, you will see both the Domain and the Page Path in your reports.

Go to GA Admin > A view where you want to implement this > Filters and create the filter with the configuration displayed in the screenshot above. In the long version of this blog post, I’ll show the settings in a bit greater detail.

 

 

Subdomain tracking with Google Analytics and GTM: THE LONG VERSION

Now, let’s move on to the longer version with a thorough explanation.

 

It’s all about the cookie

Google Analytics tracking is based on first-party cookies. Whenever a visitor lands on a page, the Google Analytics tracking snippet is activated on a page that stores a cookie (called _ga) with a randomly generated ID.

When you continue browsing the website, GA keeps checking that cookie. If it exists, GA reuses the ID from that cookie and then understands that you are the same person who has just made a page view a couple of minutes ago.

If you return to the website and still have that _ga cookie, GA will continue to use that.

However, if the cookie is not present (or is not available for that particular domain (or subdomain), then a new _ga cookie will be created.

I highlighted several words in the previous sentence for a reason.

You see, it is possible to set a cookie just for a particular subdomain. In that case, only that subdomain (and subdomains of that subdomain) will be able to access the cookie. This can also apply to the _ga cookie.

Here’s an example of a cookie that is set for all .example.com. This means that any subdomain of example.com will be able to access that particular cookie.

 

However, if the _ga cookie is created only for demo.example.com, then its value can be accessed only by:

• demo.example.com
• v1.demo.example.com (or any other subdomain that is on the lower level of demo.example.com)

But www.example.com will NOT be able to access the cookie (because www and demo are different subdomains of the same level).

But don’t worry. This limitation can be easily circumvented with a setting called cookieDomain in Google Analytics.

 

#1. cookieDomain parameter

If you want to track the same user across multiple subdomains that belong to the same business, the cookieDomain parameter is exactly what you need.

If that parameter is set to auto, GA will always set the _ga cookie on the main domain, for example, if a visitor is browsing support.example.com,  then the cookie will be set on .example.com). This means that any other subdomain of example.com (e.g., www.example.com or blog.example.com) will be able to access the same cookie and reuse it for tracking.

How can you know whether cookieDomain is set to auto? The answer depends on how your Google Analytics is implemented on a site.

 

#1.1. Universal Analytics (analytics.js)

If your website is using the older version of Google Analytics tracking code (a.k.a. analytics.js), then the code snippet (that must be added to a site) might look like this (this is the default snippet):

<!-- Google Analytics -->
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','https://www.google-analytics.com/analytics.js','ga');

ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
</script>
<!-- End Google Analytics -->

Take a look at this line:

ga('create', 'UA-XXXXX-Y', 'auto');

See the “auto”? That means that the cookieDomain parameter is set to auto.

If you see it, you’re all set. This means that the _ga cookie will be set on the main domain. If instead of “auto”, you see “.maindomain.com” (obviously, this is just an example and I meant the “main domain”), then this will also work. This means that the cookie will be set on the main domain and all subdomains will be able to access it.

If, on the other hand, instead of “auto” you see an exact subdomain, like “www.example.com“, this means that a cookie will be set only on that particular subdomain and other subdomains of the same level will not be able to access it.

If you have added the analytics.js snippet a long time ago and didn’t do any modifications, most likely, your setup is ok (regarding the _ga cookie). Nevertheless, you should still check that.

 

#1.2. gtag.js

If you are using the newer version of Google Analytics tracking code (a.k.a. gtag.js), then you should be ok. By default,  gtag.js has automatic cookie domain configuration enabled. When enabled, gtag.js will set cookies on the highest level domain it can.

However, there is still a possibility to limit cookies to just a particular subdomain with a parameter called cookie_domain. Here’s an example:

gtag('config', 'GA_MEASUREMENT_ID', {
   'cookie_domain': 'blog.example.com'
});

In this case, the _ga cookie will be set on blog.example.com. If you see this, have a discussion with your webmaster/developer and ask to remove that parameter.

 

#1.3. Google Analytics via Google Tag Manager

By default, Google Analytics (implemented via GTM) DOES NOT have a cookieDomain set to auto. Meaning that if you just fire a regular pageview tag, the cookie will be set just for that particular subdomain.

However, it can be easily solved by adding a cookieDomain field set on at least one tag on a page (Pageview tag is your best bet) and setting its value to auto.

If you are using a Google Analytics Settings Variable (recommended), then you will see that the variable (most likely) already contains the cookieDomain field set to auto. That’s because every time you create a new GA Settings Variable, it contains that configuration by default.

If you are working with an older GTM/GA implementation (pre-2017), then you will definitely need to check whether cookieDomain is set to auto.

If you want to learn more about the cookieDomain settings and how different settings affect your tracking, you can read this guide by Simo. Also, feel free to check the official GA documentation here and here.

 

#1.4. Check the actual cookie and its domain

You can also go to the Developer Tools of your browser and check the domain of the _ga cookie there. I’ll show the example with Google Chrome. Go to the browser’s menu (click three vertical dots) > More Tools > Developer Tools.

Then go to Application > Cookies > Choose your website’s domain.

Finally, in the search field, enter “_ga” (without quotation marks) and you will find all the cookies with that name that are stored from your website in your browser.

In the Domain column, you will see on which domain’s (or subdomain’s) behalf was the cookie stored.

Note: you might see multiple different domains. This happens if 3rd party tools installed on your website use their own Google Analytics tracking code to track their own usage.

Back to the domain.

If you see, for example, .mydomain.com, this means that ALL subdomains of mydomain.com will be able to access that cookie. That’s what you need.

If you see www.mydomain.com, then the cookie can be accessed by the tracking code that is implemented on www.mydomain.com, dev.www.mydomain.com, and other sub-sub-domains that belong to the www.mydomain.com.

 

#2. You must use the same GA property across all subdomains

If you want to track how visitors are behaving on your online ecosystem (across multiple subdomains), you will need to use the same property for all subdomains.

It does not matter what domain or subdomain have you entered in the GA Property’s settings:

What matters is that your subdomains are sending data to the same bucket, a.k.a. property. If you want to split that traffic later (in your reports) based on a subdomain you might want to create separate GA views for each subdomain.

 

#2.1. What about VERY large businesses?

However, just like the majority of situations we do, there are some “it depends” moments.

If you are working with a huge project where there are hundreds of subdomains, 25 GA views will not be enough for you (because that’s the limit).

If you plan to have multiple subdomains as separate properties in Google Search Console and then try to connect them with your single Google Analytics property, you will hit the wall. Why? Because you can connect only one GSC property with a Google Analytics property.

At least for now, you cannot connect multiple GSC properties with a single GA property. And that’s a bummer.

What’s the solution? One of the possible things could be tracking each subdomain as a separate GA property and then also duplicating hits to another (master) GA property. That way each subdomain will be isolated but you will still have an opportunity to have a rollup view of what is happening.

Simo has written a guide on how to duplicate hits and send the info to a rollup property. Read that guide very carefully as there are multiple gotchas you need to be aware of.

#2.2. What about the GTM container?

Should you use the same for all subdomains? Or should you create different containers for each subdomain?

The answer is: it does not matter. Your GTM account and container structure have no direct impact on subdomain tracking in Google Analytics.

Here is my rule of thumb:

• If you have multiple subdomains and all those websites are VERY similar, you can use a single GTM container for all of them.
• If your websites on those subdomains are quite distinct and serve different purposes (e.g. a blog, the main website, a support center, etc.), then I would recommend using separate GTM containers.

However, once again I’d like to emphasize this — what matters is that data must be sent to the same GA property if you want to track the same people across multiple subdomains. So, if you have multiple GTM containers, all of them must send the data to the same GA property. Simple as that.

If you are still not sure about how many GTM containers you need, read this guide.

 

#2.3. How do you decide which subdomains should be tracked in a single GA property?

Answer this: do you want to see your visitors of an X subdomain in your GA reports together with other subdomains? If yes, then you need to track that subdomain in the same property.

That’s it. We have just decided that together with you 🙂

 

#3. Check the referral exclusion list

Usually, this is already configured properly when you create a new property in GA but it’s still a good practice to check.

First of all, a quick reminder (or maybe a lesson?) about what a referral exclusion list is.

Google Analytics tracks traffic sources based on various parameters, such as UTM tags, gclid parameter in the URL or a document.referrer (a.k.a. Referrer).

Let’s focus on a Referrer for now. Its purpose is to show the URL of the previous page. Sometimes it might show the full URL, sometimes just the domain, and sometimes be empty (depends on website’s and browser’s configuration).

If a visitor is browsing the web and navigates from one website to another, Google Analytics will check whether the domain has changed. If a domain was example.com and now I’m on a mybusiness.com, the value of the Referrer will contain example.com (but sometimes even that info is stripped (depends on browsers, websites, etc.).

Since the referrer’s domain is different from the website’s domain that I’m currently on (mybusiness.com vs example.com), GA starts a new session (because the traffic source has changed).

However, subdomains can also be treated as a distinct traffic source (because the domain of the previous page might be blog.mybusiness.com and my current page’s domain might be www.mybusiness.com).

blog.mybusiness.com is different from www.mybusiness.com.

And that usually, is not a good thing — you’ll end up with seeing self-referrals in your GA Acquisition reports.

Anyway, by default, Google Analytics handles this issue fairly easily if you entered the correct info in your Property’s settings when the property was created. Why? Because that domain is added to your referral exclusion list.

A referral exclusion list informs Google Analytics that if a visitor came to your site from XXX domain, this will not be treated as a traffic source and will be turned into a (direct) session. If the visitor already has an active GA session, it will be continued.

In your GA account, go to the Admin and in the Property column, go to Tracking Info > Referral Exclusion List.

What should you expect here? There might be one domain or there might be multiple domains entered there. That depends on your website’s ecosystem, payment gateways you use, etc.

However, if your main domain is, say, mybusiness.com, then the very same domain should be entered in the Referral Exclusion List.

Referral Exclusion List matches domains with as CONTAINS. So if a visitor comes from another domain (or subdomain) that contains mybusiness.com, that hit’s traffic source will be treated as (direct), therefore, you won’t be facing self-referral issues.

There is no need to enter each subdomain separately here. Just enter your top domain and that will cover all subdomains.

 

#4. Showing full URL in your GA reports

If you have followed all the tips above, you should now be seeing data flowing into Google Analytics from different subdomains.

However, if you haven’t done any URL manipulations with GA filters, it will be tough to identify from which subdomain did the hits come.

For example, if you go to your Content reports (Behavior > Site Content > All Pages), you will just see Page Paths but not the subdomain.

Of course, you can add a secondary dimension Hostname to see but workaround takes away the possibility to add some other meaningful secondary dimension in standard reports.

I would much rather see the domain (subdomain) together with the Page Path. Luckily, that is possible with a GA View Filter. We’ll configure it to show the full URL.

In GA Admin, go to Filters (in the View column) and enter the following settings:

• Filter Type: Custom filter > Advanced
• Field A: Hostname
• Extract A: (.*)
• Field B: Request URI
• Extract B: (.*)
• Output To: Request URI
• Constructor: $A1$B1

From the moment you save this filter, it will take the Page Hostname of every request that is sent to GA and combines it with the Page dimension. Then the result is stored in GA as a Page dimension.

WARNING: this will NOT fix your past data. Your historic data will remain without a hostname, therefore, the sooner you implement the Show Full URL filter, the better.

 

 

Bonus: Create a GA view just for a particular subdomain

If you want to see the data only of a particular subdomain in your GA reports, one of the options is to create a separate GA view for that.

To do that, go to Google Analytics Admin and press Create View, enter all the information that is required.

Then (in that very same view) go to Filters and enter the following configuration:

• Filter type – Predefined
• Include only
• Traffic to the hostname
• That are equal to
• subdomain.yourdomain.com (obviously, you need to enter your actual subdomain)

 

Test the entire implementation

Now, it’s time to test. If you implemented everything as I have explained above, this is the scenario you should test.

First, I would suggest copying the current GA view (where all the subdomain data should be gathered) and create a new filter “Include – my IP”(it’s like this one — but you need to INCLUDE you IP). Or you could just use the Test view if you have one.

When you do that, open GA real-time reports.

Browse your websites, navigate between subdomains.

You should be seeing only one active user — yourself. If you are browsing from the company’s IP address, most likely, you will see multiple people (your coworkers). Then you can try adding “?testing=true” (without quotation marks) to the URL of each page. That way, you will be able to identify yourself in the real-time reports.

Your goal here. You should see only one person who is browsing the page where the URL contains “?testing=true”. Just keep in mind to manually add that parameter to every pageview. I tried testing with UTMs in the URL (to isolate myself if traffic medium is “testing”) but real-time reports deal badly with traffic source debugging.

After you have isolated yourself in reports, if you see two users, something is incorrect. Re-read my guide once again. If you don’t see yourself on a particular subdomain, most likely, that subdomain is sending data to another GA property.

You can also check whether the _ga cookie has the same value on all subdomains (check Application > Cookies > yourdomain) in Chrome Developer tools. If you are using a different browser, you’ll need to find a way on your own. I have mentioned developer tools in greater detail in one of the above chapters.

If everything is OK, you can then check the non-test GA view by applying the same “?testing=true” technique.

 

Pro tip: don’t tag links between your subdomains with UTM parameters

Sometimes, I see people tagging links on their blog (e.g., blog.example.com) that redirect to their main website (www.example.com) and those links are marked with UTM parameters (e.g. www.example.com?utm_medium=referral&utm_source=blog&utm_campaign=blablabla).

This is a bad idea because if the visitor clicks this link, Google Analytics will start to track a new session. So if someone landed on your blog from Google Search, then went to a site and signed up/converted, your traffic source report in GA will attribute that conversion to your blog, not the Organic traffic.

Also, your session metrics will be very inaccurate.

 

Subdomain Tracking with Google Analytics and GTM: Final Words

Looks like we’ve reached the end. Here are the key takeaways from this blog post:

• If you are tracking visitors on different subdomains but they all belong to the same main domain, you DO NOT need to implement Cross-domain tracking.
• Make sure that your cookieDomain value is set to “auto” or at least to “.yourdomain.com” (that should be replaced with your actual domain). That way, all subdomains will have access to the same _ga cookie.
• Use the same GA property for all subdomains. Or at least have a rollup property implemented.
• Make sure that your main domain is entered in the Referral exclusion list
• Implement the Show Full URL filter in the GA view where you want to check the data coming in from various subdomains.

Even though this is much simpler than Cross-domain tracking implementation, there are still some nuances. If you just skimmed the content and landed at the end of this summary, I suggest you scroll up and read the longer version.

Any questions? Is there anything missing? As always, the comment section is at your service.