Debugging GTM Conversion Tags: A Complete Troubleshooting Guide

The tag fires green in Preview Mode. Google Ads shows zero conversions. You have probably lost an afternoon to that exact gap, and most troubleshooting guides will not help you, because they start debugging in the wrong place.

I have debugged GTM conversion setups for years, and the single most common mistake is this: people start at the tag. Is the trigger right, is the conversion ID correct, is the label pasted in. All reasonable questions. All step three of a four-step problem. By the time you are inspecting the tag, you have already skipped the two places where conversions actually go to die.

Here is the honest read. A GTM conversion tag failure is rarely a tag failure. It is usually an upstream failure. The container script never loaded, or it loaded but the trigger never fired, or the trigger fired but consent state suppressed it. The tag itself, the thing everyone debugs first, is fine more often than not.

This is not a "12 reasons your tag is not firing" post. This is a layered diagnostic tree. We go in order: did GTM load, did the trigger fire, did the tag fire correctly, did the ad platform receive it. Work it top to bottom and you stop guessing.

And there is a deeper point here that conversion debugging usually misses. Even a perfectly working tag can only report what reaches it. If the container is blocked for a third of your visitors, no amount of tag debugging recovers those conversions. The real fix for that is architectural, first-party collection that does not depend on a fragile third-party container, and that is what DataCops is built around. We will get there. First, the tree.

Quick stuff people keep asking

Why is my GTM conversion tag not firing? In rough order of likelihood: the GTM container itself did not load, the trigger conditions were never met, consent state blocked the tag, or there is a genuine misconfiguration in the tag. Debug in that order. Most people debug in reverse and waste hours.

How do I use Preview Mode to debug conversion tags? Connect Tag Assistant to your site, reproduce the conversion, and watch the event stream on the left. Click each event and check the Tags tab: did your tag move into "Tags Fired" or stay in "Not Fired." If it did not fire, the Triggers tab tells you which condition failed. Preview Mode answers "did it fire and why," not "did Google receive it."

Why does my tag fire in GTM but not record in Google Ads? This is the classic one. Preview Mode confirms the tag fired from your browser. It cannot confirm Google accepted it. The usual causes: wrong Conversion ID or label, the conversion action is still in "Unverified" or "Inactive" state in Google Ads, the request was blocked by an ad blocker or consent gate, or you are inside the conversion's attribution window for fresh data lag. Preview Mode being green does not mean Google said yes.

How do ad blockers prevent GTM conversion tags from firing? Blockers like uBlock Origin and the built-in shields in Brave target the GTM container by its standard hostname and the ad-platform endpoints by domain. If the container is blocked, nothing inside it runs, so every tag fails at once. If only the platform endpoint is blocked, the tag "fires" in Preview Mode but the network request dies. Real-world block rates land around 30 to 40% of sessions for the container.

How do I debug with Tag Assistant? Tag Assistant is the engine behind GTM Preview Mode now. Same tool. Use it for the event-by-event tag firing view. The legacy Tag Assistant Chrome extension is mostly gone, so do not chase it.

Why do GTM tags fire multiple times or duplicate? Usually the trigger is too broad. A "Page View" trigger on a tag that should fire on "Purchase," or a History Change trigger on a single-page app firing on every route change, or the tag installed both natively and through GTM. Duplicate conversions inflate your count and quietly corrupt the data feeding your bidding.

How does Consent Mode affect conversion tag firing? With Consent Mode v2, tags wait for a consent signal. If the user has not consented, or the consent default never resolves, an ad-storage-gated conversion tag will not fire. On SPA transitions there is a real race: the route changes and the trigger evaluates before the CMP has written the consent state. The tag checks, sees no consent, and skips. Reload the page and it works, which makes the bug maddening to reproduce.

How do I verify my conversion setup end to end? Four checkpoints, in order. One: GTM container loaded. Two: trigger fired in Preview Mode. Three: tag moved to "Tags Fired" with correct values. Four: the conversion appears in the ad platform after its data lag. A green checkmark at step two is not a working setup. Only step four is.

The gap: you are debugging step three of a four-step problem

Most guides open at the tag. The tag is step three. Here is the full tree, and the SOP this exposes is Layer 3, the third-party container script being the fragile link in the whole chain.

Layer one: did GTM even load. Before any trigger or tag can run, the container script has to download and execute. Three things stop it. Ad blockers and Brave shields block the container by hostname for an estimated 30 to 40% of sessions. A Content Security Policy header without the right script-src allowance silently refuses to run it. And mixed content, an HTTPS page trying to pull anything over HTTP, gets killed by the browser. If the container did not load, every tag fails simultaneously and Preview Mode will not even connect. Check the Network tab for the container request and check the console for CSP errors. Start here. Always.

Layer two: did the trigger fire. Container loaded, now the trigger has to evaluate true. Form-submit triggers fail when the form does not cause a real submit event, for example a JavaScript handler that does a fetch and never fires submit. SPA route changes need a History Change trigger, not Page View, and a plain Page View tag will simply never fire on an in-app navigation. Then there is the Consent Mode race condition. On an SPA transition the trigger can evaluate before the CMP writes consent state. The trigger fires, the tag checks consent, sees nothing, and skips. In Preview Mode you see the event but the tag sits in "Not Fired."

Layer three: did the tag fire correctly. Now you are at the tag, and now the usual checklist applies. Wrong Conversion ID or label. Conversion value pulling from a variable that is undefined at fire time. The tag firing more than once because the trigger is too loose. This is real, this matters, it is just not where you should have started.

Layer four: did the ad platform accept it. The tag fired and sent the request. Separate question: did Google or Meta accept it. The conversion action might still be "Inactive" or "Unverified" in Google Ads. The conversion label might be stale from an old action. The platform endpoint itself might be blocked even when the container was not. Or you are simply inside the reporting lag and the data has not surfaced yet. Preview Mode cannot see any of this. You have to check the platform side directly.

Walk those four in order and you will find the failure instead of guessing at it.

Why a perfect tag still loses conversions

Here is the part the diagnostic tree exposes that no checklist will fix. Suppose you nail all four layers. Container loads, trigger fires, tag is configured perfectly, Google accepts every event. You are still losing conversions, and the loss is structural.

The GTM container is a third-party script. For the 30 to 40% of your visitors running a blocker or Brave, it does not load at all. For those people, layer one fails before layers two, three and four ever get a chance. There is no tag fix for that. The tag is downstream of a script that never executed.

Then there is what does get through. Of the traffic that loads your container and fires your tags, a meaningful slice is not human. Invalid-traffic estimates put bots at roughly 24 to 31% of collected web traffic. Bots execute JavaScript. They trip your triggers. They fire your conversion tags. A perfectly debugged GTM setup will cheerfully record a bot's form submission as a conversion, because GTM has no idea who is human.

So the data you are debugging toward is contaminated from two directions. Real humans missing because the container was blocked. Fake conversions present because bots fired the tags. And that blended dataset is what flows to Meta and Google as training signal. The platforms learn from it. They optimize toward the pattern in it. Garbage in, garbage optimized, garbage out, and your ROAS drifts down while every tag in your container shows green.

This is why debugging the container can only ever get you so far. The container is the wrong foundation. The fix is architectural: collect conversions first-party, from your own subdomain, far more resilient to blockers than a third-party container. Filter non-human traffic at ingestion, before the event is counted, scored against a large IP intelligence database. Keep two separated data tiers so anonymous analytics and identifiable conversion data never get blended into one undifferentiated stream. Clean, deduplicated events go to the ad platforms through server-side CAPI. That is the DataCops model. SignUp Cops handles the identity layer for signup and form conversions specifically.

To be plain about limits: DataCops is a newer brand than GTM, and SOC 2 Type II is still in progress, so a compliance-driven buyer may want that finished first. It also does not claim to catch 100% of bots. What it does is stop your conversion data depending on a script that a third of your visitors block, and stop counting bot events as human ones. That is a different and better foundation than debugging a fragile container forever.

Decision guide

Tag is green in Preview Mode, Google Ads shows zero: Jump to layer four. Check the conversion action status in Google Ads and check whether the platform endpoint is blocked. Stop re-checking the tag.

Tags work on full page loads, fail after in-app navigation: Layer two. You need a History Change trigger, and you are probably hitting the Consent Mode race on SPA transitions.

All tags stopped firing at once: Layer one. The container did not load. Check Network for the container request and the console for a CSP error.

Conversions are roughly double your real orders: Layer three, duplicate firing. The tag is installed twice or the trigger is too broad. Also check whether bots are padding the count.

Tags fire fine for you but conversions are lower than expected at scale: That is the structural loss, not a bug. Container blocking plus bot contamination. A tag fix will not recover it.

You are rebuilding tracking from scratch: Do not rebuild on a third-party container alone. Start first-party and server-side so layer one stops being a coin flip.

You cannot debug your way out of the wrong foundation

The mistake I see people make is treating every missing conversion as a bug with a fix. Find the broken setting, correct it, conversions return. Sometimes that is true. The trigger was wrong, you fix the trigger, done.

But a large share of your missing conversions are not bugs. They are the foundation working exactly as designed. A third-party container that a third of your visitors block. A tag layer that counts any JavaScript-executing visitor, bot or human, as a conversion. You can debug that setup until it is flawless and it will still leak real humans and still count fake ones. Flawless is not the same as accurate.

So after you have walked the four layers and fixed what is genuinely broken, ask the harder question. Of the conversions you are not seeing, how many are a misconfiguration you can fix, and how many are the architecture itself? Because one of those is an afternoon in Preview Mode, and the other is the reason your numbers will never quite add up until you change the foundation.

When your tag fires green and Google still shows nothing, are you sure the problem is the tag?