Let’s face it - most of us use Google Tag Manager for one main purpose: to deploy and configure Google Analytics tracking on a website. I’d wager that once you start using GTM, you won’t be implementing Universal Analytics the old-fashioned way, with on-page code, any more. But running Universal Analytics tags through GTM isn’t yet a perfect workflow. We’re still missing things like proper plugin support and the option to properly differentiate between the tracker and the hit - both of which are easy to do with an on-page implementation.
For me, and I’m sure for many others, one of the biggest problems with Universal Analytics has been how to manage scale. Once you have dozens of tags that have some settings configured in a specific way, e.g. cross-domain tracking settings or custom page paths, it becomes a nightmare to update each and every one when you want to make a change to one of these generic settings. Well, it’s been a long time coming, but Google Tag Manager just introduced a feature to help us with this: the Google Analytics Settings variable.
The variable contains the fields you’ll find under “More Settings” of Universal Analytics tags, combined with some set fields that are (typically) absolutely necessary to include in all tags anyway (Tracking ID and
cookieDomain, specifically). The advent of this new variable type gives you three ways to create and manage Universal Analytics tags:
Copy all settings from the Google Analytics Settings variable.
Don’t use a Google Analytics Settings variable at all, and instead set all fields manually.
Use a combination of both: set the fields with a Google Analytics Settings variable, and then overwrite some of the fields with custom values on a tag-by-tag basis.
This gives you a lot of flexibility to work with.
The Google Analytics Settings variable is available in your web containers as well as your mobile Firebase containers.
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.
The Google Analytics Settings variable
You can find the new variable in the variable creation menu that pops open when you start building a new User-Defined Variable.
The first thing you’ll notice is that the Cookie Domain field is auto-populated with the value
auto. This is an excellent change, and removes one of the key differences between the recommended analytics.js tracking code (which has
auto as the default value for
cookieDomain) and the default Universal Analytics tag template in Google Tag Manager (which does not have a
cookieDomain value set at all).
Note that the Tracking ID field is required, so add your Universal Analytics property tracking ID or a variable you’ve used before to it before saving the new variable.
If you click More Settings you’ll find all the fields available for configuration in Universal Analytics tag templates. You can set these as you wish, remembering that they will be applied to all tags that use this variable.
Note that obvious conflicts are resolved automatically. If you Enable Enhanced Ecommerce Features in your Google Analytics Settings variable, and then add this variable to a Timing type Universal Analytics tag, the Timing tag won’t magically turn into an Enhanced Ecommerce enabled tag. Since Enhanced Ecommerce hits can only be sent with Page View and Event tags, this particular setting is simply ignored in incompatible tag types.
Adding the settings to your tags
To add your settings to tags, you’ll find a new drop-down under the heading Google Analytics Settings that instructs you to select a variable from the list. You can also start a new variable creation workflow from this menu.
As you can see, you can still configure the Advanced Settings individually for this tag. That’s because Advanced Settings have nothing to do with Google Analytics - all tags in Google Tag Manager have these same Advanced Settings fields.
You’ll still need to add individual triggers to this tag. Again, triggers are not specific to Universal Analytics tags. The Google Analytics Settings variable only conflates all Google Analytics settings into a single variable configuration.
As I mentioned in the introduction of this article, there are three ways to implement a Google Analytics Settings variable in your Universal Analytics tags. The first one is in the screenshot above. When you apply the variable and save the tag, all Google Analytics settings are derived from the variable. This is definitely the most light-weight and straightforward way to implement the variable.
The second way is to ignore the variable completely, and just create an individual, one-off tag. In this case, you need to do two things:
Leave Select Settings Variable… as the value of the drop-down.
Check the box next to Enable overriding settings in this tag.
Once you do these two things, you’ll completely ignore any Google Analytics Settings variables and just configure the tag independently. A very useful thing to still have, especially if you want to do some quick prototyping.
If you use a Google Analytics Settings variable, all fields that you set in that variable are inherited in the tag that uses the variable. You can always override the fields, but it might be difficult to remember just which fields have been set.
For this conundrum, there’s a brilliant UI workflow update. See the little (I) icons in the screenshot above, marked with a yellow star? When you click that icon, an overlay opens with the variable in question for you to review or even edit! You can now modify or edit variables mid-workflow, without having to leave the tag settings to make adjustments.
This is, naturally, vital for the Google Analytics Settings variable as well, because you want to be careful you’re not overriding fields that should not be overridden. It would be helpful to see the actual modified values and settings inherited from the variable in the tag itself, but I guess there are technical limitations why this is not (yet) possible.
Ideas for use
Here are three types of Google Analytics Settings variables I use in my projects.
1. General settings
This is the one I use as a generic settings variable in tags that have no special function (e.g. regular Page View and Event tags).
These are fields I use in all my tags.
2. Cross-domain tracking
If I have a rollup property to which I collect cross-domain tracking data, I have a Google Analytics Settings variable for that, too.
And in all my rollup tags, I would have the settings from above. If I had rollup tags that have BOTH Enhanced Ecommerce and cross-domain requirements, I would set them up with cross-domain tracking settings and then manually add the Enhanced Ecommerce settings.
3. Enhanced Ecommerce settings
And finally, I have a generic settings template for all Enhanced Ecommerce tags.
With this tag, I can setup simple Enhanced Ecommerce settings for all my EEC tags. In some special cases, I can override these default settings with custom stuff.
This is a pretty smooth feature for managing your Universal Analytics tags. I firmly believe this is a great timesaver, as it will help you avoid typical data quality mishaps with misconfigured tags. With the Google Analytics Settings variable, it’s also easy to help new users become accustomed with your data collection configuration. New users, typically, are the weakest link for data quality, as they might not know all the settings the Universal Analytics tags in your organization should be configured with.
If there’s one thing I’m missing it’s variable chaining. I would like to be able to use a Google Analytics Settings variable within a Google Analytics Settings variable. In the three examples of the previous chapter, you can see that all these settings variables share the same Custom Dimensions. I would like to specify that all these three settings variable use another settings variable as the base, and then simply add/modify all the necessary settings. This way I could create a hierarchy of settings variables, making it even more unlikely that misconfigured fields lead to data quality issues.
Naturally, chaining variables can lead to issues, too, so proper governance and common sense would still rule.
Do you have some “go-to” settings configurations in your tags, for which you could leverage the new settings variable?