GA4 events not showing: check what the tag actually sent

Updated 2026-10-09

A GA4 event is a request to a /g/collect endpoint that carries the measurement ID in tid and the event name in en. If that request leaves the page, the tag fired, and a missing event is a reporting or data question. If it doesn't, the tag or the page is the problem. First rule out the most common false alarm: Google says standard reports can take 24 to 48 hours, while the Realtime report usually shows events within minutes.

What a GA4 event looks like

Key	What it holds	Example
`tid`	The measurement ID the event goes to	`G-ABC123XYZ`
`en`	The event name, exactly as sent	`purchase`
`epn.value` or `ep.value`	The event value (`epn.` marks numbers, `ep.` text)	`79.00`
`cu`	The currency	`USD`
`ep.transaction_id`	The order ID of a purchase	`1001`
`pr1`, `pr2`…	Products, packed as `id…~nm…~pr…~qt…`	`idSKU-1~pr79.00~qt1`
`gcs` / `gcd`	Consent signals sent with the hit	`G111`

The checklist

You're looking too early. Google lists Realtime as typically a few minutes, intraday data as about 2 to 6 hours, and says processing can take 24 to 48 hours. Check Realtime or DebugView before deciding an event is missing.
The tag is waiting for consent. In consent mode's basic implementation, Google tags don't load until the visitor responds to the banner, and nothing is sent if they decline. In the advanced implementation, tags send measurements without cookies while consent is denied. Accept the banner and check again; the gcs and gcd keys show the consent signals each hit carried.
It went to a different property. Compare tid with the measurement ID of the stream you are viewing. In our study of 38 websites, 4 of 34 sent events to more than one GA4 property.
The requests go to your own domain. With Google's tag gateway (first-party mode), GA4 hits are sent to a path on your own site instead of Google's hosts, so a DevTools filter for google-analytics.com finds nothing. Pixel Debugger recognizes these first-party paths and decodes them as GA4.
Several events share one request. GA4 often batches events: one /g/collect request can carry several events, one per line of the request body. Looking only at the URL shows just one of them.
The page reloaded before the hit finished. Chrome cancels requests still in flight when a page reloads or navigates, and reports net::ERR_ABORTED. On the websites we checked, every failed GA4 request was a hit sent 26 to 74 milliseconds before a reload.
A browser extension blocked it. Ad blockers and privacy extensions stop the Google tag or its hits; Chrome reports net::ERR_BLOCKED_BY_CLIENT. Test without them.
The purchase is incomplete. Google's reference marks transaction_id, value, currency and items as required for purchase. It says currency is required whenever value is set, and that transaction_id helps avoid duplicate purchase events. A value without a currency is the case we see most; see GA4 purchase without currency.

A hit that left the browser shows what the tag sent. It does not show how GA4 processed, filtered or attributed it; reports and DebugView show that part.

How to check it with Pixel Debugger

Open your site, click the Pixel Debugger icon and go through the steps that should send the event.
In Events, find the GA4 row. Open it to see the measurement ID, the event name as sent, the value with the key it came from, the currency, the transaction ID and the products.
If a batched request carried several events, each one appears as its own row.
Nothing there? Setup shows whether the Google tag was found and which consent-mode commands the page issued, and Requests lists cancelled and blocked hits with Chrome's error.

When the hit is there but the report isn't

Wait for processing, and compare with Realtime for the same minutes.
Check the exact en: GA4 treats a differently spelled name as a different event.
For revenue, check that cu is present alongside the value.