Why does the GA4 Measurement Protocol return a 204 success but the event or user data never shows up in reports?
Quick answer
A 204 No Content response from /mp/collect only means the HTTP request was received and syntactically parseable - it is not an acknowledgement that the event was valid, correctly attributed, or will survive processing. Payloads with a malformed client_id, a missing required field, an unregistered custom dimension, or a timestamp too far in the past can all return 204 and then vanish silently.
Why This Happens
The Measurement Protocol was built to be fire-and-forget: Google intentionally keeps the response minimal (status code only, no payload) so a slow validation pass doesn't block the caller. That design choice means the HTTP layer cannot tell you whether the event was actually good - it can only tell you the request was accepted for further processing.
The three most common silent-loss causes are a client_id or user_id that doesn't match GA4's expected shape (see the dedicated client_id page), an event timestamp (timestamp_micros) more than 72 hours in the past which GA4 will reject during processing even though collection accepted it, and required top-level fields (client_id, at least one events entry with a name) being present but empty or malformed in a way the collector doesn't hard-validate.
Fix It
Always test against the debug endpoint first
Before trusting any Measurement Protocol integration, send the exact same payload to https://www.google-analytics.com/debug/mp/collect (same query string and body as your real /mp/collect call). This endpoint returns a JSON body listing every validation issue instead of a bare 204.
Check timestamp_micros is within 72 hours and in microseconds, not milliseconds
A very common mistake is sending Unix time in milliseconds where GA4 expects microseconds - this makes the event look like it's decades old or in the future, and it gets silently dropped.
Confirm the API secret and measurement ID are for the same data stream
A mismatched pair (measurement ID from one stream, API secret generated under a different stream) can pass the request through without an auth error but never write to the property you're checking.
Verify every custom parameter is registered as a custom dimension
Unregistered parameters are stored in raw BigQuery export (if linked) but never populate the GA4 UI's standard reports - see the dedicated custom-dimensions page for the registration steps.
How To Verify It Worked
Run the same payload through the debug endpoint (/debug/mp/collect) and confirm validationMessages is an empty array. Any populated message - even one classified as a warning rather than an error - explains why the live endpoint's 204 didn't translate into visible data.
Once the debug endpoint is clean, send the real event with "debug_mode": true and check GA4 DebugView for it within a minute or two. If it appears there but never reaches standard reports after 48 hours, that's a separate processing-layer issue - see the DebugView-vs-reports page.
Still Not Fixed?
We audit and fix GA4 implementations for a living - if this doesn't resolve it, the next step is usually a full event-by-event audit.
Talk to a GA4 Consultant