GTM Container ID vs Product ID: Why Your Custom Tags Stop Firing

Some time in the last two months, a Google Tag Manager container you manage may have stopped running its custom tags. No error message. No red warning inside the container. No deprecation email to the address your client checks. The cause was not the container at all. It was the ID inside the loading snippet on the page.

On 9 July 2026 Google changed how Tag Manager decides what a container is allowed to execute, in a release note titled "Updates to container behavior for unsupported installation paths". Before that change, a container loaded through one of the Google tag's own endpoints could be pushed into a restricted state where only Google-provided tags and variables ran. Custom HTML, third-party templates, anything your team built, silently did not fire. The July release makes the rule explicit: the ID decides, the path does not.

What changed on 9 July

Unsupported installation paths are the endpoints that belong to the Google tag rather than to a GTM container: /gtag/js and /gtag/destination. If a container was loaded from one of those, it could degrade into restricted mode. Restricted mode allows only tags and variables provided by Google. Everything custom was skipped, and the page looked normal while it did it.

From 9 July the behaviour follows one rule, applied regardless of the path the container was loaded from:

• GTM-XXXXXXX ID in the snippet: the container runs unrestricted, with full functionality, on any path.
• Product ID in the snippet (G-XXXXXXX or AW-XXXXXXX): only tags and variables provided by Google run.

Installations that use Google's own snippets are unaffected either way, which is exactly why this goes unnoticed. Nothing about the container changed. Nothing in the Tag Manager interface reports the restriction. The only place it shows up is the network request.

The two IDs, and what each one allows

Every new Google tag ships with two identifiers, and they are not interchangeable:

• Container ID, GTM-XXXXXXX. The one you already know from the GTM interface under Admin, Install Google Tag Manager.
• Product ID, G-XXXXXXX for Analytics or AW-XXXXXXX for Ads. The identifier of the specific Google product the tag serves.

Deploy with the container ID and you get the full container: custom HTML tags, community templates, your own variables and triggers, everything you built. Deploy with the product ID and the container is deliberately limited to Google's own tags and variables. Custom HTML does not run. Neither does a template someone installed from the community gallery.

Google emailed administrators of significantly impacted containers, which is a useful line to remember when a client asks why they were not told. The email went to whoever was listed as a container admin, which is often the agency that set it up years ago, not the person now paying the invoices.

Why it goes unnoticed for months

Four things combine to hide the problem:

• The failure is silent. Tags do not throw errors when they are not allowed to run. There is nothing in the page console telling you a custom tag was skipped.
• The container still loads. Requests still go out. The tag is not broken, it is disallowed, and the two look identical from the outside.
• Google's own tags keep working. GA4 events and Google Ads conversions measured by Google-provided tags carry on, so the top-line numbers in the client dashboard stay plausible.
• Nobody looks at the loader. Most audits start inside the container, where the snippet is displayed but the version actually deployed on the site is not.

What usually breaks is the layer you built yourself: the custom HTML tag that fires a form submission to a CRM, the template that captures a scroll depth with extra context, the tag that pushes a value into a data warehouse. Those disappear from the data and nobody notices until someone asks why lead quality reporting went thin in August.

A five-minute check you can run on any property

Open the site in Chrome, open DevTools, go to the Network tab, and filter for googletagmanager. Then reload the page and read the requests.

• A healthy GTM installation loads /gtm.js?id=GTM-XXXXXXX.
• Requests to /gtag/js or /gtag/destination carrying a G- or AW- ID mean the container is running in restricted mode.

Cross-check it against the published snippet. In Tag Manager, go to Admin, then Install Google Tag Manager. The snippet shown there tells you which ID Google believes is installed. If the page is loading something different, you have found the gap.

Finish with Preview mode and Tag Assistant on the live page with consent granted. Preview tells you which tags fired. If a custom tag sits there with a status other than fired, and the container loaded from a gtag endpoint, you have your answer.

The gtag pattern that hides the problem

The most common shape of this is a page loading a container through gtag.js, like gtag('config', 'GTM-XXXXXXX'), because someone wanted Analytics and Tag Manager wired from one script. That pattern is legal, and after 9 July it behaves predictably.

The inverse is the dangerous one. If the page carries gtag('config', 'G-XXXXXXX') and the GTM container rides along on the same loader, the container inherits restricted mode. Before the July release a container in that state could also be forced into restriction by the path itself, even when the ID was correct. After the release, if the ID is a container ID, the full container runs no matter where it was loaded from. That means tags which have been dead for years can come back to life with no container change and no deployment. When that happens, expect duplicate pageviews, doubled conversions, or a sudden flood of events into a BigQuery export. Check the data layer before you celebrate the recovery.

When a restricted container is the right answer

The restriction is not a defect. Deploying the Google tag with a product ID is now a documented way to enforce a Google-tags-only policy on a site. For agencies working with clients who have security reviews, a DPA with a clause about third-party script execution, or a marketing ops team that keeps pasting unreviewed code into containers, a restricted container is the honest technical answer to a governance problem. Custom HTML means arbitrary JavaScript in the client's page. If the client never signed off on that, restricted mode is the control that makes the promise true.

It is not a consent solution. A container running in restricted mode can still fire Google tags, and those tags still depend on Consent Mode v2 signals and on your CMP to hold the line. Use it to constrain what can execute, not to satisfy a regulator. The two jobs are different, and conflating them is how a compliance review turns into an argument.

If your custom tags were affected, the fix is small

Work through it in this order:

1. Confirm the loader and the ID on the live page, using the network check above.
2. Decide the intended mode. Full container for sites where custom tags are expected to run. Restricted where the client wants Google tags only.
3. Switch the loading snippet to the container ID where you want full functionality, or keep the product ID where the restriction is deliberate. Do it in the site's template, not in a page-builder field that the next theme update will overwrite.
4. Re-test in Preview and Tag Assistant. Confirm the tags that should fire now fire, and that nothing new fires twice.
5. Check downstream systems: key events in GA4, conversions in Google Ads, and anything writing to a CRM, warehouse, or reporting tool. A recovered tag can create duplicate records as easily as missing ones.
6. Write the change into the measurement plan with the date and the reason, then flag the step change in the next report so the client does not read it as a spike in performance.

Put it on the onboarding checklist

Inherited containers are where this lives. Add one line to your handover audit and you will catch it before it costs a quarter of clean data:

• Which ID is loading, and from which path?
• Do the tags in the container match the mode the client thinks they are paying for?
• Are custom HTML tags present at all, and if so, does anyone own the review of what they execute?

That sits naturally next to the checks you already run on consent defaults, duplicate conversions, and PII in event parameters. Both belong in the same pass: the GA4 audit checklist covers the measurement side, and this covers the loading side, and neither is complete without the other.

The July release did not break anything by itself. What it did was remove the excuse. Container behaviour is now a decision you make explicitly, with an ID, in a snippet, on the page. Know which one you deployed, and you will never be the agency explaining a quarter of missing leads. If you have inherited a container you cannot fully explain, book a consultation and we will read the loader with you.