Cross-Subdomain Tracking in Google Analytics
Categories: analytics
One common Google Analytics issue we see a lot are issues with cross-domain tracking, especially for cases of subdomains. Say you have www.yrdomain.com and blog.yrdomain.com but you want to keep track of sessions under the same Analytics property for both.
The Google Analytics docs are pretty good in this case, but they lay out a large number of options and also focus on using the linker to pass session from domain to domain, which we’ve found to be a real problem because it means putting that linker on every single cross-domain link, which doesn’t usually work that well in practicality.
Our go-to solution pretty simple:
Step 1 — Tracker code changes.
use the same tracker code on both domains and specify the domain as the top-level domain, e.g.
ga('create', 'UA-XXXXXX-1', { 'cookieDomain': 'yrdomain.com' });
for universal analytics.js or
_gaq.push(['_setDomainName', 'yrdomain.com']);
for the ga.js asynchronous tracking code.
This gets the analytics cookies to be set at the top-level domain so they will be shared between blog.yrdomain.com and www.yrdomain.com.
Step 2 — Add Filter in Google Analytics admin.
If you just did step one the sessions would be shared between the two domains (so for example you wouldn’t lose the source of an ecommerce checkout on your www. domain if they started on the blog. domain), but you wouldn’t be able to easily see if a user was viewing the blog.yrdomain.com homepage or the www.yrdomain.com homepage, they both are “/”.
The filter you setup will make blog.yrdomain.com/ show up as /blog. So the blog homepage would be /blog, and an article would be /blog/article-name if the original URL was blog.yrdomain.com/article-name.
Make sure you set “Field A Required” to Yes, otherwise all your URLs will get rewritten to /blog.
This same method could of course be used for any domain where you want to move the sub-domain to a sub-directory in your analytics reports… news.yrdomain.com to /news, app.yrdomain.com to /app, etc. The only rule is that the sub-directory shouldn’t also exist on the top-level domain. So if you use www.yrdomain.com/blog for something else already, then for your filter use something like /blog-domain instead. Let’s hope that’s not the case though.
We also recommend creating an additional view (used to be called “profile”) where you have no filters on the domain at all. This way if you mess up the filter or want to see the raw data at some point you have another place to check.
Step 3 (optional) — Rewrite Rules
So now you’ve got these fake URLs like www.yrdomain.com/blog/article-name. If you want to close the circle here and make it so that URL actually works in case people are clicking on those URL in a report then you can add a rewrite rule to redirect it back to original URL. So in apache that’d look something like:
RewriteRule ^/blog(.*) http://blog.yrdomain.com$1 [L,R=301]
Now www.yrdomain.com/blog/article-name actually works!
Hi Jason,
Very helpful article. Question – if we have a domain that already has the same GA code on sub1.domain.com as sub2.domain.com but we’re currently only seeing traffic for sub1.domain.com – can we create a new view or account to see the traffic from sub2.domain.com? If so, will it be retro active to when it started tracking?
Hi Scott,
Thanks for commenting. If you aren’t seeing the traffic for sub2 at all then creating a new view would likely not help. Are you sure that it is not just that they are both reporting but the URLs are overlapping in the report? For instance if sub1 & sub2 both have a /about page it could be adding the numbers together for that URL. Creating a new property (with a different UA- tracking id) could make that clear if you don’t want to do the filters I describe in the article.
Unfortunately virtually nothing in GA is retroactive, so any fix you make cannot sort out your old data if its in the wrong buckets. Good luck!