For years, one oddity has made GTM work messier than it needed to be. A Google Tag is essentially a wrapper around a Google Tag Manager container, yet GTM containers didn't have the capabilities of a Google Tag. With the new tagging experience in Google Tag Manager, that gap is closing. A container you upgrade becomes a Google Tag in its own right.
Simo Ahava covers the update in detail in his write-up on the optimized tagging experience. This article is our practical take: what the merge changes for GA4 data collection, and what we audit in a container before anyone clicks the optimization banner. The wizard is well designed, but it acts on whatever state your container is already in. If that state is messy, the migration carries the mess forward, and some of it gets harder to see.
What actually changes
The short version: your GTM container now behaves like a Google Tag. Products such as GA4 data streams, Google Ads conversions and Floodlight can be linked to the container as destinations. Linked destinations share one set of Google Tag settings and permissions, managed in the GTM interface under a new Settings menu.
Three changes matter most for GA4 collection.
No more separate gtag.js loads for linked destinations. According to Ahava's write-up, destinations are no longer loaded as separate gtag.js resources. The GTM file itself carries the instructions and settings for each destination. That is a real client-side performance gain, and it is also why the legacy Google Tag type should be phased out: it forces the extra gtag.js load.
New Destination tag types. The legacy Google Tag is replaced by three Destination tags: Google Analytics, Google Ads and Google Floodlight. They keep the old loaders' capabilities. You can still override individual fields, such as preventing the automatic page_view or configuring server-side tagging, and they are consent-aware. The Conversion Linker also becomes a legacy tag, because the Destination tags now handle its job.
Shared settings with one-way overrides. The Google Tag settings decide things like which events are detected automatically, whether first-party data collection can happen, and they can override consent defaults. Destinations inherit these settings. A destination can override them only to a stricter state. If the shared settings block user-provided data collection, a Google Ads Destination tag can't switch it back on. If the shared settings allow it, the Ads tag can still turn it off.
That last point drives most of our audit. Shared settings are convenient. They also mean one decision now affects every linked destination at once.
How the optimization wizard works
Containers created before this release show a banner that starts the optimization. The wizard then:
- Lists every Google Tag in the container that you have access to. You can uncheck any tag you don't want linked. Unchecked tags stay as legacy Google Tags and get none of the benefits.
- Asks whether to grant Read access to the GTM container to anyone who already has access to each Google Tag.
- Asks which Google Tag's settings should become the container's shared settings. If every destination has identical settings, there's no choice to make. If they differ, you pick one as the blueprint or start from scratch.
- Offers a Show details view before you click Add to workspace. Here you can see that settings are added as a new Setting type, that linked Google Tags are marked Modified and converted to Destination tags, and how the setup looks before and after.
Two safety nets are worth knowing. First, the changes land in your workspace and are not deployed automatically. You still test in Preview mode and publish. Second, you can roll back by reverting to an earlier container version.
Ahava also explains why Google doesn't convert legacy tags automatically: the new Destination tags inherit the container's shared settings, which could cause data quality and compliance problems. Read that as the brief for your audit.
The pre-migration audit checklist
This is the checklist we work through for each client container, in order.
1. Inventory every Google Tag and its owner
List every legacy Google Tag in the container: GA4, Ads, Floodlight. For each one, note who has access to the underlying Google Tag. The wizard only offers tags you can access, and the Settings view's Add destination button only lists destinations where you have admin access. Any tag you can't access stays legacy, as Ahava's example shows with a Floodlight tag he couldn't access. Sort out access before you start, or you'll end up with a half-migrated container.
2. Compare the settings of each Google Tag side by side
Use View settings in the wizard, or check each Google Tag in its product interface first. Look at automatic event detection, first-party data collection, user-provided data collection and any consent default overrides. If two GA4 streams in the same container are configured differently, choosing one as the blueprint silently changes the other. Decide on the target settings on purpose, and write down why.
3. Map consent behaviour before and after
Google Tag settings can override consent defaults, so the shared settings now have consent implications for every linked destination. Before migrating, record how each tag behaves under each consent state in Preview mode. After migrating, repeat the same test. If anything changes, find out which shared setting caused it.
4. Find duplicate loaders inside and outside GTM
This is where we see the most risk of double counting. Look for:
- More than one tag loading the same GA4 measurement ID in the container. For example, an old Google Tag plus a newer one added by a different team.
- Hardcoded gtag.js snippets in the site templates for IDs that GTM also loads.
- Plugins or CMS integrations that inject their own GA4 tag.
The optimization merges what's inside the container. It can't see a snippet a developer pasted into the page header two years ago. Clean these up first, so that after migration each destination has exactly one loader.
5. Review field overrides on existing tags
List every tag that overrides configuration fields: suppressed page_views, a server container URL, custom parameters. Destination tags support the same kinds of overrides. You need to confirm they survived the conversion and still make sense alongside the new shared settings.
6. Decide what happens to the Conversion Linker
The Conversion Linker is now legacy because Destination tags handle its functionality. Don't leave it in place by default. Decide whether to retire it once the Ads and Floodlight destinations are linked, and test the result.
7. Plan permissions deliberately
The wizard asks whether to give Read access on the container to people with access to each Google Tag. Ahava recommends granting it, because access to a Google Tag without access to the deployment mechanism quickly becomes a handicap. We agree. Still, check the list of people who would gain access before you accept. Ad hoc destinations added without proper linking also miss out on shared permissions, so linking is better than bolting tags on.
8. Snapshot, migrate in a workspace, verify downstream
Publish or note the current container version so you have a clean rollback point. Run the wizard in a dedicated workspace and read Show details carefully. Then test in Preview mode. Preview is necessary, but it isn't enough on its own. It shows that tags fire. It doesn't show that the data arriving in GA4 matches what you had before.
Why clean collection matters more than ever
It's tempting to treat this as housekeeping. But more and more decisions now run on top of the data. Analysts query it, and increasingly so do automated agents and models. If a migration quietly doubles page_views or drops a consent-gated parameter, every layer above inherits the error. We've written about how decision models differ from text models in marketing automation, and the common thread is that a system that makes decisions is only as good as the signals feeding it.
The same goes for measuring the right things. A tidy container that tracks events no one uses is still wasted effort. While you're auditing, ask whether each tag supports a decision. Our piece on qualifiers versus determiners makes that argument on the messaging side, and it applies just as well to which conversions you bother to instrument.
If you manage many containers and are considering automating parts of this audit, such as inventorying tags or diffing settings across versions, model choice affects the economics. Our breakdown of how Claude Haiku 5.5 changes the math on high-volume marketing agents is a useful starting point for working out what that kind of repetitive work should cost.
The bottom line
The merged Google Tag and GTM experience is a genuine improvement. You get fewer resource loads, one place for settings and a cleaner permissions model. But the optimization wizard reflects the container it's given. Inventory your tags, settle the shared settings deliberately, remove duplicate loaders, check consent behaviour and verify the result downstream rather than trusting Preview mode alone.
If you'd like a second pair of eyes on your containers, or want help building GTM, GA4 and BigQuery pipelines and connecting them to Claude via MCP, talk to us at Bitegrico. We're glad to help you migrate without losing data along the way.