Why most GTM containers are quietly broken (and the 4-step fix)
The median audited site scores 49 out of 100, and 95% fail Consent Mode v2. Here is what actually breaks in a GTM container, why nobody notices, and the four checks that catch it.
This post used to be called "Why 80% of GTM containers are quietly broken". We have changed the title, because our own data does not support that number — and we publish the data that shows it.
What was wrong with the old headline
We run a free public auditor and publish every aggregate result at /state-of-tracking. As of August 2026, across 1,757 audits, the score distribution looks like this:
| Band | Sites |
|---|---|
| 0–19 (broken) | 0 |
| 20–39 (poor) | 3 |
| 40–59 (mixed) | 1,098 |
| 60–79 (decent) | 247 |
| 80–100 (healthy) | 409 |
Three sites score in the "poor" band. None score "broken". Even counting every "mixed" site as broken — a stretch, since that band includes sites with working analytics and one or two real gaps — you reach 63%, not 80%. And 656 sites, 37% of the corpus, score 60 or better.
So the number was wrong. It was never derived from the corpus; it was a round figure that sounded about right, and it survived because nothing in the post ever had to justify it. A reader could refute our most-shared headline using a dataset we publish ourselves. For a company selling measurement accuracy, that is a worse problem than the missing citation.
We have left the URL alone so existing links keep working. Only the claim has changed.
What the data does support
Two figures hold up, and both are more useful than the one we removed.
The median audited site scores 49 out of 100. Not broken, not healthy: instrumented enough to produce numbers, flawed enough that some of those numbers are wrong. That is the harder failure mode, because a dashboard that is 80% right looks identical to one that is 100% right until someone reconciles it against revenue.
95% of audited sites fail Consent Mode v2. This is the most-failed check in the corpus, and unlike a composite score it is close to binary — the consent signals are present before the advertising tags, or they are not. If you run Meta or Google Ads in the EU or UK, that failure has direct billing and modelling consequences.
Every figure above is live at /state-of-tracking, and how each check is scored is documented on the methodology page. If a number in this post ever stops matching those pages, trust the pages — they are generated from the corpus, this text is not.
The four ways a GTM container quietly breaks
Across the corpus, the most common breakage is not "no GTM at all". Most sites have a container. The failures are subtler, and they share a property: nothing in the stack surfaces them.
Debug mode leaks to production
When a developer previews a container, GTM appends ?gtm_preview=env-3>m_auth=... to the script source. If those parameters survive into a published template, every visitor loads a preview environment. Tags fire against the wrong workspace, and the container you are measuring is not the container you shipped.
To spot it, search your homepage HTML for gtm_preview or gtm_auth. Either one means you are live in debug mode.
Two GA4 properties on the same page
A site adds GA4 directly through gtag.js for the marketing pages. Later, someone adds a second GA4 property inside GTM for the app. Now every pageview is counted twice, in two properties, under two attribution models — and the two dashboards will never reconcile, which usually gets blamed on "GA4 being weird" rather than on the duplicate.
Configured pixels that never load
Pixel IDs are collected during setup and saved. Then a GTM tag template gets deleted, paused, or has its trigger rewritten, and nothing reconciles the two states. Your configuration says the Meta pixel is live; the page disagrees. This is precisely the comparison our auditor makes — what you configured against what the live page actually loads.
Consent Mode v2 absent while ad pixels keep firing
This is the 95% figure. The advertising tags fire, the consent signals never do, and the ad platform quietly degrades your conversion modelling. Nothing errors. See the Consent Mode v2 walkthrough for the implementation detail.
The 4-step audit any team can run
- View source on your homepage. Search for gtm_preview and gtm_auth, then count the G- measurement IDs. More than one is a finding worth chasing.
- Open the network tab and filter by vendor. Confirm each pixel you believe is live actually issues a request. A loader script being present is not the same as a tag firing.
- Check that consent signals precede the pixels. A consent default should be set before any advertising tag loads. Order matters as much as presence.
- Repeat next quarter. Nearly every regression above arrives through a deploy that had nothing to do with tracking, which is why a one-off audit ages badly.
Our public auditor runs these four checks plus nine more against any URL, with no signup, and every result joins the dataset above.
Why teams find out late
GTM publishes whatever you tell it to publish, and never tells you when a tag stops firing. Drift arrives over weeks, in small pieces, from changes nobody associated with measurement. The first signal is usually a finance question — "why are Meta conversions down 30% this month" — asked long after the deploy that caused it, when the evidence has scrolled out of every log you keep.
That is the argument for continuous monitoring over an annual audit. It is also the argument for publishing your own numbers in the open: we found the error in this post's title because our dataset was public enough to contradict it.
FAQ
Is 80% of GTM containers being broken a real statistic?
Not one we can support. Our corpus of 1,757 audits shows 3 sites in the "poor" band and none in "broken". If you define broken as scoring below 60, the figure is 63%. If you define it as failing Consent Mode v2, it is 95%. The honest answer depends entirely on the definition, which is why we now publish the distribution rather than a single number.
What score should I be aiming for?
Above 60 puts you ahead of roughly 63% of audited sites, and above 80 puts you in the healthiest band, which is 409 of 1,757 sites. More useful than the composite is the individual check list: a site at 55 with working consent signals is in better shape than one at 70 without them.
How often should we audit a container?
Quarterly by hand is enough to catch the four failures above, because they arrive through deploys rather than through tag edits. If your release cadence is weekly or faster, hand auditing will always trail the regressions — that is the case for automated drift monitoring.
Does a low score mean my tracking is worthless?
No. The median site scores 49 and still produces broadly usable analytics. The risk is narrower than that and worse: specific numbers being wrong in ways nobody notices, such as duplicate pageviews inflating sessions or a purchase event arriving without revenue attached.
See where your tracking stands
Run the same 13-check audit referenced in this post against any URL. No signup, results in seconds.