With a recent update, the Google Tag Manager and Google Tag technologies are finally merging.

In my many posts about Google Tag, I’ve often lamented the fact that while any given Google Tag is essentially a wrapper for an underlying Google Tag Manager container, for some inexplicable reason Google Tag Manager containers themselves did not have the capabilities of Google Tags (and vice versa).

Well, that’s a thing of the past now. By upgrading to the new tagging experience in Google Tag Manager, the container will have the full capabilities of a Google Tag. Most importantly, Google Tags that you have access to can now be linked directly to the GTM container as destinations, governed by a single set of Google Tag settings (conveniently accessed via the GTM user interface, too).

You might be wondering: So what? After all, Google Tag has always been a fuzzy piece of technology that’s never fully realized its promise. However, for client-side performance, things are now on a completely different level. Destinations are no longer loaded as separate gtag.js resources. Instead, the Google Tag Manager file itself contains all the instructions and settings that should be applied to the destinations.

This incentivizes joining permission management between Google Tag Manager and the linked Google Tags. Adding ad hoc destinations to the container can still be done by using the new Destination tag types (more on these below), but without proper linking, you’ll miss out on having shared permissions.

In this article, I’ll explore the new tagging experience in detail. Read on!

The new tagging experience in a nutshell

The main thing that changes is that your Google Tag Manager container is now a Google Tag, too.

Individual products (GA4, Ads, Floodlight) can be loaded as destinations of the Google Tag Manager container, meaning they can all benefit from a single set of settings and permissions that are centralized in the GTM container itself.

There are new tag types (Destination tags) to replace the (legacy) Google Tag type in Google Tag Manager. These tag types start data collection for their respective destinations without generating additional gtag.js resource loads, and they make use of the shared settings you’ve configured in the GTM container. The new tag types have all the capabilities of the legacy loaders, in that they let you override individual configuration fields and are, naturally, consent-aware.

There are some changes to the Google Tag Manager user interface, the container settings, and Preview mode which we’ll explore later in this article.

Next, let’s explore the terminology a bit.

What are tagging destinations?

A Google Tag sets the parameters for how individual products can work. For example, it determines what kinds of events can be automatically detected, whether first-party data collection can be done, and they can even override consent defaults.

Individual products (GA4 data streams, Ads conversions, Floodlight sales tags, for example) can be added as destinations to a Google Tag, at which point they will automatically observe all the settings configured in the Google Tag. However, they can also override these settings, although never to a less strict state.

For example, if the Google Tag prevents User-provided data collection, a Google Ads conversion tag linked to this Google Tag can’t enable it in its own settings. In contrast, if the Google Tag did allow User-provided data collection, you could still disable it with the Google Ads tag settings.

So, when you link your products as destinations of this new Google Tag Manager container experience, they will inherit all the settings that you configure in the new Settings view. However, you can override these central settings to a more strict state by configuring them directly in the Destination tag itself.

To get started, you can use the handy optimization wizard to migrate your Google Tag Manager container to the new tagging experience.

The optimization wizard

For containers created prior to this release, you will see a banner in the Google Tag Manager user interface that lets you start the optimization process.

Start the optimization

When you click to start the optimization, a new overlay pops up that shows you all the Google Tags (to which you have access) in the container.

In this list, you can uncheck the tags that you do not want to automatically link to the container as destinations. If you uncheck them, they will remain as (legacy) Google Tags in the container, and they will not enjoy any of the benefits of the optimized experience.

For each individual tag, you can choose whether to grant Read access to the Google Tag Manager container for anyone with prior access to the Google Tag itself. I think it’s a smart move to grant Read access, because having access to just the Google Tag and not the deployment mechanism (Google Tag Manager) can quickly become a handicap in effective tag management. You can always change the permissions later in the container’s settings.

You can also click View settings to see the individual settings for each listed Google Tag. This is a good idea as you prepare for merging the settings in the next screen.

Choose container settings

In the next step, you need to choose which Google Tag settings to apply to the Google Tag Manager container. If the destinations have identical settings, there’s no choice to make. The shared settings will be applied to the container.

If the tags have different settings, you can choose which one to use as the blueprint for the container’s shared settings. You can also choose not to import anything at all and instead configure the shared settings from scratch.

See how I’m talking about shared settings here? That’s one of the main benefits of the optimization. All destinations that are added to the container will make use of the same set of Google Tag settings, meaning you no longer need to worry about having to maintain everything in sync across multiple different products.

You can always override individual settings in the Destination tags themselves (more on this below).

Preview what the optimization changes

Before clicking Add to workspace in the top bar, you should click Show details. It lets you inspect, at a glance, all the changes that the optimization wizard will do.

Google Tag settings are added as a new Setting type into the container. You’ll manage these in the (equally new) Settings menu in the container navigation.

Google Tags that were linked to the container will show up as being Modified. This means that they will no longer be Google Tags but will instead be converted to the new Destination tag types (more on these below).

In case you decided to allow Read access to the container for the linked destination users, you’ll be reminded about this, too:

Finally, you’ll have a handy visual showing you what will happen to Google Tags that were optimized vs. those that weren’t. Here’s the Before view:

Here, the optimization tool found three Google Tags in the container. One for Floodlight (DC-12345) to which I do not have access, and two for different GA4 measurement IDs.

You can see that I have access to these latter Google Tags as the optimization tool has flagged them with the warning symbols, indicating they can be directly optimized to benefit from the new tagging experience.

Here’s what it looks like when I click the After toggle to preview what happens:

After optimizing, the DC-12345 stays as a separate Google Tag, but the two GA4 tags are now combined with the Google Tag Manager container as direct destinations.

Add the changes to the workspace

To complete the optimization, you can click Add to workspace in the top bar.

IMPORTANT! The changes are added as changes to the workspace. They will not be automatically deployed. You will still need to test things as usual with Preview mode before publishing the changes to make them stick.

The cool thing is that you can always roll back the optimization by reverting the container to an earlier version!

Before we move on, let’s review what the new Destination tag types are.

New tag types

There are “new” tag types in the container, and ye olde Google Tag should no longer be used (as it forces the extra gtag.js load).

Here’s what the set of Google Analytics 4 tag types looks like:

You might find it a bit funny how Google has changed this approach over the years. From having just event tags, to having a Configuration tag, to having a Google Tag, and now to having a Destination tag.

The Google Analytics tag loads an associated Google Analytics 4 data stream in the container. Its main benefit over using the legacy Google Tag type is that when it’s loaded, no additional resource loads take place as everything is contained in the GTM library.

Additionally, as soon as the Destination tag fires in the container, it makes use of the shared settings, including (but not limited to) automatic event detection.

The new Destination tags are Google Analytics, Google Ads, and Google Floodlight:

As mentioned above, the old Google Tag is now considered as Legacy, and its use should be avoided. Similarly, the Conversion Linker is now a legacy tag, too, as its functionality is handled by the Destination tag(s).

As before, you can override individual fields in the Destination tag’s settings, such as preventing the automatic page_view dispatch or configuring server-side tagging.

The Destination tags are, of course, consent-aware as are all of Google’s tag types these days.

To help wrap your mind around this change, think of the new Destination tag type as an iteration of the (legacy) Google Tag type, and you should migrate all existing Google Tags to the new Destination tags as soon as possible. The optimization tool does the work for you for all Google Tags that you have access to.

Why doesn’t Google automatically change all legacy Google Tags to the new Destination types, you might ask? Well, the reason for this is that the new Destination tag types automatically make use of the shared settings in the container, which might lead to data quality and compliance issues. When you migrate a legacy Google Tag to the new Destination tag, you need to be mindful of the container’s shared settings and how the tag’s individual settings might diverge from these.

Speaking of shared settings, next we’ll take a look at how they are implemented through the Google Tag Manager container.

Tag settings in the container

The Google Tag settings for the Google Tag Manager container are now integrated into the container experience itself.

When you click the Settings link in the navigation, you’ll see something like this:

The Add destination button in the top corner opens an overlay that lists all the Google Tag destinations to which you have admin access. You can then easily add those as destinations of the GTM container!

These are the shared settings applied to all Destination tags that are added to the container.

The cool thing is that individual settings are treated as Google Tag Manager resources, meaning they’ll have proper version history in Google Tag Manager itself.

When you make a change to a setting, it becomes a workspace change which can be previewed and tested. It’s only once you publish the container that the setting change goes live! That is very, very useful.

If you have (legacy) Google Tags in the container, they will show up in the list of destinations, too. However, they will show up as not optimized and without an external account link.

If a destination hasn’t been added as an External Account Link, users of the destination will have no visibility to the GTM container itself.

Feature request: settings conflicts

One thing that I would like to see, which would dramatically improve transparency between the container and the destination(s), is some way to flag potential conflicts between what the GTM container imposes on the destinations and what the Destination tags might have configured in their own settings.

For example, if the destination has been configured to not allow User-provided data capabilities but the Google Tag Manager container’s respective settings do allow this feature, it could spell trouble.

The shared Read permissions help a little, but because GTM’s settings have final say, it would be useful to have this flagged in the Settings overview somehow.

However, since Google Tag Manager admins do not automatically get visibility to the Google Tag’s own settings, this conflict needs to be flagged so that it doesn’t reveal something about the Google Tag that’s not meant for the GTM user’s eyes.

Here’s a very rough outline of what it could look like. There would be no additional information available about the nature of the conflict, but just knowing something differs between the two sets of settings is enough to warrant an investigation.

The screenshot above is my (sloppy) design, not something that’s actually in the product.

The new “Manage data transmission setting”

There is a (relatively) new setting available in the container: Manage data transmission settings.

It’s basically a Basic Consent Mode control on top of Advanced Consent Mode.

It lets you specify whether Google Tag Manager should automatically withhold any hits if relevant consent has not been granted.

If consent is then granted on the page, GTM will automatically (re)fire all the hits that were thus withheld.

This is very, very interesting. One of the most complicated things to set up with Basic Consent Mode is the queueing and refiring of events that were blocked due to lack of consent.

With Manage data transmission settings, you can control this data flow for advertising and analytics tags.

For advertising tags, you have an even more granular control, where you can choose to submit a limited set of data (so the typical Advanced Consent Mode approach) or to block the advertising requests altogether until ad_storage consent is granted.

This works remarkably well and will make Basic Consent Mode setups much easier. It might even eliminate the need to have tag-specific consent settings.

However, a major caveat is that it only works with Google’s tags. It won’t help with other vendors’ tags.

Now that we’ve explored how the shared settings model works, it’s time to delve into how permissions are distributed between Google Tag Manager and the linked Google Tags.

Permissions management

By default, users who had access to the Google Tag will automatically receive Read access to the Google Tag Manager container, if the Google Tag is added as a destination of the container.

You can always adjust these permissions by going to Admin and selecting External account links in the Container Settings.

This doesn’t work in reverse. Users who manage the Google Tag Manager container will not receive access to the linked Google Tags.

The reason for this permissions linking is to add transparency and alleviate possible confusion that might result from setting conflicts.

As mentioned before, when a product is added as a destination of the GTM container, it will inherit all Google Tag settings configured in the container.

If the Google Tag user didn’t have visibility to the GTM container, they might wonder why the settings they’ve configured in the Google Tag aren’t respected when the tag is firing through a linked GTM container, where some settings might be configured differently.

For this reason, allowing Read access to the container is a good idea. Having said that, it’s also a good idea to audit who has access to the Google Tag prior to making the change, so that you don’t inadvertently give someone visibility into the GTM container who should not be privy to its contents.

Perhaps at some point the permission model will be enhanced so that instead of giving Read access to the full container, the automatically added users could only see the tag settings, for example.

Next, let’s explore the user interface changes in more detail, starting with the Google Tag Manager container Overview page.

Container overview

Helpfully, the Overview panel includes a diagram of all the included Google products that are added to the container.

For (legacy) Google Tags, they’ll show up as an additional hop before the destination.

In the example above, I’ve added AW-23456 and DC-12345 as (legacy) Google Tags. The two GA4 destinations are linked to the container, and the two advertising destinations are added as Google Tags but not linked to the container.

The number next to the destination indicates how many tags (Google Tag / Destination tag included) reference that destination.

If you click a destination, a new Destination details overlay appears, and you’ll be able to see a list of all the tags that reference this destination.

You can use this panel to quickly get an understanding of how data flows from the container to individual Google destinations.

Preview mode

There are some new (and old, but relevant) features in Preview mode that we should discuss.

First of all, the icon that indicates a deferred hit (1. in the image above) is now very relevant in case you’ve made use of the Manage data transmission setting we discussed above.

If you’ve configured this setting to prevent the transmission of analytics or advertising data until proper consent has been granted, then any relevant tags that fire will have their hits deferred until a Consent Update signal (with appropriate consent) shows up. So it’s a nice visual of how your tags are actually respecting a Basic Consent Mode approach, even if they’ve been set to fire regardless of consent.

Since GTM is now a Google Tag, Preview mode shows the Hits sent tab as part of the GTM preview itself (2. in the image above). This is what the tab looks like for a trigger event that caused a hit to be sent:

The warning about hits being delayed just means that GTM processed the trigger event before the destination was loaded in the container.

Finally, if a Destination tag fired for the trigger event, GTM shows the Settings that were activated in the container (3. in the image above). You can click an individual setting to see what was configured:

Time will tell whether this consolidated view in Preview mode gets too messy, especially in containers with lots and lots of destinations.

Summary

This is, in my view, the biggest change in Google Tag Manager in over a decade.

By consolidating Google Tag Manager and Google Tag technologies, Google has a chance to overcome one of their biggest blunders: maintaining overlapping and competing technologies for deploying their tags.

The optimization process is quite simple, but I can foresee how it gets exponentially more complex in case you have multiple destinations with competing settings to be integrated into the container. At that point, you need to approach the optimization process as a proper migration: add the new destinations incrementally, test everything, and roll back if necessary.

By far the biggest benefit of going forward with the optimization process is improved page performance. The fact that each Google Tag was always loaded as a separate JavaScript resource was stupefying, and the amount of bloat that these libraries introduced to the page was staggering. With this setup, you only ever load the GTM container, and all destinations are just data objects within. For this reason alone, the optimization process is totally justified.

There’s one additional benefit to all this that a GTM old-timer like myself really appreciates. Google has prioritized Google Tag development over GTM updates for years now. With this merge, any improvements made to GTM will be reflected in Google Tag (and vice versa). This means that hopefully we’ll see Google Tag Manager blessed with new features and performance improvements at the same scale that we used to have before Google Tag was introduced.

What do you think of this new GTM? Let me know in the comments!