Hello friends! Today I want to direct your attention to a dangerous setting found within the bowels of the Universal Analytics Tag template in Google Tag Manager. In fact, GTM itself highly discourages you from meddling with it:
I actually agree with this warning. It should be highly discouraged, as modifying the tracker name introduces a potential hazard to your tracking plan, unless you know what you’re doing.
But I’m getting ahead of myself, let’s take a step back and look at just what we’re doing here.
The Simmer Newsletter
Follow this link to subscribe to the Simmer Newsletter! Stay up-to-date with the latest content from Simo Ahava and the Simmer online course platform.
Tip 41: One tracker name to rule them all
By setting the Tracker Name field, you can have multiple Google Tag Manager Tags use the same tracker name (for various purposes), or you can combine your on-page, traditional analytics.js tracking with tracking done via GTM’s Tag templates.
David Vallejo’s written a great guide for tracking single-page sites. This solution relies on setting a Tracker name across your tag templates, and I consider it to be the only solid way of fixing the “rogue referral” problem that single-page sites have with GTM.
(Just for reference, the problem with rogue referrals is that after the initial landing page hit with the UTM and/or GCLID parameters, any referrer information in the HTTP request will override these campaign settings due to how Universal Analytics processes referrals. In other words, after the landing page, any virtual pageview that does not have these UTM and/or GCLID parameters will, by default, be sent with the referrer as the campaign source, potentially starting a new session).
However, before dashing to your GTM container (why would you do that anyway?), pause for a moment. Google Tag Manager, by default, uses a random, unique tracker name with each instance of a Tag, even if they’re injected by the same Tag template. This means that, by default, no two Tags fired via GTM ever share the tracker name.
This, in turn, means that settings you set in one GTM Tag will never be inherited by any other Tags. Thus you can’t make use of settings that would apply to multiple Tags simply by modifying the fields in one. You will need to replicate the settings across the Tags.
To solve the inheritance problem, all you need to do is set the multiple Tags to use the same Tracker name. This way, the settings you set in one Tag will affect the settings in all the subsequent Tags that share the Tracker name! How simple and beautiful. To fix the “rogue referral” problem in AJAX sites, you’d set the same Tracker name for each Tag, since now they’ll share the “Document Location” setting, meaning a possible referral will not override any UTM Tags or AdWords GCLID settings in the URL itself.
Wonderful.
However, and this is a very emphatic “however”, setting the Tracker name will share all settings across the Tags! Yes, that’s right, even hit-scoped Custom Dimensions and any fields you set for one Tag alone. In GTM, at the moment, there’s no way to differentiate between fields you set for a hit and fields you set for the tracker. Only the latter exists in GTM.
Naturally, if you do not touch the Tracker name setting, these fields are, in essence, “per hit”, since each Tag has a unique Tracker, right? But when you set the Tracker name across multiple Tags, they will share all the field settings whether you want them to or not.
This leads to some embarrassing situations, and it requires quite a hacky workaround. For example, if you set the Tracker name in Tag 1, and you also add a hit-scoped Custom Dimension that you want to apply to that Tag alone, in your next Tag with the same Tracker name, you’ll need to add a null-returning Custom JavaScript Variable to the same Custom Dimension field to ensure it isn’t inherited from the first Tag:
function() {
return null;
}
That’s just clumsy.
So, my point is this. When you’re setting the Tracker name across your Tags, whether by design or because you’ve read the tip online somewhere, make sure you audit the fields you set in the Tags. If any of them should exist in one Tag alone, you will need to manually clear the those fields in all the other Tags that use the same Tracker name.
I hope, no, I beg that Google Tag Manager would let you decide whether to set fields only for the Tag rather than for the Tracker name. This would solve a lot of issues.
Alternatively, I wish analytics.js would take care of the “rogue referral” problem natively, making sure subsequent page views after the landing page (with the UTM parameters) would not utilize the HTTP referrer to override the currently active source/medium.