Google has started rolling out a new tagging experience in Tag Manager. Every container now works as a Google tag in its own right, and your GA4 properties, Google Ads accounts and Floodlight configurations become "destinations" added straight to the container.
It's the biggest structural change to Tag Manager in years. It's opt in, nothing changes until someone clicks the banner, and for most sites it's worth doing carefully. Here's what it changes.
The container is now the Google tag.
Until now, sending data to GA4 from Tag Manager meant a Google tag inside the container, and that tag loaded its own copy of Google's tag library, gtag.js, on top of Tag Manager's. Each extra Google tag could mean another library.
After optimising, the container sends data directly to its Google destinations, with no separate gtag.js for each one. Google's reason is speed, and it's a real one: fewer scripts on every page view.
Destinations and the new tag types.
A destination is a GA4 data stream, a Google Ads account or a Floodlight configuration linked to the container. Each is handled by a new destination tag: Google Analytics, Google Ads or Google Floodlight.
Destination tags are consent aware, and each can still override individual fields, such as switching off the automatic page view or sending through a server container.
The old Google tag and the Conversion Linker tag are now marked legacy. They keep working, but a legacy Google tag still loads its own library, and the destination tags take over the linker's job.
One set of settings for every destination.
The new Settings section holds what used to be repeated in every Google tag: consent defaults, user-provided data collection, first-party data, automatic event detection, and how data is transmitted before consent. Settings are versioned and only go live when the container is published.
A destination can override a shared setting only to make it stricter, never looser. If the container blocks user-provided data, no linked Google Ads destination can switch it back on.
The data transmission setting is new and useful. It can hold Google hits until consent is given and then send them, or block advertising requests outright until ad storage consent is granted. It only applies to Google's own tags, so Meta, TikTok and the rest still need their own consent rules.
Who gets access.
Optimising links the container to each destination's account, and by default anyone with access to those Google tags gets Read access to the container. It only works one way: Tag Manager users don't gain access to the GA4 or Google Ads accounts. You can change it afterwards under the container's external account links.
What doesn't change.
Google says event tags and triggers are kept, nothing is changed automatically, and every change can be previewed before it's published. If something goes wrong, rolling back is the same as for any other change: publish the previous container version.
Should you do it?
For most containers, yes. The speed gain is free, and one place for consent settings is easier to keep right than five copies of them.
The risk is in the shared settings. A container sending to two GA4 properties with different settings has to pick one set for both, and a destination you don't administer, such as an agency's Floodlight, stays a legacy tag. Take it slowly on a busy container, and use the step-by-step checklist before you click.
The banner is the start of a series of changes Google has been making since August, which also includes the gtag.config event that now exposes stray config calls on the page.
If you'd rather someone else checked the result, that's routine Tag Manager work for Marc, and consent behaviour after the change is covered in his Consent Mode service.
Sources: Google's Tag Manager Help announcement and optimisation guide, and Simo Ahava's walkthrough.