GA4 Measurement Protocol goed toepassen: het EU-endpoint, client_id, debugvalidatie en wat het niet kan

Het endpoint en de EU-variant

POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXX&api_secret=… is het gedocumenteerde verzamel-endpoint. Google documenteert daarnaast https://region1.google-analytics.com/mp/collect voor verkeer uit de EU; Track gebruikt standaard de region1-host, zodat requests in de EU ontstaan en eindigen.

De measurement_id is openbaar (hij staat in je gtag-snippet). Het api_secret maak je aan onder Beheer → Gegevensstreams → API-secrets voor Measurement Protocol, en het hoort in de kluis.

De body

{
  "client_id": "1234567890.1700000000",
  "user_id": "u_42",
  "timestamp_micros": 1767225600000000,
  "non_personalized_ads": false,
  "consent": { "ad_user_data": "GRANTED", "ad_personalization": "DENIED" },
  "user_data": { "sha256_email_address": ["<hash>"] },
  "events": [{ "name": "purchase", "params": { "transaction_id": "A1001", "value": 129.9, "currency": "EUR", "items": [{ "item_id": "SKU-1", "price": 99.9, "quantity": 1 }], "engagement_time_msec": 100 } }]
}

Limieten volgens de referentie: maximaal 25 events per request, 25 parameters per event, eventnamen van maximaal 40 tekens en een timestamp_micros van hoogstens 72 uur oud. Namen die beginnen met google_, ga_ of firebase_ zijn gereserveerd.

client_id is wat iedereen vergeet

GA4 koppelt server-events aan sessies via client_id, de waarde die in de _ga-cookie staat (GA1.1.<random>.<timestamp> → client_id = "<random>.<timestamp>"). Zonder de echte client-ID vormen server-events hun eigen verweesde gebruikers en blazen ze de gebruikersaantallen op.

Track leest de _ga-cookie in de browser zodra analyticstoestemming is gegeven, stuurt hem met elk event mee als leveranciers-id en gebruikt hem als client_id voor Measurement Protocol-leveringen. Bestaat er geen _ga-waarde (zuivere serverbronnen), dan leidt Track een stabiele pseudo-client-ID af uit de anonieme ID, zodat events in elk geval per bezoeker worden gegroepeerd.

Het zegt altijd ja — valideer op het debug-endpoint

Het productie-endpoint geeft 2xx terug voor alles wat syntactisch acceptabel is. Semantische problemen (onbekende parametertypen, gereserveerde namen, een ontbrekende client-ID) kom je alleen te weten via het debug-endpoint /debug/mp/collect, dat antwoordt met validationMessages. In de testmodus stuurt Track elk event eerst naar het debug-endpoint en stuurt het pas door als die lijst leeg is, zodat een kapotte mapping luid faalt in de wizard in plaats van stilletjes in productie.

Wat het Measurement Protocol niet kan

• Het maakt zelf geen sessies aan; paginaweergaven horen van de gtag in de browser te komen.
• Het heeft geen geo-, apparaat- of campagnedata, tenzij je die zelf meestuurt; de meeste teams sturen alleen aankopen, terugbetalingen en backend-events.
• Realtime-rapporten hebben engagement_time_msec nodig (elke positieve waarde) om de gebruiker als betrokken te tellen.
• Attributie aan campagnes leunt nog altijd op de browsersessie waar de client_id bij hoort.

De pragmatische verdeling: gtag voor paginaweergaven en interacties, Measurement Protocol voor de gezaghebbende aankoop met transaction_id (GA4 dedupliceert aankopen op transactie-ID), terugbetalingen en backend-events.

Toestemmingsvelden

Stuur consent.ad_user_data en consent.ad_personalization mee, afgeleid uit de doelen van de bezoeker, en zet non_personalized_ads: true wanneer marketingtoestemming ontbreekt. Zonder analyticstoestemming wordt het event helemaal niet verstuurd — de GA4-destination heeft in Track het doel analytics nodig, niet marketing.

Checklist

• Te doen: Measurement-ID in de destination, API-secret in de kluis
• Te doen: _ga-client-ID vastgelegd met analyticstoestemming
• Te doen: Aankopen dragen een transaction_id; browser- en serveraankopen delen dezelfde
• Te doen: Debugvalidatie slaagt in de testmodus
• Te doen: Events bevestigd in DebugView met de verwachte parameters