"In GTM preview the tag fires perfectly, but on the live site nothing is tracked." If you use Tag Manager, this is the most common — and most confusing — pattern of all. A green (fired) preview makes you feel the setup is correct, yet the live site shows no numbers after publishing. And if you can't see where preview and production differ, you end up endlessly tweaking settings.
Does any of this sound familiar?
- The GTM preview shows it firing, but production isn't tracked
- You thought you published (Submit), yet the change isn't live
- Only specific pages or specific buttons fail to fire the tag
- In DevTools, the measurement request isn't even being sent
- Events never reach GA4 or Google Ads
This guide organizes what to check, and in what order, when GTM isn't tracking — into six common causes. Before you rebuild tags and triggers at random, work through them top to bottom.
First principle: "works in preview" and "works in production" are different
The biggest reason diagnosis goes wrong is treating a green (fired) preview as proof it works in production. GTM preview loads your unpublished, in-progress version into your own browser and runs it. So even when preview fires, that change isn't necessarily being served to real visitors.
First, get clear on which state you're actually looking at.
| State | Whose contents you're seeing | Tracked? |
|---|---|---|
| Preview (Tag Assistant) | The unpublished working version | Only your browser |
| Published (after Submit) | The published version of the container | All visitors |
| Unpublished edits | The workspace draft | Served to no one |
The key point: "fires in preview" does not equal "tracked in production." Causes 1–6 below are ordered from most common and easiest to isolate, following exactly from this gap.
Cause 1: You haven't published (Submit) the change
This is the most common and most overlooked. In GTM, creating and saving a tag or trigger doesn't push it live. It goes to production only once you hit "Submit" in the top right and publish a new version. Preview runs your workspace draft, so it fires without publishing — which is exactly why "works in preview but not in production" happens.
How to check: open the "Versions" screen at the top right of GTM and confirm whether your latest change is included in the "published version." If the timestamp of the "Published…" version predates your edits, you haven't published yet.
Common pitfall: the vast majority of "green in preview but zero in production" is this Cause 1. Don't stop at a firing preview — first confirm you pressed Submit and the change is in the published version. See also When a conversion fires but isn't recorded.
Cause 2: Trigger conditions don't match the real production situation
Whether a tag fires is decided by its trigger. If those conditions are even slightly off from the real page, it won't fire in production.
- URL condition mismatch: you built "Page URL contains
/thanks," but the live completion page is subtly different —/complete,/thank-you/, a trailing slash, or a query string (?id=...) - Click-element mismatch: the button's class or ID differs in production, or on an SPA (a site that doesn't reload between screens) the click element is swapped in dynamically
- Form-submit triggers: depending on the implementation, the standard form submit isn't detected, so it doesn't fire
How to check: in preview (Tag Assistant), see whether the trigger reads "Fired" or "Not Fired" when you perform the action. If Not Fired, reconcile the trigger's conditions against the real values (URL, click element).
Common pitfall: when "only a specific page isn't tracked," suspect the trigger's URL condition first. Copy the live URL and compare it character by character against the condition to be sure.
Cause 3: Wrong published version or container ID (GTM-XXXX)
Surprisingly common: the place you're looking at differs from the place that's live.
- Container ID mix-up: production embeds
GTM-AAAA, but you're editingGTM-BBBB(a test container, another site's, or a rebuilt one) — no amount of configuring will show up in production - Old code or double installation: old GTM code remains on the site, or multiple GTMs are installed twice and the one you didn't intend is running
How to check: open DevTools on the live page, search the source for IDs starting with GTM-, and confirm it matches the container ID you're editing. Also watch for more than one GTM- (double installation).
Common pitfall: the agency and the marketing team each install a different GTM, and "I set it up but nothing shows" drags on for weeks. First confirm the actual container ID present in the live HTML.
Cause 4: The tag is "paused" or unattached
Sometimes the tag itself is stopped.
- The tag is set to "Pause" in its configuration
- The tag has no trigger attached (with no firing condition, it can never fire)
- A dependency tag it relies on (a settings/initialization tag) isn't firing
How to check: in the GTM tag list, confirm the target tag has no pause icon and that its trigger field isn't empty.
Common pitfall: it's not rare to pause a tag for testing, publish while it's still paused, and leave it stopped. Review your tags' states in the list before publishing.
Cause 5: It's being blocked by consent settings
The measurement signal can be stopped just before it's sent. With GTM consent mode or an integration with a cookie consent banner, tag firing may be held or blocked while the user hasn't consented.
- Before the banner grants permission, the measurement tag waits or doesn't fire
- Measurement is restricted for users who chose "essential cookies only"
How to check: review the consent status in preview and see whether firing changes before vs. after consent. In production, confirm measurement runs once you actually grant permission on the banner.
Common pitfall: if "it works in preview (treated as consented) but not for real visitors," consent settings may be blocking it. It's easy to forget that you-in-preview are consented while many real visitors are not.
Cause 6: The variables (data layer) are empty
Even when a tag fires, if the payload is empty the measurement may not complete, or the values come through wrong. GTM reads amounts, order IDs, event names and so on from a handoff mechanism called the data layer. If that isn't populated in production, the tag fires but sends "no value."
- The tag fires before the site writes values into the data layer (a timing mismatch)
- The variable name is spelled differently on the site side vs. the GTM side
- In preview a developer set the values by hand, while production isn't populated
How to check: in the preview "Variables" and "Data Layer" tabs, confirm the target variable holds the value you expect at the moment of firing. If it's empty or undefined, review the site-side write timing and the variable name.
Common pitfall: an e-commerce purchase amount arriving as "0" or empty is almost always this data-layer timing or a variable-name mismatch. Cross-checking with verifying the GA4 tag and verifying a Google Ads conversion makes it easier to isolate.
Often overlooked: blocking triggers silently prevent firing
Even when a tag's firing trigger conditions are all met, GTM has a feature called blocking triggers (exception triggers) that can silently prevent the tag from firing. If someone added a blocking trigger — for example, to exclude internal traffic or specific pages — and its conditions match, the tag won't fire regardless of the firing trigger.
How to check: Open the tag in GTM, scroll past the firing triggers, and look for any blocking triggers listed below them. In preview, a tag that shows "Not Fired" despite all trigger conditions being green often has a blocking trigger overriding it.
Common pitfall: Blocking triggers are visually less prominent than firing triggers and easy to forget. If a tag mysteriously won't fire even though the trigger conditions look correct, check for blocking triggers before rebuilding the tag. This is also a common source of issues when conversions fire but aren't recorded.
The order to check whether GTM is the cause
Checking top to bottom gets you to the cause fastest.
- In the DevTools "Network" tab, is the measurement request being sent at all? (If not, it's a firing problem = Causes 1–4)
- In preview (Tag Assistant), is the target trigger Fired, and do the variables hold values?
- On the GTM Versions screen, is your latest change in the published version?
- Does the container ID (GTM-XXXX) in the live HTML match the one you're editing?
- With permission granted on the consent banner, does it fire and track in production too?
What checking on your own machine can't tell you
Checking Causes 1–6 is all useful, but previewing once on your own machine has two structural limits.
- Your environment isn't your visitors' environment. Preview loads an unpublished version into your browser, and your consent status, login state, extensions and cache differ from real visitors'. It may fire on your machine yet be missing under real visitor conditions (no consent, a different browser, an SPA navigation path).
- Conversions involving an ad click are hard to verify. To properly see "does it really track via an ad," you'd need to click a live ad to recreate the path — which carries the risk of an ad-policy violation as a self-click.
Judging "it fires in preview, so it's fine" tends to miss the problem of data going missing on the real path your visitors take.
Ad blockers and privacy tools: a production-only blind spot
A growing share of visitors use ad blockers, privacy-focused browsers, or tracking-prevention extensions that block GTM or the measurement requests it sends. This creates a gap that's invisible during your own testing if you don't use those tools.
- Browser extensions like uBlock Origin or Privacy Badger may block the
googletagmanager.comscript entirely, so GTM never loads - Privacy-focused browsers (Brave, Firefox with Enhanced Tracking Protection) may block outgoing requests to
google-analytics.comorgoogleads.g.doubleclick.net - Corporate firewalls or DNS-level blockers can strip tracking requests before they leave the network
What this means in practice: You won't see these blocked hits in GA4 or Google Ads — they simply vanish. There's no GTM-side fix for users who actively block tracking, but understanding this gap prevents you from chasing a configuration problem that doesn't exist. For more on how privacy tools affect measurement, see ad blocker and pixel blocking and Safari ITP conversion loss.
Tip: If your overall conversion numbers are lower than expected but the setup is confirmed correct through Causes 1–6, ad-blocker usage among your audience may explain part of the gap. Server-side GTM can recover some of this lost data by routing measurement requests through your own domain.
Rule out reporting delays before rebuilding
After confirming that tags fire correctly, don't panic if numbers don't appear immediately in GA4 or Google Ads. Reporting delays are normal and can mislead you into thinking tracking is broken.
- GA4 real-time report: Events typically appear within seconds to minutes, but standard reports can take 24-48 hours to fully process
- Google Ads conversions: New conversion actions may take up to 24 hours to start appearing, and the reporting window attributes conversions to the ad click date, not the conversion date
- Conversion linker: If the Google Ads conversion linker tag isn't firing, conversions may be tracked but not attributed to the correct campaign — see GCLID and click IDs for details
How to check: Use GA4's Realtime report (Reports > Realtime) to confirm events arrive within minutes of your test. For Google Ads, check the conversion action's "Last recorded" timestamp under Tools > Conversions. If the timestamp is recent, tracking works — the standard reports just haven't caught up yet.
Verification checklist
- You published (Submit), and the latest change is in the published version
- The trigger conditions (URL, click element) match the real production values
- The container ID (GTM-XXXX) in the live HTML matches the container you're editing
- The target tag isn't paused, and a trigger is attached
- With permission granted on the consent banner, it fires and tracks in production
- At the moment of firing, the data layer (variables) holds the expected values
- In DevTools "Network," the production measurement request is actually sent
For more, use the conversion tracking verification checklist as well.
Frequently asked questions
Q. It fires in GTM preview but isn't tracked in production. A. Most commonly, you haven't published (Submit) the change (Cause 1). Preview shows the unpublished version, so it fires without publishing. Next, suspect a production container ID that differs from the one you're editing (Cause 3), or consent settings blocking it (Cause 5).
Q. Only specific pages or buttons fail to fire the tag. A. A trigger-condition mismatch (Cause 2) is the prime suspect. Check whether the live URL's trailing slash and query, or the button's class/ID, truly match the trigger conditions — reconcile them while watching Fired/Not Fired in preview.
Q. The tag fires, but amounts and order IDs arrive empty. A. The variables (data layer) are likely empty (Cause 6). Check the timing at which the site writes values into the data layer, and the spelling of the variable name. Reading the firing-moment values in the preview "Variables" and "Data Layer" tabs is the reliable way.
Q. I thought I set it up — where do I check whether it's published? A. On the GTM "Versions" screen at the top right, confirm your latest change is included in the "published version." If the published version's timestamp predates your edits, you haven't published (Submit) yet.
Q. How do I confirm the container ID is right?
A. Open the live page, search the source in DevTools for GTM-, and see whether the ID that appears matches the container ID you're editing. If multiple GTM- appear, you may have a double installation.
Conclusion: confirm you published, then verify on the real path
"GTM not tracking" nearly always comes down to one of: ① not published (forgot Submit), ② a trigger-condition mismatch, ③ the wrong container ID, ④ a paused tag, ⑤ consent settings blocking, or ⑥ an empty data layer. Don't relax at a green preview — isolate top to bottom and you'll reach the cause without rebuilding tags at random.
But preview checks on your own machine have limits. Going further — confirming the data is actually tracked, on the real path your visitors take, in production — is what "it's tracking" truly means.
ConversionOK runs your live page in an independent, isolated browser and intercepts the tag measurement requests actually sent, then verifies them — with no need to click your own ad and no interference from your office environment. Start with a free static check to confirm the entry point of your measurement.