Google Tag Manager’s Cleanup Button Also Hands Out Account Access

Posted on
Analytics dashboard on a laptop screen showing measurement data

There is a banner sitting in Google Tag Manager right now offering to optimize your container. It looks like housekeeping. It is not only housekeeping.

Google published the details on 20 August, and most coverage has focused on the visible parts: a redesigned Overview page, a new Settings tab, Triggers and Variables tucked into a collapsible Advanced section, and visual tagging that lets you define a conversion by clicking an element on your site instead of writing a selector. All of that is fine, and some of it is genuinely useful.

Two other things in the same document will cost somebody a quarter of clean data.

The line worth reading twice

When you run the optimization flow, your container gets linked to your Google destination accounts automatically, and Read access is granted by default. Google says plainly in its own documentation that this makes the container visible and manageable inside the interface of other Google products.

If you run one business with one Google account, that is a convenience. If you are an agency, a freelancer, or a founder who has ever handed a contractor access to a Google Ads account so they could fix something, that is a permissions change you did not review line by line. Anyone with access to the linked Ads account can now see the tagging container.

You can adjust it afterwards through Tag Manager’s user management. Most people will not, because they will never know it happened. Approving a banner is not the same as reviewing an access list. This is the second time in a month that a tool has quietly widened what it can reach without anyone re-approving the access.

The change that will actually break something

Google tags are being upgraded into full Tag Manager containers. Sites that only ever deployed a Google tag get the whole Tag Manager interface: version control, debugging, the lot. Google is clear that in-page behaviour of existing tags does not change.

But new deployment snippets will not carry the gtag config command. Google recommends configuring initialisation through a gtm init trigger instead, and that trigger can be set to wait for the config command if you need a legacy setup to keep working.

Translate that into the real world. A site has a gtag implementation a developer customised in 2022. Nobody has opened it since. Someone pastes in a fresh snippet alongside the old one because the interface suggested it. Now you have a plausible route to double-counted purchases, or to conversions that quietly stop firing. Nothing in the interface will raise its hand about this.

An hour of work that saves a quarter

Before anyone clicks optimize:

  1. Export the current container version. Tag Manager keeps versions internally, but export it anyway. A file on your own drive is faster to read than a rollback under pressure.
  2. Screenshot the last 30 days of conversions, broken out by conversion action in Google Ads and by key event in GA4. This is your baseline. Without it you cannot prove anything changed, let alone what.
  3. Run the optimization flow but stop at the preview. Google lets you preview every change before publishing to your workspace. Read the diff properly rather than scrolling to the button.
  4. Publish, then compare the same conversion numbers 48 hours later against the baseline.
  5. Open user management and look at the account links the optimization created. Remove any that should not be there.

That is an hour. The alternative is discovering in October that September’s conversion data is not comparable to August’s, which is a much longer conversation with whoever signs off the budget.

What is genuinely good here

Not everything is a trap. The performance change is real: containers can now send data directly to Google destinations instead of loading gtag.js as an intermediate step, which removes a request from the page. If you have been fighting Core Web Vitals on a marketing site, that is a small free win you did not have to argue for.

Visual tagging is more interesting than it first sounds, although it is currently in beta and limited to purchase conversions in Google Ads. For a small business with no developer on call, being able to point at a checkout button and register a conversion removes a genuine blocker that has cost people months.

The risk is the predictable one. Point-and-click tagging makes it easy to track the wrong element, and easier still to end up with fourteen half-configured events that nobody named properly and nobody can now identify.

What I would not automate yet

Measurement setups do not fail loudly. They fail quietly, and you find out at the end of the quarter.

I would not run the optimization on a client container in the same week as a campaign launch. I would not run it at all on a container where the original implementer is unreachable, until someone has actually read what is inside it. And I would not treat “no changes will be made automatically” as permission to postpone forever, because opt-in changes at Google have a reliable habit of becoming defaults later.

This may not be worth prioritising at all if your entire setup is one GA4 tag and one Ads conversion action. In that case the container is simple enough to rebuild from memory. Click the button and get on with your day.

For everyone else, an hour of preparation is cheap. This is the kind of unglamorous operations work mark8ng.ai is being built around: fewer surprises in the systems that quietly decide what your reporting says.

Editor’s note: This area changes quickly, so check the latest platform policy before making compliance decisions.