There is a specific, maddening failure mode in Google Ads conversion tracking: the tag appears to work. Tag Assistant shows it firing, the thank-you page loads, everything looks correct — and yet Google Ads records zero conversions, or far fewer than your CRM says happened. For a B2B SaaS account running Smart Bidding, this is not a cosmetic reporting gap. The bidding algorithm trains on the conversions it can see, so a tag that fires without recording is silently starving the system that sets your bids, and your effective CAC drifts upward while the dashboard insists nothing is wrong.
This is a hands-on debugging guide for that exact problem. Where our conversion tracking guide for SaaS covers what to track and why, this one covers how to open the browser and watch the request leave — using Chrome DevTools and Google Tag Assistant to find precisely where a "firing" tag actually breaks. We move from the fast checks to the deep ones: confirming the tag triggers, watching the network request, reading its payload, and testing the full click-to-conversion journey the way a real prospect experiences it.
The four places a firing tag breaks
Before touching DevTools, it helps to know what you are looking for. A conversion that fires but never records fails at one of four points after the trigger. First, identity mismatch: the conversion ID or label baked into the tag does not match the conversion action configured in Google Ads, so the hit arrives but maps to nothing. Second, transport failure: an ad blocker, a consent gate, or an iframe context stops the request before it reaches Google. Third, wrong-page firing: the tag fires during a redirect or on a page the user never fully reaches, so it triggers without a real conversion behind it. Fourth, missing click identifier: the GCLID never made it through the journey, so Google has a conversion event with no ad click to attribute it to.
Each of these leaves a different fingerprint in DevTools, which is why the browser is the source of truth rather than the Google Ads interface. The Google Ads UI only tells you the conversion action is "unverified" or "inactive" — it cannot tell you whether the request was blocked, malformed, or fired on the wrong page. By watching the actual network traffic you replace guessing with observation: you either see the request leave with the correct payload, or you see exactly how it fails. Knowing these four buckets in advance turns the debugging session into a checklist instead of a fishing expedition.
First pass: Tag Assistant
Start with Google Tag Assistant because it answers the cheapest question first — did the tag load and fire at all? Connect Tag Assistant to your site, complete a conversion (submit the demo form, finish the signup), and watch which tags fire on the confirmation page. Google's own Tag Assistant troubleshooting guide for unverified conversion actions is the canonical reference here. You are confirming one thing: the Google Ads conversion tag fires once, and only once, when the confirmation page loads. Zero fires means a trigger problem; multiple fires means you are about to double-count.
Tag Assistant is necessary but not sufficient, and understanding its limit is the whole point of this article. It reports that Google's tags recognised and triggered — it does not guarantee the resulting network request actually reached Google intact. A tag can show as "fired" in Tag Assistant while the request behind it is blocked by an extension, stripped of its click identifier, or malformed. That gap between "fired" and "received" is exactly where the firing-but-not-recording bug lives, and closing it requires dropping down to the network layer. If Tag Assistant shows the tag not firing at all, fix the trigger first; if it shows a clean single fire and conversions are still missing, move to DevTools.
Watch the request in the Network tab
Open DevTools (F12 or right-click, Inspect), select the Network tab, and make sure recording is on and "Preserve log" is checked so the log survives the page navigation to your thank-you page. In the filter box, search for the conversion endpoint — filtering on google, collect, or your numeric conversion ID isolates the relevant requests from the noise. Now complete a real conversion and watch. The single most diagnostic moment in this entire process is whether a request to Google's conversion endpoint appears in that list at the instant the conversion happens.
Three outcomes tell you three different things. If no request appears at all, the tag either did not fire or was blocked before send — cross-check against Tag Assistant to tell which. If a request appears but is cancelled or shows a blocked status, an ad blocker or consent tool is killing it in flight, which is common for the technical audiences B2B SaaS attracts. If the request appears and returns a successful status, transport is working and the problem is in the payload — which is where you look next. Reading the status column turns an invisible failure into a visible, categorised one.
Read the payload: ID, label, and GCLID
A successful request with no recorded conversion means the data inside the request is wrong, so open it. Click the conversion request in the Network list and inspect its Payload (or Query String parameters). You are verifying three things. The conversion ID and conversion label must match exactly what Google Ads shows in the conversion action's tag setup — a single transposed digit routes the hit to nothing. Check for a click identifier: a GCLID (or GBRAID/WBRAID) present in the request, or a first-party identifier if you use enhanced conversions. And confirm the conversion value and currency, if you send them, are populated rather than blank or zero.
A missing click identifier is the most common payload-level cause of "conversions that go nowhere," and it is a journey problem, not a tag problem. If the GCLID was dropped somewhere between the ad click and the form — stripped by a redirect, lost across a subdomain, or never captured into a hidden field — the conversion fires with nothing to attribute it to. That is precisely the failure our guide to passing the GCLID through your forms exists to prevent. Confirming the identifier is present in the actual network payload — not assumed to be there — is the check that separates a working setup from one that silently under-reports.
Blockers, consent, and iframes
If DevTools shows the request being blocked or never sent, the culprit is usually one of three environmental issues. Ad blockers target the exact Google domains conversion requests travel to, and B2B SaaS audiences — developers, security buyers, technical evaluators — run them at rates well above the general population, so a meaningful slice of your highest-intent conversions can be dropped before they leave the browser. Consent tooling causes a timing-shaped version of the same failure: if the consent banner script loads after the conversion tag, or gates it for non-consented users, the tag never sends and DevTools shows nothing at the moment of conversion.
Iframes are the third trap. A conversion or thank-you page rendered inside an iframe — common with embedded checkout, scheduling, or form widgets — often breaks tag firing, because the tag manager is not tracking correctly inside the frame. In DevTools you diagnose this by confirming the page context the request originates from. The structural fix for all three is to stop relying on the browser as the final hop: server-side tracking (sGTM) moves the send to your own infrastructure, where a client-side blocker cannot reach it and consent logic is enforced in one controlled place. DevTools tells you how much you are losing; server-side tracking is how you stop losing it.
Test the full click-to-conversion journey
The final and most-skipped step is to test the way a real prospect arrives, not from a bookmarked confirmation page. Testing only the thank-you page hides the two failures that matter most in production: a click identifier that gets lost in transit, and a tag that never fires because the user's real path differed from your assumption. Recreate the live journey — land on your site with an actual GCLID in the URL, then navigate naturally through to the conversion — watching Tag Assistant and the DevTools Network tab at every step to confirm the identifier persists and the tag fires exactly once on the true confirmation event.
While you are there, check for duplicate conversion actions, a quieter source of distorted numbers. If both a website tag and a GA4 import are set to count the same event as a conversion, you can double-count and mis-train bidding in the other direction. The end state you want is one clean fire, one intact request, one correct payload, one attributed click. Once DevTools confirms all four, your recorded conversions finally match reality — which is the precondition for the bidding system to optimise toward real pipeline and for the wider discipline of optimising for SQLs rather than raw leads to work at all. You cannot optimise for a conversion you never recorded.