"We tested it. Everything fires." I hear this sentence on almost every audit, said in good faith, backed by a screenshot of Google Tag Manager's preview pane full of reassuring green. And then the property's purchase count disagrees with the shop by a margin nobody can explain.
Both things are true at once: the tags fire in preview, and the data is wrong. Because preview mode answers a much smaller question than everyone thinks it does.
What preview actually tests
GTM preview loads your site with a debugging layer attached and shows which tags fired on which triggers, in that browser session. It is genuinely good at its job. But look at the conditions of that session:
- It is your browser: no ad blocker, or an allowlisted one, on a machine where half the privacy features are off because you work in marketing.
- You granted consent, or your consent tooling recognizes debug mode and quietly waves you through.
- You are logged into everything, possibly on an internal IP that your filters treat specially.
- You tested the happy path, on desktop, on the current release, probably on a page you chose because it was convenient.
Preview answers: "can this tag fire under ideal conditions?" Production asks a different question: "does this tag fire for a stranger on an old Android phone, with a blocker, who clicked Reject All?" The distance between those questions is where your missing data lives.
The specific ways preview and reality diverge
Consent is the big one. In preview you test with everything granted; in production a real share of visitors declines, and their tags legitimately never fire. If nobody re-ran the tests in the declined state, nobody knows what your setup does for those users, which is both a data problem and occasionally the opposite one: tags that fire despite refusal, which is a compliance finding, not a bug.
Blockers are second. The preview badge does not simulate an ad blocker, so a tag that fires perfectly for you simply never loads for the blocking segment of your audience. Nothing in GTM will ever tell you this; only your capture rate against real orders reveals the size.
Then the long tail I keep finding in audits: triggers bound to CSS selectors that exist on desktop but not mobile; tags that depend on a dataLayer push which fires after the tag on slow connections; staging containers previewed and production containers never updated; single-page-app routes that preview fine on a hard load and break on the client-side navigation your users actually perform.
Every one of these passes preview. Every one loses data in production. That is the pattern: preview validates configuration, and configuration was never the thing you cared about. Collection was.
What "tested" should mean instead
A tag earns the word "working" when it clears three bars, in order of increasing honesty:
- Preview: fires on the intended trigger. Necessary, nowhere near sufficient.
- Production network tab: a normal browser session on the live site shows the request actually leaving, with the right values, on desktop and mobile, under both consent states. Ten minutes, catches the majority of what preview misses.
- Reconciliation: over a real period, the counted events land within your known gap of an independent source (orders, signups in the database). This is the only test that includes the users you cannot impersonate.
The full procedure with the exact checks is in how to verify GA4 tracking; it applies to any tag, not just Google's.
The organizational version of the bug
The deeper issue is that "configured" is a deliverable and "collecting" is not. Agencies hand over containers with preview screenshots, the invoice clears, and no one owns the question of whether production data arrives from real users. Six months later the numbers are quietly short, and the diagnosis costs more than the setup did.
If your tracking was ever declared done on the strength of a preview session, assume the gap between configured and collecting has never been measured, and measure it: one afternoon, shop orders versus GA4 purchases, same window. A stable small gap means you are fine and you can stop reading audits like this one. Anything else means the green checkmarks have been telling you a smaller truth than you thought you were buying, and finding the leaks is exactly the kind of work a tracking audit exists to do.