"In the DevTools Network tab, the conversion request clearly goes out. Yet no conversion shows up in the dashboard." This is far more maddening than the simple case of a missing tag. Because you can see it firing, you assume the setup must be right — and you're left with no idea what to fix.
Does any of this sound familiar?
- You can clearly see the request to
…/pagead/conversion/…in the Network tab - And yet Google Ads conversions are zero, or obviously too low
- The event appears in GA4 DebugView but isn't recorded as a conversion
- Tag Assistant says "firing OK" but the number doesn't move
If your problem is broader — the conversion isn't firing at all, not just failing to record — start with No Conversions in Google Ads? A Step-by-Step Diagnostic Guide instead. This article has a single theme: "firing" (the browser sent it to Google) and "recording" (Google accepted and stored it) are two completely different stages. Seeing the send in Network is no guarantee that Google's side will store it. With that one idea as our axis, we'll isolate why "I sent it but it isn't recorded."
First principle: firing = sending, recording = accepting — and there's a "review" in between
The biggest reason people get stuck is assuming "the request went out = the conversion was captured." In reality, between the signal reaching Google and it being recorded, there's an "acceptance (review)" stage on Google's side.
| Stage | What happens | Where you can confirm it |
|---|---|---|
| ① Firing (send) | The browser sends a measurement request to Google | DevTools Network tab |
| ② Acceptance (review) | Google judges consent, exclusion, duplication, validity | Not directly visible (inside the platform) |
| ③ Recording (store) | Signals that pass review are stored as conversions | The conversion column in the dashboard |
The key point: all you can confirm in the Network tab is ①. The ② review happens inside the platform, and if it's rejected there, ③ never happens — no matter how perfect ① looks. In other words, "it fires but isn't recorded" almost always means something is rejecting it at the acceptance stage.
Below are the seven most common reasons it gets rejected at ②, described accurately.
Cause 1: Consent mode — no consent, so it isn't stored (it's modeled)
If you've deployed Consent Mode, the request itself still goes out (in fact, Consent Mode v2 is designed to send cookieless pings even without consent). So you genuinely see hits in the Network tab — but when the user hasn't consented to measurement, Google doesn't store that data as-is; it treats it as restricted or modeled.
- Firing (sending) is happening → so on your machine it "looks like it's going out"
- But if the
gcsparameter signals "no consent," the acceptance stage won't turn it into a normal record
This is the most textbook case of "fires but isn't recorded." For the full mechanism, see Why Consent Mode Makes Your Conversions Drop.
Common pitfall: when "the request goes out but the numbers don't add up," first look inside the request that's being sent (the parameter that signals consent state). "It's going out" does not mean "consent was granted."
Cause 2: Internal-traffic exclusion / data filters reject it at acceptance
If GA4's internal-traffic exclusion, a developer-traffic filter, or a Google Ads IP exclusion is active, the request is sent but discarded at the acceptance stage. The send succeeds yet nothing is recorded — so watching only the Network tab will never get you to the cause.
- Your or your office's IP is caught by a filter
- GA4's "internal traffic" rule (
traffic_type=internal) is set to exclude in a data filter
The tricky part: this is normal behavior. It's designed so that your own tests get dropped, so "it fires when I test but isn't recorded" doesn't mean anything is broken.
Common pitfall: when you hit the completion page on your own PC and "it goes out but isn't recorded," internal-traffic exclusion is the likely culprit. Don't conclude "it's broken" from your own excluded test.
Cause 3: Not registered as a key event / conversion
The event fires in GA4 and shows in DebugView. Even so, unless you've registered that event as a "key event (conversion)," it won't appear in the Google Ads conversion column. Everything is sent and received — the only thing missing is the setting that says "count this as a conversion."
- The event is arriving on the GA4 side (sending/receiving is fine)
- But it isn't marked a "key event," or isn't imported/registered as a conversion on the ad side
This is the prime suspect for "shows in GA4 but not in ads." Check the registration setting before you start doubting whether it's even being sent.
Common pitfall: if you relax the moment you see the event in DebugView, you'll miss this registration gap. "The event arrives" and "it's counted as a conversion" are two separate settings.
Cause 4: Wrong measurement ID / conversion ID
The request goes out, but the destination ID it's sent to (measurement ID, conversion ID, label) is wrong. Sending succeeds, so you can confirm firing — but the signal lands on a different property, a different action (or a nonexistent destination), not the conversion action you intended.
- An old / different-account conversion ID is left in the GTM tag
- You've mixed up the measurement ID (
G-XXXX) and the conversion ID (AW-XXXX) - A redirect or environment (production vs. staging) swapped the ID
Open the request contents in the Network tab and confirm that tid, the destination ID, and the label match the action you're looking at in the dashboard.
Common pitfall: when "it fires but the dashboard I'm watching doesn't move," it's often a mix-up — the firing request's destination ID and the action you're staring at are two different things.
Cause 5: Deduplication / falling outside the conversion window
If the same conversion is sent twice, Google's deduplication (dedup) won't record one of them. Conversely, results that occur too long after the click — outside the conversion window — aren't accepted even though they're sent. Both create a "sent but not recorded" state.
- The transaction ID is identical / the tag is double-installed, and one is dropped as a duplicate (see Duplicate Conversion Tracking: Causes and Fixes)
- The click-to-conversion span exceeds the configured window
The "ads and GA4 counts don't match" phenomenon can also stem from this dedup or window mismatch. For cross-platform count gaps, see Why Google Ads and GA4 Conversion Counts Don't Match.
Common pitfall: when "I see the send twice but only one is recorded," that may not be a fault — dedup is working correctly. Send count and record count are not always meant to match.
Cause 6: Excluded by bot / spam detection
To counter invalid traffic (IVT), Google excludes at the acceptance stage sends from bots, automation tools, and unnatural patterns. A request fired by a headless browser or automated test tool can show in Network yet never be recorded.
- Checks via automation tools / headless can be dropped as bot traffic
- A burst of sends from the same environment in a short time can look spammy
If "it fires in test automation but production records don't increase," consider that the test itself is being excluded. This, too, is normal defensive behavior.
Common pitfall: judging "it's going out in my automated test, so we're fine" misses the case where that send is bot-excluded and real-user recording is a separate matter. Verify under conditions close to a real user.
Cause 7: Reporting delay (don't mistake it for breakage)
Finally, a surprisingly common case: panicking when nothing is broken. Firing (sending) is visible in real time, but there's a delay before it reflects in the dashboard's conversion column (usually a few hours; the first one can take longer).
- Right after setup or swapping a tag, you decide "it fires but it's zero — broken"
- You start changing settings and break the healthy wiring instead
If firing is confirmed, the send wiring is alive. First wait a few hours to the next day and confirm whether it's still not recorded.
Common pitfall: don't conclude it's broken from a zero right after you confirmed "it's going out in Network." Once firing is visible, what remains is acceptance and reporting.
Cause 8: Attribution window mismatch between platforms
The tag fires and the conversion is real — but Google Ads doesn't record it because its attribution window has expired, or because you're comparing platforms with different window settings.
- Google Ads default: 30-day click-through window, 1-day view-through window
- Meta default: 7-day click, 1-day view (changed from 28-day in the iOS 14 era)
- GA4: Session-based or configurable, with different logic entirely
If your sales cycle is longer than 30 days, conversions that happen on day 35 will fire correctly but never appear in Google Ads. And if you're comparing conversion counts across platforms, mismatched windows explain discrepancies that look like tracking failures but aren't.
How to check: In Google Ads → Goals → Conversions → Settings, verify the attribution window matches your actual sales cycle. If your business has long consideration periods (B2B, real estate, high-ticket items), extend the window accordingly.
Cause 9: Cross-device conversion breaks
A user clicks your ad on their phone, researches on their laptop, and converts on their desktop. The tag fires on the desktop — but there's no cookie connecting this conversion to the original ad click on the phone.
Google tries to bridge cross-device journeys through signed-in user data (users logged into Google accounts across devices). But when users aren't logged in, or use different browsers, the journey fragments — and the conversion fires without being attributed.
What helps:
- Enhanced Conversions — matching via hashed email bridges the gap, because the email is the same across devices
- Server-side tagging — sends first-party identifiers that can persist across sessions
- Both approaches are covered in our first-party data strategy guide
Cause 10: Conversion counting setting discards the repeat
Google Ads conversion actions have a counting setting: "One" or "Every."
- "One": Only the first conversion per ad click is recorded. If the same user converts again (e.g., submits the form twice, reloads the thank-you page), subsequent fires are silently discarded
- "Every": Every conversion is counted (correct for e-commerce where each purchase is a separate transaction)
If you set "One" for a lead action and wonder why a second legitimate conversion from the same user doesn't appear — it's working as configured. Conversely, if you set "Every" for a lead action, you may see inflated counts from page reloads.
How to check: In Google Ads → Goals → Conversions, click the conversion action and check the "Count" setting. Use "One" for leads, "Every" for transactions.
So how do you actually check?
To verify "it fires but isn't recorded," you need to look beyond the ① send confirmation, into the conditions tied to ② acceptance.
- GA4 DebugView / Realtime: confirm the event is received via
debug_mode. But note: showing in DebugView ≠ conversion recorded (Cause 3) - Platform test tools: use Google Ads Tag Assistant and the like to confirm the destination ID and label are as intended (Cause 4)
- Read the contents of the sent request: open
gcs(consent state) andtid/label in Network — look inside "it's going out" (Causes 1 & 4) - Verify under production conditions: confirm under conditions close to a real user, free of internal exclusion, bot exclusion, and extension interference (Causes 2 & 6)
For the full isolation picture, see the Conversion Tracking Verification Checklist; to check the GA4 tag itself, see How to Verify Your GA4 Tag Is Working.
Verification checklist
- Did you open the contents of the sent request (destination ID, label,
gcs) in Network? - Does the destination ID (measurement ID / conversion ID) match the action in the dashboard you're watching?
- Under consent mode, is the no-consent case being treated as restricted/modeled?
- Are internal-traffic exclusion or data filters dropping your own test?
- Is the GA4 event registered as a "key event (conversion)"?
- Any double install / dedup, or falling outside the conversion window?
- Are you verifying via automation / headless and getting bot-excluded?
- If it's right after setup, did you wait out the reporting delay (a few hours to next day)?
What checking on your own machine can't tell you
Every check above is useful, but verifying once on your own machine has two structural limits.
- Your environment isn't your visitors' environment. Your PC differs from real users in login state, extensions, office-IP exclusion and more. The mismatch — "it fires on my machine" but it's rejected at acceptance under real-user conditions — is invisible to on-machine testing.
- It's hard to verify when an ad click is involved. To rigorously see "does it really record via the 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's going out on my action, so it's fine" tends to miss exactly the problem this article is about: firing is visible, yet it's missing at the real acceptance stage in production.
Frequently asked questions
Q. The request fires in the Network tab, but the conversion isn't recorded. A. Firing (sending) and recording (acceptance/storage) are different stages. Since sending succeeds, the cause is at acceptance. Work through this article's causes in order: 1 (consent mode), 2 (internal exclusion), 3 (key event not registered), 4 (ID mix-up), 5 (dedup), 6 (bot exclusion), 7 (delay).
Q. The event shows in GA4 DebugView but no conversion appears in ads. A. An event being received and it being "counted as a conversion" are separate settings. Register it as a "key event (conversion)" in GA4 and confirm it's imported as a conversion on the ad side (Cause 3).
Q. I see the send twice but only one is recorded. Is it broken? A. In most cases it's not a fault — dedup is working correctly. Check for a duplicated transaction ID or a double-installed tag (Cause 5).
Q. Why does it fire when I test myself but isn't recorded? A. Either you're caught by internal-traffic exclusion (normal behavior), or your automated verification is being bot-excluded (Causes 2 & 6). Verify under conditions close to a real user.
Q. If firing is confirmed, will it always get recorded eventually if I wait? A. Not always. Firing only proves "it was sent." Some cases reflect after a delay (Cause 7), but if it's rejected at acceptance, waiting won't record it. The reliable move is to check the contents of the send (consent, destination ID).
Conclusion: all you see is the "send" — recording is on the far side of acceptance
The truth behind "it fires but isn't recorded" is that all the Network tab shows is ① sending, with an invisible ② acceptance (review) stage beyond it. Consent mode, internal exclusion, unregistered key events, ID mix-ups, dedup, bot exclusion, delay — most reasons something isn't recorded hide at this acceptance stage.
That's why "it fires, so we're fine" isn't a verification. Confirming the signal passes acceptance and reaches recording — in production, on the real path your visitors take — is what "it's tracking" truly means.
ConversionOK runs your live page in an independent, isolated browser and intercepts the conversion signals actually sent — including their contents (consent state, destination ID) — then isolates where the chain breaks between firing and recording. 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.