GA4 Measurement Protocol: send an event and debug it

What you need for the first request

An app stream uses firebase_app_id in the URL and app_instance_id in the body in place of the first and third rows. The protocol accepts only POST requests. For data collected in the EU, use region1.google-analytics.com as the host.

Never put the api_secret in code that runs in a browser. From a browser, send events with the Google tag or Tag Manager instead, as in how to set up GA4 tags with Google Tag Manager.

A request that works

curl -X POST 'https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXXXX&api_secret=API_SECRET' \
  -H 'Content-Type: application/json' \
  -d '{
  "client_id": "1234567890.1700000000",
  "events": [{
    "name": "purchase",
    "params": {
      "transaction_id": "T-1001",
      "value": 49.9,
      "currency": "EUR",
      "session_id": "1700000000",
      "engagement_time_msec": 100,
      "items": [{"item_id": "SKU-1", "item_name": "Test item", "price": 49.9, "quantity": 1}]
    }
  }]
}'

Send transaction_id with a purchase so a retry does not create a duplicate; the failure is described in duplicate transactions in GA4. Google says to include session_id and engagement_time_msec: without them, events may still appear in some reports, but they do not count correctly toward metrics such as average engagement time or engaged sessions.

This request returns 204 and no body, whether or not it is valid. Do not read that as success.

Check it on the validation server first

Send the same body to the same path with /debug in front of mp/collect:

curl -X POST 'https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXXXX&api_secret=API_SECRET' \
  -H 'Content-Type: application/json' \
  -d '{ ...the same body... }'

The response for the request above is:

{ "validationMessages": [] }

An empty array means the validator found no problem. Events sent to it do not appear in reports. Google says to leave validation_behavior out in production, to keep rejections down.

Google recommends strict checking in development, and it matters more than the recommendation suggests. These mistakes were each sent to the validator twice, once as written and once with "validation_behavior": "ENFORCE_RECOMMENDATIONS", using a made-up measurement ID and secret:

In default mode the validator reported three of these ten. If you test without the flag, a payload that breaks the length and count limits comes back clean.

A full response looks like this, for an event named first_visit:

{
  "validationMessages": [{
    "fieldPath": "events",
    "description": "Event at index: [0] has name [first_visit] which is reserved.",
    "validationCode": "NAME_RESERVED"
  }]
}

Google states that the validation server does not check the api_secret, and in these tests it did not check the measurement_id either: a made-up one passed. A request with a wrong secret or the wrong property passes.

What the validator lets through

These four returned an empty validationMessages array in both modes:

An empty array therefore means the payload parsed, not that GA4 will use the event. Check these four by hand.

Why an accepted event can be missing

Each of these comes from Google’s documentation, or from the tests above:

1. The secret or the measurement ID is wrong. Neither the endpoint nor the validator says so.
2. The client_id does not match the browser’s. Google joins Measurement Protocol events to online activity by client_id. If the tag has collected no device information for it, the event defaults to desktop on a web stream.
3. There is no session_id or engagement_time_msec. Google says such events may not be fully reflected in Realtime user counts, and they do not count correctly toward engagement metrics.
4. The timestamp is more than 72 hours old. In the default relaxed mode GA4 accepts the event and overrides its time to 72 hours ago. In strict mode it rejects it.
5. The event arrives too late to be joined. Google says events meant to be joined with gtag.js or Firebase events should reach GA4 within 48 hours of the original client-side timestamp.
6. The request is over a limit. Beyond 100 million non-conversion requests an hour for a property, the protocol silently ignores them for the rest of the hour.
7. The name is reserved or belongs to the other stream type. Apart from the cases above, some event, parameter and user property names cannot be sent.

How long an accepted event takes to appear in reports is not stated in Google’s documentation, and it was not measured for this page.

Limits

What it cannot do

The Measurement Protocol is meant to add to the data your tag collects, not to be a full replacement. Google notes that sending everything through it may give only partial reporting, and that the rules you set in the GA4 interface to create or rename events do not run on events sent this way. Your code has to send the final event names.

Google’s documentation now describes the protocol as in a finalized state with no plans for deprecation, and recommends the Data Manager API for new server-to-server integrations. If you are starting one, read that page before you build on this one.

Data TrackingTrack Instagram Traffic in Google Analytics 4October 7, 2026→Data TrackingDirect Traffic in Google Analytics 4: Causes and FixesOctober 7, 2026→GA4Google Analytics 4 Checklist and Best PracticesNovember 28, 2023→

See all articles →