GTM’s new Google tag: one tag to rule them all
Goodbye to the GA4 Config Tag
Anyone who’s spent any time implementing the Google Analytics 4 (GA4) tracking in Google Tag Manager (GTM) over the past few years will be familiar with the GA4 Configuration tag. Essentially the top level of tracking within GTM for configuring GA4, this is where you would specify your Measurement ID, configure server requests and specify things like event parameters and user properties.
The GA4 Config tag would then typically act as a reference point for all your GA4 Event tags. For anyone still mourning the demise of Universal Analytics (UA), the GA4 Config tag behaved kind of like a UA Pageview tag and a Settings Variable all rolled into one.
However, the eagle-eyed among you will have recently spotted a new message in your Google Tag Manager containers, heralding the news that change is afoot:
Hello to the Google Tag
In a move that has seemingly been brewing for a while, Google is introducing “one tag to rule them all” (and in a Google black box bind them?).
If Google Tag sounds familiar, it’s because it’s already been kicking around for a while. Formerly known as Global Site Tag, and commonly abbreviated to GTAG(.js), the Google Tag uses a single Tag ID that lets you fire information to all your favourite Google platforms.
The key thing here is that where GTM and GTAG were previously kind of an either-or situation (with GTAG typically being hardcoded), they’re now merging into one. This means you can send hits to multiple platforms from one handy GTM tag.
Before we all start panicking, Google assures us in their container-topping banner that “Your existing measurement will not change and no action will be required.”
Good news, but what’s changing?
GA4 event tags!
GA4 Event tags are changing, but only ever so slightly, in that they’ll work with the new settings variables. The main difference here is that GA4 Event tags still reference your GA4 Property’s ‘Measurement ID’ while the Google Tag uses the ‘Google Tag ID’.
Right now GA4 Event Tags are displaying the following when creating a new GA4 Event:
It looks as though Google will gather the Measurement ID from the GA4 Config Tag you specify here and populate the new Measurement ID field with that value when Google Tag officially launches.
The Return of The Settings Variable
Google has replaced the GA4 Config tag’s “Fields to Set” with two new Settings Variables. They have also moved around the Send a Pageview, Send to Server Container and User Properties settings.
The two new Settings Variables we have now are:
The Configuration-Level Settings Variable is for any parameters that you want to set when the Google Tag loads. Examples might include various page-level data points like Page Type or Page Location etc. The Configuration-Level Settings Variable also now hosts the Send a Pageview option, as well as the Send to Server Container option.
A neat new addition in Settings Variables is that they will give a little tick if they recognise your parameter as a predefined parameter:
The Event-Level Settings Variable is to hold various event-level parameters like ecommerce data, click/navigation event data etc. The Event-Level Settings Variable is also the new home for all your User Properties.
The Event Settings Variable will also give you little ticks for predefined parameters, although oddly not user_id, uid or cid (at the time of writing):
For any who don’t remember UA’s Settings Variables, the great thing about them is that you can populate them with all the key parameters you’re interested in for your daily tracking needs, and then reuse that variable across any tags you like. This saves needing to duplicate work manually updating tags with individual parameters.
There does seem to be a fair amount of overlap between which parameters you can and should include in Config Settings Variables and Events Settings Variables. However, Google has provided lists of recommended parameters for Configuration Settings and Event Settings, so unless you have a particular use case in mind, it’s best to align with those where possible.
How has my container changed?
Google is currently in the process of rolling out these changes and will be replacing existing GA4 Config tags with the new Google Tag. It looks like the GA4 Config tag will continue to live as a ‘Legacy’ tag for the foreseeable future.
For those who haven’t had their containers updated yet, this is what the tag looks like:
Where previously the GA4 Config tag had UX checkboxes to send page views and to send hits to a Server Container, these are now manually specified either in your Google Tag, your Config Settings Variable, or your Event Settings Variable.
On that note, we’ve been seeing that multiple Google Tag configurations on a page can overwrite each other. As such it’s advisable to include server_container_url and other critical parameters in Event Settings Variables. This is because if you fire a Google Tag with a server_container_url specified, followed by a Google Tag with the same Tag ID without your server_container_url specified, that 2nd hit won’t go to your server and neither will subsequent hits.
It’s very important to make sure you aren’t accidentally using multiple configs and overwriting yourself.
As Google says, there’s no need to change your existing configurations right now, they will be doing it for you. That said, the way we approach new implementations should be streamlined with the addition of the new Settings Variables. Google Tag’s combined approach should also save a lot of time and headaches when it comes to implementing tracking for the Google Marketing Platform (GMP) products such as Google Ads.
In a future blog post we’ll discuss Google Tag IDs and how to combine tags, as there are different formats depending on the platform (G- for GA, AW- for Google Ads and GT- which look to be the combined tag but more on that soon).
If you have any questions on what this change means for your implementation, or if you’d like a second pair of eyes on what you’re setting up, please do let us know and get in touch!