One Tag To Rule Them All: Introducing The New Google Tag

For the longest time, Google has been working towards consolidation of their products to build a unified tagging platform.

Products that are instrumented (or associated) with “tags” would fall under this umbrella. These comprise tools like Google Tag Manager, Google Ads, Google Optimize, and, of course, Google Analytics.

If you’ve been peeking under the hood, you might have noticed how all the tools listed above already run through the gtag.js library. This Global Site Tag has slowly but surely become the de facto client library used by Google’s tagging platforms on the web.

Now, Google has taken a step deeper into the consolidation process by introducing yet another overarching technology: the Google Tag.

Read the release blog post here.

While there is a lot of overlap with the Global Site Tag, this new Google Tag is, in fact, quite a bit more.

In this article, I’ll take a look at what the Google Tag is and what the underlying model looks like. This won’t be a deep-dive or a thorough tutorial – there will be other people far more qualified than me writing these, especially since one of the main benefits of the Google Tag is for consolidating analytics and advertising measurement client-side. I have very little interest in discussing the latter.

X

The Simmer Newsletter

Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!

Google Tag is gtag.js – but so much more

By default, Google Tag is pretty much the same thing as an individual gtag.js measurement product.

When you create a new GA4 stream or a Google Ads pixel, for example, corresponding Google Tags will be created at the same time. At this point, both Google Tags will have a 1:1 relation with their respective tagging endpoints, known as destinations.

In this scenario, Google Tag doesn’t really bring additional benefit to the mix, although you can, of course, make use of its new access control levels, event detection, and other features (more on these below).

Where Google Tag really starts to shine is when you combine multiple Google Tags into one and/or add multiple destinations to a single Google Tag.

Combine Google Tags

When you combine two or more Google Tags, these tags will automatically share key features such as their event detection configuration, cross-domain measurement lists, destinations and, importantly, tag coverage.

For example, when you choose to combine G-123456 and AW-567890, their respective tagging implementations (via gtag.js) will become interchangeable. There won’t be any practical difference between having the G-123456 or the AW-567890 installation on any given website.

From a tag coverage point-of-view, this means that if 80% of your website is tagged with G-123456 and 30% (including the 20% missing from the GA4 deployment) is tagged with AW-567890, you now have 100% tag coverage. The overlapping 10% is deduplicated by default.

When you combine tags, you need to choose which tag’s configuration will be used as the blueprint for all combined tags. This way you’ll be able to share cross-domain tracking settings, event detection, and user access level configurations across all combined tags (and their respective destinations, of course).

Google Tag configuration

So what is actually shared when tags are combined? What configurations can you do on the Google Tag level, so that these are then inherited by the destinations the Google Tag is collecting data to?

As the little note at the top states – not all of these settings make sense for all destination types. For example, Define Internal Traffic is really only relevant for Google Analytics 4 data streams.

• Manage automatic event detection – More on this below. This establishes what types of events the Google Tag can detect on a web page. It doesn’t yet decide what actually gets collected – that’s up to the destination’s own settings (e.g. Enhanced Measurement in a GA4 web stream).

• Configure your domains – Establish which domains will be part of cross-domain measurement for destinations configured in this Google Tag.

• Include user-provided data from your website – This lets you collect Enhanced Conversions data to your Google Ads account.

• Collect Universal Analytics events – Automatically tap into ga() calls on the website to enable collection of Universal Analytics events to a GA4 destination.

• Define internal traffic – Setup rules to flag certain traffic as internal in your Google Analytics 4 destination(s).

• List unwanted referrals – Use this setting to list domains you don’t want to appear as referral traffic in your GA4 data streams.

• Adjust session timeout – Change the session timeout for Google Analytics 4.

• Override cookie settings – Adjust the default cookie settings for Google Analytics 4.

As you might notice, these settings are really just a rehash of what you’d find under each destination, too. But the purpose of configuring them with the Google Tag is to allow multiple combined tags (and destinations) to benefit from a single, centralized configuration.

Event Detection vs. Enhanced Measurement

At this point, it’s good to clarify the difference between configuring a Google Tag’s Event Detection settings vs. configuring a single GA4 destination’s Enhanced Measurement options – the two look very similar!

Event Detection is a feature of the Google Tag, where you get to configure what types of on-page events the tag is set to monitor.

For example, you can configure that the Google Tag can only monitor outbound clicks.

These event detection settings set the parameters of what you can configure in GA4’s Enhanced Measurement settings!

If you do so, then any GA4 destinations added to the Google Tag will at most be only able to collect outbound click data. You can toggle the Outbound Clicks off in the Enhanced Measurement settings of one connected GA4 destination but leave them on in another. But even if you toggle, for example, Scroll events on in the GA4 data stream settings, those will not get collected because their Event Detection hasn’t been enabled in the Google tag settings.

If you know your data engineering terms, think of this in terms of a Publisher / Subscriber setup. The Google Tag is set to detect and publish events to the destinations configured in the Google Tag. These destinations can then subscribe to all or some of these events. But destinations can’t measure events that weren’t broadcasted by the Google Tag.

Tag destinations

Each GA4 web stream and each Google Ads conversion is now known as a Google Tag destination.

By default, as mentioned above, when you create a new destination, it will have its own Google Tag automatically created for it.

Each destination can be added to one, and ONLY ONE, Google Tag.

You can remove a destination from its original Google Tag, and add it to another Google Tag.

This is useful if you want to prevent a destination from being controlled by its previous Google Tag.

For example, if you used to work with an agency that used your GA4 destination with their Google Tag, you could remove it from that Google Tag and add it to your site’s own Google Tag to prevent the agency from being able to control the destination’s data collection.

Combining and adding destinations is NOT consolidation

You might be tempted to think that by combining Google Tags and/or by adding multiple GA4 streams as destinations, you are effectively able to duplicate a single tagging setup to multiple different destinations for every single event collected through that setup.

This is not how it works.

When you add multiple destinations to a Google Tag (either by combining tags or just adding the destinations), what actually gets multiplied is the tagging configuration.

On-page, this means the config API calls of the Global Site Tag.

When the config API call (or GTM’s GA4 Config tag) of the main Google Tag or one of the combined Google Tags runs on the page, all destinations added to it will start their collection, too.

Enhanced Measurement events will be sent to all destinations, including the Page View hit unless the config tag prevents the automatic collection of the Page View event.

All other GA4 (or Ads) events will be sent only to the destination configured in the event itself.

As such, the Google Tag helps you install different destinations on any given website. It doesn’t do the tagging for you.

Summary

At release time, the Google Tag is definitely geared towards enterprise use, as it’s larger companies with more varied data collection needs that would most benefit from consolidating multiple tags’ configurations into one single place in the admin infrastructure of Google’s more and more complicated tagging ecosystem.

While I’m somewhat worried that the overlap between the Google Tag and the Global Site Tag will just muddy the waters even further, once you understand how the Google Tag is an administration feature and the Global Site Tag is the client-side component of the Google Tag, it should all start to make sense.

Out of the box, the Google Tag lets you control what types of events can be automatically detected on a site, what cross-domain measurement settings to use across connected destinations, which users are able to view and modify the tag settings, and so forth.

Once you combine Google Tags (especially across tagging products like GA4 and Google Ads), you’ll really start to benefit from the features discussed in this article. At that point, Google Tag becomes more than the sum of its parts.

Do you think Google Tag is a welcome addition to Google’s already quite expansive (and often confusing) tagging offering? Do you think consolidating tagging efforts across products makes sense? Let the readers know in the comments section below!