What is actually happening
Google is replacing the GA4 Configuration tag in Tag Manager with the Google tag, rolling out from early September 2026. The details are in Google's own Tag Manager announcement, and it is worth reading rather than taking anyone's summary of it, this one included.
Most of the coverage has treated it as a rename with a slightly different settings panel. That is the part that is wrong.
Why rename is the wrong mental model
The GA4 Configuration tag configured one product. It loaded, it set up Analytics, and what it did began and ended there.
The Google tag is a shared configuration surface. One tag, one load, and settings that apply across more than one Google product at once. That is a genuine simplification and it removes a category of duplicated setup that used to cause its own problems.
It is also a coupling. Scope changed, not just the label.
What a migration does to settings, in any system
Three things happen in every migration, in every tool, regardless of vendor.
- Defaults get re-applied. Anything you never explicitly set becomes whatever the new thing's default is.
- Implicit settings become explicit ones. A behaviour you were relying on without configuring is now a value somebody, or something, chose on your behalf.
- The choice is recorded as if it were yours. Six months later nothing in the interface distinguishes a setting you decided from one a migration decided.
None of that is specific to Google and none of it is a criticism. It is what migrations are, and it is the part nobody reads the release notes for.
The ground this is landing on
Our Website Privacy Index scanned 47,505 public websites and scored 47,419, January to September 2026, across restaurant, hospitality and independent ecommerce sites. Of those:
- 23,307 (49.2%) ran Google tags with no Consent Mode signal at all.
- 2,108 (4.4%) showed a working Consent Mode v2 signal.
So roughly half of the sites in this sample that run Google tags are carrying no consent state in those requests, and have been for as long as the tags have been there.
Absent is a different failure from wrong
A wrong consent signal is visible. Somebody set a default to granted that should have been denied, and anyone who looks at the request can see a value they disagree with.
An absent signal produces a page where everything observable looks correct. The banner appears. The tags fire. The reports fill in. Consent parameters ride inside requests that were going out anyway, so a missing one does not break anything that renders, error or alert.
That is why a migration matters here. It is one of the few moments when a setting nobody ever chose gets chosen, and the outcome is invisible either way.
What coupling does to blast radius
When one tag configured one product, a settings mistake had one consequence, in one report, owned by one team.
When one tag configures several products, the same mistake propagates to all of them at once. Mechanically that is the whole point of the change and it is a real benefit when the setting is right.
We are describing what shared configuration means, not predicting that anyone will get it wrong. We have not measured migration outcomes and we are not going to imply we have.
Three checks, before yours happens
- Export the current container version and keep the file. Not because anything will go wrong, but because a diff is impossible after the fact if nobody kept the before. This is the same argument we made about keeping a change log you actually own.
- Open one Google request and read the full query string. Do this before and after. You are checking whether consent parameters are present at all, not whether the request fired. Those look identical in most tag debuggers.
- Enumerate which products the tag is now configuring, and who owns each one. If the answer to the second half is different people, the migration has just given them a shared dependency they do not know about.
The mechanics of the earlier stage of this migration are in our piece on the Google tag migration in GTM, and the publish-safety habit that catches this class of change is in the default workspace piece.
Who would notice
When the container version changes next month, who on your side will see it, and would anybody be able to say which settings moved? If the honest answer is that the container is administered elsewhere and nobody reviews the diff, the migration is not the risk. It is just the next thing that will happen without anyone watching.
Configuration moves between audits, which is the argument for watching it continuously rather than checking it once. That is what Managed Privacy does. For a single review of the whole tag layer, book a data and tracking audit.
Not legal advice. Rawsoft determines what a system technically does: which tags fire, when, under what consent state, and what data is transmitted. We do not determine which laws apply to your organization, how a regulator would read them, or whether your organization is in compliance. Those are determinations for your counsel. Everything above describes behavior an automated scan observed on public pages at the time of the scan, and nothing in it is a legal conclusion about any site.