GA4 Measurement Protocol Debug: Why 2xx Proves Nothing

The GA4 Measurement Protocol returns a 2xx status for almost anything you post to it: a valid event, a misspelt event, an event with no client_id, a secret you made up. So the status code is useless for debugging. To debug GA4 Measurement Protocol calls, send the same body to the validation server at /debug/mp/collect, read the validationMessages it returns, fix what it names, and only then confirm arrival in DebugView or Realtime.

That last step matters more than people expect. Why? The validation server doesn't check your API secret, so a payload can pass validation, get a 204 from the real endpoint and still never land in your property, and I've watched a team lose a week to exactly that before anyone thought to copy the secret again.

If you're wiring server-side events to track campaigns, the cornerstone guide on tracking UTMs end to end covers what should be in the link before any of this. This post is about the moment you send the event and nothing shows up.

Why the Measurement Protocol Answers 2xx to Everything

Google's protocol reference is blunt about it: the endpoint returns a 2xx status code if the HTTP request is received, and it doesn't return an error if the payload is malformed or the data isn't processed. Collection is fire-and-forget. Your server never waits on processing.

We checked this ourselves. A POST to /mp/collect with the body {"garbage":true}, a fake measurement ID and a made-up secret came back as HTTP 204 with an empty body. Same as a perfect event.

Retry logic keyed on status codes catches network failures. Nothing else. It can't tell you that GA4 dropped your events. For that you need the second endpoint.

How to Use the Validation Server at /debug/mp/collect

The measurement protocol validation server sits on the same host. Same query string, same body:

curl -s -X POST \
  "https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXXXX&api_secret=YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"events":[{"name":"session_start","params":{"firebase_x":1}}]}'

It answers 200 with a JSON body instead of an empty one. That test payload has three problems, and the server reports the first one it hits:

{
  "validationMessages": [
    {
      "fieldPath": "client_id",
      "description": "Measurement requires a client_id.",
      "validationCode": "VALUE_REQUIRED"
    }
  ]
}

Add a client_id and it moves on to NAME_RESERVED for session_start; rename the event and the firebase_ prefix is next. Each message carries a fieldPath, a human description and a code. The codes Google documents include VALUE_INVALID, VALUE_REQUIRED, NAME_INVALID, NAME_RESERVED, VALUE_OUT_OF_BOUNDS, EXCEEDED_MAX_ENTITIES and NAME_DUPLICATED.

An empty array, "validationMessages": [ ], means the structure is fine. Nothing sent to /debug/mp/collect is stored. Hammer it during development as much as you like; just remember a debug call never proves that data arrived.

What the Validation Server Does Not Check

Most tutorials skip this part. Google's validating events page says outright that the validation server does not validate the api_secret. In our test on 22 September 2026 it didn't check the measurement ID either: G-FAKE123 with the secret nonsense returned an empty validationMessages array.

A wrong secret passes. So does a revoked one, one from another data stream, or a typo in G-. The measurement protocol api_secret is the most common reason I see for "valid payload, no data", and you can only confirm it by seeing an event arrive.

The second gap is the validation mode. By default the server runs in RELAXED mode, and in that mode it let through two things Google's own limits forbid: an event with 26 parameters, and a parameter value of 120 characters. Add "validation_behavior": "ENFORCE_RECOMMENDATIONS" to the debug body and both fail, with EXCEEDED_MAX_ENTITIES and VALUE_TOO_LONG. I'd always validate in the strict mode, even if production stays relaxed. It's the difference between a checker and a rubber stamp.

Seeing Server Events in GA4 DebugView and Realtime

Once the payload validates, send it to the real endpoint and watch it land. Two views work for server events, and standard reports aren't one of them, since they can trail by 24 to 48 hours.

DebugView needs an opt-in per event. Google's verification guide asks for "debug_mode": 1 (or true) in the event's params plus a positive engagement_time_msec. Only events carrying the flag show up, so a batch where one event lacks it looks half-empty. Open Admin, then DebugView, and give it a minute.

Realtime needs nothing extra. Scroll to the "Event count by Event name" card and look for your event. Google notes that session_id and engagement_time_msec matter for user activity showing up in Realtime, so if an event validates but Realtime stays empty, check those two first.

One more caveat from the same guide: for web streams it says a valid event uses a client_id that gtag.js has already used. Synthetic IDs still get counted, each as its own user, but they never join a browser session, and in a report built around sessions that shows up as a long tail of one-event users you can't explain until you know where they came from. More on that in the next section. If what's missing is campaign data rather than events, UTM parameters not showing in GA4 walks the DebugView side of that problem.

Common Payload Errors and What the Validator Says

Most broken events fall into a handful of patterns. Here they are with what the validation server returned when we sent each one on 22 September 2026:

Two rows deserve a comment. The ga_ prefix is reserved according to the reference, yet the validator accepted ga_session_id in both modes when we tried it, so don't treat an empty array as permission. And the 100-character value limit catches full destination URLs all the time: a landing page with five UTM tags is often longer than that.

The client_id itself is the subtle one. Any string passes relaxed validation, but strict mode rejected both c1 and elido-12-4711 with "It should be in . format". If your events must stitch to browser sessions, send the real _ga value; the GA4 server-side tracking guide explains that stitching in detail.

How Elido's GA4 Forwarder and Test Connection Use This

Elido forwards short-link clicks to GA4 server-side. You paste a Measurement ID and a Measurement Protocol API secret into the GA4 card under Integrations, and from then on every click in that workspace becomes one link_click event:

{
  "client_id": "elido-12-4711",
  "events": [
    {
      "name": "link_click",
      "params": {
        "workspace_id": 12,
        "link_id": 4711,
        "slug": "spring-26",
        "country": "DE",
        "device": "mobile",
        "destination": "https://shop.example/spring?utm_source=newsletter",
        "engagement_time_msec": 100
      }
    }
  ]
}

The client_id is elido-<workspace>-<link>, so every click on one link reads as the same GA4 user and none of them joins a browser session. That's the honest trade-off of doing this without a cookie: totals, and breakdowns by slug, country and device, work; user counts and session funnels don't. Country and device are plain event parameters. Register them as custom dimensions first. And a destination over 100 characters runs into the limit from the table above, so report on slug or link_id instead.

The Test connection button follows the order this article recommends:

First it sends a synthetic link_click, flagged with elido_test: true, to /debug/mp/collect. If validationMessages isn't empty, the test fails and shows Google's descriptions verbatim. If the array is empty, the same event goes to /mp/collect for real. Under the button you see the vendor response (HTTP status, the debug endpoint with your measurement ID but never the secret, and Google's body) plus a note saying the Measurement Protocol doesn't verify the API secret.

So green means "valid, and Google got it". Not "your property has it". The test event carries debug_mode: 1 and elido_test: true, so it shows up in DebugView as link_click; Realtime works too. If you'd like click events in GA4 without a tag on every landing page, start a workspace and point the GA4 card at a test property first.

A GA4 Measurement Protocol Debug Order That Works

When GA4 events are not showing, work through it in this order and stop at the first failure:

1. Send the body to /debug/mp/collect with validation_behavior set to ENFORCE_RECOMMENDATIONS. Fix every message.
2. Copy the API secret again from Admin, Data streams, your web stream, Measurement Protocol API secrets. Check it's from the same stream as the G- ID.
3. Send one event to /mp/collect with debug_mode: 1 and watch DebugView for two minutes.
4. Remove the flag and check Realtime, then give standard reports a day or two.

Step 2 is where most of my own debugging ends. Google's troubleshooting page opens with the same three questions: right secret, still valid, copied exactly. When the numbers finally flow and still don't match your link counts, short-link clicks versus GA4 sessions explains the gap, and server-side conversion tracking covers the conversion events that usually follow. The same validate-then-verify habit applies to the other destinations on the conversion tracking page.

Related on the Blog

• GA4 server-side tracking via redirects - credentials, payload shape and client_id stitching.
• Mixpanel vs GA4 for link analytics - which tool should hold your click data.
• Mixpanel link tracking - the same forwarder pointed at Mixpanel, with its own 200-for-anything quirk.
• UTM parameters not showing in GA4 - the campaign-data version of this debugging problem.
• Server-side conversion tracking - GA4, Meta CAPI and TikTok side by side.