How did it work?
Google Tag Manager’s always had this rule: certain container ID prefixes get full functionality, whilst others get locked down to Google-only tags.
This means a “GTM-XXXX” container can run anything you build into it. Whilst a “G-XXXX” or “AW-XXXX” container (the product-specific IDs used by GA4 and Google Ads) is only allowed to run tags and variables that Google itself provides.
Until now, that rule wasn’t just about the ID; it was also enforced by the loading path. Therefore, if you load a container through an unsupported path like “/gtag/js” or “/gtag/destination”, GTM will drop it into the restricted, Google-only state, regardless of the type of container it is.
Not anymore. The ID decides this now, not the path.
What was the problem?
Two things were going wrong under the old logic.
Firstly, legitimate “GTM-” containers were getting throttled for no good reason, just because they’d been loaded via a non-standard path. For example, custom migration scripts and legacy setups.
Secondly, and this is the bit the release note skates past, the same flaw ran the other way too. Because the restriction sat on the path rather than ID, a container that was only ever meant to have Google-only permissions could end up running completely unrestricted, just by loading through one of those same unsupported paths. This is arguably the more interesting half of this fix, even if Google doesn’t frame it as such. A container someone deliberately locked down to Google tags only could actually pick up full functionality through nothing more than an odd loading path.
Our take: the fix pros and cons
This is a sensible fix. Tying permissions to the ID rather than the path closes a real inconsistency and should have been in place from day one.
It’s worth flagging the governance angle: some organisations deploy with a “G-” or “AW-” ID on purpose, specifically to lock a container down to Google-only tags as a way of controlling what marketing teams or third parties can add to a site. Teams then rely on it for governance and compliance reasons. So, if any part of your setup was leaning on the old path-based loophole to get more out of a product ID than it was meant to allow, that will stop working now. We’d suggest checking anything running on a product ID with an unusual loading path: custom server-side proxying, migration scripts, anything that touches how the container gets loaded.
There’s a transparency gap too.
Google’s release note frames this as a fix regarding “how” GTM handles unsupported paths, without mentioning that this was, in effect, a permissions bug that could go either way. Fair enough, most people will never notice but in some use cases it is important.
If you’re not sure what this means for your own GA4 or GTM setup or want a hand putting it into practice, get in touch with 120Feet and we’ll work through it with you.
