QA Ultimate Stack
Delivered, blocked or warned: reading a hit's delivery verdict
A tag that fired is not proof the hit arrived. What each delivery verdict means, why an aborted beacon is usually fine, and why a page that sends nothing fails the run.
A fired tag isn't a delivered hit
Between GTM firing a tag and the endpoint receiving the hit, a lot can go wrong: a Content Security Policy refuses the connection, an ad blocker cancels it, a proxy returns an error, or the page unloads too early. The Network Requests Inspector gives every request a verdict based on what actually happened on the network.
| Verdict | When |
|---|---|
| Pass | A 2xx response: the endpoint received it |
| Fail | A 4xx or 5xx response, a request blocked by CSP or a blocker, or any other network error |
| Warn | A 3xx redirect, an aborted request, or no response before the wait ended |
| Fail (page) | The page sent no GA4 collect request at all, or the page itself errored |
A list of delivery verdicts: pass on 2xx, fail on 4xx, 5xx or blocked, warn on redirect, aborted or pending, and fail when nothing was sent.
What each status code usually points to
Client-side hits sent straight to Google almost always come back 204. When you see anything else, the cause is usually in your own setup, often the server-side endpoint or whatever sits in front of it:
- 302 or 307: the hit was redirected, typically from http to https, by a trailing-slash rule, or by a proxy. Most redirected hits still arrive, but fix the endpoint so it isn't needed.
- 403: something refused the request. On a server-side endpoint this is usually a firewall or bot-protection rule treating the hit as suspicious.
- 404: the path doesn't exist. Common after changing a custom loader or first-party path in one place but not the other.
- 5xx: the server-side container is down, overloaded or misconfigured. Every brand that routes through it loses data at once.
- Blocked: the request never left the browser: a Content Security Policy, an ad blocker or a network error.
- Pending: no answer arrived before the wait ended. If it happens repeatedly, the endpoint is too slow.
A table mapping 204, redirects, 403, 404, 5xx and blocked requests to their usual causes and verdicts.
Delivered is not the same as processed
A 2xx means the endpoint accepted the request. It doesn't mean GA4 will show it. Consent mode, data filters, internal-traffic rules and reporting thresholds all act after delivery. Delivery is the last link the QA stack can prove; if every hit is delivered and the report is still wrong, look at GA4's configuration next, starting with the GA4 Ultimate Stack.
Four steps: sent, delivered (what is checked), processed and reported (not proven).
Why an aborted beacon is a warning, not a failure
When a page is about to unload, after a form submit or a link click, gtag.js hands its last hits to the browser as beacons. The browser often reports these as aborted even though it delivered them after the page went away. Treating every aborted beacon as a failure would raise false alarms, so it's a warning. If that particular hit matters, confirm it arrived in GA4 DebugView.
Two panels: an aborted collect request at page unload, and what usually happened, with a note to confirm in DebugView.
A page that sends nothing fails the run
A page with zero GA4 collect requests is treated as a failure, not an empty result. Usually the container isn't installed on that template, consent blocked everything, or something on the test machine replaced the tag library (see When the test machine blocks tags). The run exits as failed if any request fails, any page errors, or any page sends nothing. That's what makes a scheduled run useful as an alarm.
A run across five pages: three delivered, one with zero collect requests and one blocked by CSP.
Read the page diagnosis before you blame the site
Every page in the results has a short diagnosis written in plain language, and it does the first round of debugging for you. For a page with zero hits, it separates the cases that need different fixes:
- No gtm.js or gtag.js request at all: the container isn't installed on this page template, or a script-src policy stopped it loading.
- The library loaded but no hit was sent: usually consent not granted, a trigger that needs an interaction (a click or scroll the test doesn't make), or a wait that's too short.
- The library isn't Google's: something on the test computer replaced it. See When the test machine blocks tags.
- Google requests blocked by the site's CSP, with the count and the directives involved.
- Analytics-related console errors, with a pointer to the Console tab.
A page diagnosis checklist for a page with zero collect requests: no library, library but no hit, library replaced locally, CSP blocks, and console errors.
Consent: the most common honest zero
The test opens each page as a brand-new visitor who hasn't accepted the consent banner. What happens next depends on how the brand implements Google's consent mode:
- Basic consent mode: Google tags don't load until the visitor accepts. Zero hits is the correct behaviour for a new visitor, not a break.
- Advanced consent mode: tags load and send cookieless pings with the consent state in gcd. You should see hits, but without a stored client id.
Know which mode each brand runs before you call a zero a failure. To test the consented journey, use a form test whose first step is a click on the banner's accept button.
Two panels comparing basic consent mode, which sends no hits before consent, with advanced consent mode, which sends cookieless pings.
ODDVX for Windows
From the page to the hit, proved.
Start free with one saved form, one page and one parity check. Premium adds batch runs, exports and scheduled QA.