There are a lot of posts on the internet about cross-domain analytics tracking, subdomain tracking, and even cross-frame (X-frame) tracking. Some are pretty solid, yet many aren’t current and/or accurate, a fair number are just confusing, and only a few of them cover all three topics well. While this does not purport to be “the one post to rule them all”, it can absolutely serve as the definitive answer to how I think about cross-X-tracking and walk most people through implementing a good solution.
I’m a firm believer in the guideline that, “if you find yourself answering the same question three times or more, you need to make it into a blog post.” By that thinking, this post is years too late, but better late than never!
Skip To:
- How to Configure Subdomain Tracking
- How to Configure Cross-Domain tracking
- How to Set Up Cross-Frame Tracking
Before we get into “how”, let’s discuss “why”.
Why Your Tracking Falls Apart
Cookies are what make any client-side, tag-based analytics tracking work. One of the most important things that your foundational Google Analytics tracking snippet does (whether it’s the gtag.js or analytics.js version) is to set a cookie in a visitor’s browser.
Note: This post focuses on GTM implementations and analytics.js. For specific instructions on configuring gtag.js, head here. Either way, at a conceptual level all the ideas in this post still apply.
That cookie contains important information that can be read, written to, or otherwise modified when Google Analytics runs on that site. Keep in mind that the GA cookie is the 1st-party cookie, meaning that it only works on the domain that set it, which is great for your users as it doesn’t track them across every other site they visit. Said cookie only comes into play while they’re in your ecosystem.
The important piece of data contained within that cookie is the Google Analytics client ID (CID, for short). That’s how Google Analytics identifies a visitor as the same person from page to page, visit to visit. It’s a pretty simplistic model, really, but it works for most webmasters. Anything more sophisticated requires significant investment — of time, money, or brainpower; usually all three.
As you go page-to-page on a website, Google Analytics needs to be present on each page. As the full page content loads and Google Analytics loads along with it, GA looks for the cookie. If it finds one, it then searches for the client ID. If that CID is the same one that was logged on a prior page view, GA can infer that you’re the same user visiting another page during your visit.
Along similar lines, if you begin a new session some days later but you haven’t cleared your cookies, that CID can be found yet again and GA will know you’re the same unique user beginning a new session.
The actual mechanics aren’t quite that simple, but that’s how it all works in a nutshell. Things fall apart when the cookie isn’t there.
The Cookie is Key
Since cookies are browser-based, analytics features such as cross-device and cross-browser tracking are problematic if not impossible to implement. If I visit a site using Opera on my MacBook and within 10 minutes visit the same site using Chrome on my Pixel 3, that site’s GA instance has no clue that I’m the same person. As far as it knows, I’m two different people because those cookies don’t talk to each other; they aren’t shared across devices.
But cross-platform web analytics is not the subject of this post. What we’re discussing here is tracking across different domains, subdomains, and even frames. These are situations where we’re able to have some control and if we approach it carefully, we can keep that CID consistent across a variety of environments.
Let’s explore how to keep that CID and cookie around when we need them most.
Subdomain Tracking
I like to start with subdomain tracking first when I’m breaking down these concepts, but I really don’t need to. That’s because subdomain tracking problems are a bit of a non-issue these days with modern GA and/or GTM implementations. However, it’s a simple example to wrap one’s head around and I think it helps cement some of the key elements.
All of this really boils down to placing the GA cookie in an accessible place and ensuring that Google Analytics knows where to find it.
While there are other wonderful write-ups and technical resources available, I think it’s helpful to distill the concept here into the simplest version possible. Put simply, cookie-setting on a domain naturally happens from left to right.
In the scenario above, Google Analytics would set its cookie on the first valid location that it could, i.e., on the “upbuild” because “www” isn’t a valid subdomain. That would be fine for any page on the main upbuild site, but what if someone then navigated to tools.upbuild.io (doesn’t exist)? There would be no cookie set on “tools”, so GA would set a new one with a new CID, thus creating what would look like a new “user”. Uh oh!
The fix, then, is to reverse the default behavior, something we can do by configuring the “cookie domain” setting to “auto”. Rather than left to right, our cookie setting will now proceed from right to left.
Note that the top-level domain (e.g., .com, .org, .io) can’t have a cookie set upon it; hostnames and subdomains (excluding www) are the only valid placement locations.
Under this scenario, a user could navigate back and forth, in any direction, between the two (or more) subdomains and be tracked properly. The cookie and, by extension, the CID would be available on the root domain and not tied exclusively to a single subdomain.
Fortunately for all of us, “cookie domain” — which is what makes this all possible — is set to “auto” by default. Back in my day, that wasn’t the case.
Cross-Domain Tracking
Cross-domain tracking is a slightly different can of worms. Similar concepts apply but there are some additional hoops to jump through on the Google Analytics admin settings site. Let’s assume that we want to track visitors on a few different domains under one analytics umbrella.
- www.upbuild.io
- upbuild.shopify.com
The prerequisite lies in the basic Google Analytics tagging. Put simply, you need to be using the same tracking code on all the various domains you want to track. So we’d want to use the same tracking code and, this is the most critical part, the same UA ID (Universal Analytics Tracking ID) on each website.
Once that’s out of the way, we have to activate a plugin that allows Google Analytics to link GA data (and the client ID) across multiple domains. The linker plugin can be thought of as additional features of Google Analytics that only come into play when needed, and with Google Tag Manager, activating the plugin is as simple as filling out a field in your Google Analytics Settings. Find the “Cross Domain Tracking” field in your Google Analytics Settings variable and add the domains for which you want to set up cross-domain tracking. GTM will then know to pull in the linker plugin and pass the CID back and forth where appropriate.
Note that you should really include both your primary domain and any secondary ones. If you’re using this same tracking set up on a secondary domain (like upbuild.shopify.com), listing your primary (upbuild.io) will ensure that users going the other direction are tracked properly.
The last step is Referral Exclusions. First, we’ll hop into the Google Analytics admin settings for the property being used.
Why is this important? Because a referred visit from another site triggers a new session in GA (even if you’re CID is the same!). Adding your secondary domains to the referral exclusion list keeps your session data nice and clean.
Note that you really only need to put the domain because sub-domains will be automatically included. Google Analytics uses a CONTAINS match in this context.
Cross-Frame Tracking
I’d originally intended to provide steps to set up cross-frame tracking in this post, but it became clear to me that any attempt to write that part of the post would degrade into a stream-of-consciousness self-therapy session wherein I went on a tirade against iframes and the bare fact that they’re even allowed on the internet, let alone used in widespread fashion.
So, alas, that section was not to be. It may well be unwritable.
In the words of the eternally-genius Simo Ahava, “(iframes) are horrible, Lovecraftian subterranean beings of horror that crawl from the nether pits of darkness after the tolling of the midnight bell. They are playground bullies; entitled little brats that wreak havoc on innocent markup. They are artifacts of human laziness, true examples of Conway’s Law in motion. They are, in essence, untrackable little shit-monsters that exist in the void between websites, accountable to none and hazardous to all.”
If you find yourself faced with the challenge of trying to reliably collect analytics data across frames,
A) I’m so, so sorry (I can provide a shoulder to cry on should you need one) and,
B) here are some pretty great posts on the subject that should provide some aid. There’s little point in my rewriting them here:
- Tracking Cross-domain Iframes – Upgraded Solution by Simo Ahava
- “Pardot and Google Analytics Event Tracking”. A wonderful solution by UpBuild’s own Laura McDougall, which I’d say is still our Gold Standard for recording conversions in Google Analytics off of a marketing automation platform’s embedded forms.
Whatever your cross-x-tracking challenge happens to be, I wish you good luck and I hope that this post has helped you on your way. If you have any questions, let me know in the comments. Happy Optimizing!
Featured image credit to @j0rt on UnSplash
