Das Measurement Protocol: Überblick und Anwendung
Google Analytics dient primär dazu, Seitenaufrufe und Interaktionen auf Websites und in Apps messbar zu machen. Aber was ist mit Daten, die gar nicht aus einem Browser oder einer App stammen? Offline-Transaktionen, IoT-Geräte, Serverlogik, automatisierte Prozesse - all das fällt durch das Raster des klassischen Trackings. Genau hier wird es spannend: Das Measurement Protocol erlaubt es, Daten von jedem Client mit Internetzugang direkt an GA4 zu senden. Ein Raspberry Pi, ein Shell-Script, ein ERP-System - alles kann zum Datenlieferanten werden. Dieser Beitrag erklärt, wie das funktioniert, und liefert eine Anleitung für die ersten Gehversuche.
Der Titel lässt es vermuten: Dieser Beitrag ist der erste aus einer Serie von Artikeln rund um das Measurement Protocol. Im ersten Teil geht es um Zweck, Einsatzmöglichkeiten und eine Anleitung für erste Gehversuche.
Alle Teile dieser Serie
- Überblick und Anwendung
- Praxistipps und Einsatzmöglichkeiten
- LifeLogging mit IFTTT
- Transaktionen stornieren per Refund-Event
- Serverseitiges Tracking: Dem Googlebot zuschauen
Was ist das Measurement Protocol?
Das Measurement Protocol ist eine HTTP-Schnittstelle, über die beliebige Clients Daten direkt an GA4 senden können - ohne JavaScript, ohne Browser, ohne SDK. Die Idee: Alles, was einen HTTP-Request absetzen kann, kann auch Daten in die eigene Webanalyse schreiben. Das klingt simpel, und das ist es auch. Ein JSON-Objekt per POST an einen Endpoint schicken - fertig. Kein Tracking-Snippet, kein Tag Manager, kein DOM.
Ein Measurement Protocol gab es bereits in Universal Analytics. Wer sich an die Zeiten von GET /collect?v=1&tid=UA-xxxxx-1&cid=666&t=event&ec=Test... erinnert: Das GA4 Measurement Protocol funktioniert fundamental anders. Statt URL-Parametern kommt JSON zum Einsatz, statt GET nur POST, und statt einer Property-ID braucht man jetzt eine Measurement ID plus ein API Secret zur Authentifizierung. Und das ist nicht der einzige Unterschied: Während man mit dem Vorgänger problemlos eine Website komplett auch über diesen Weg "vollwertig" vermessen konnte (denn bei Universal war das Measurement Protocol und das, was aus dem Browser vom Tracking-Script gesendet wurde, identisch), ist das mit der GA4-Variante nur sehr eingeschränkt möglich. Denn es ist nicht als Ersatz, sondern zur Ergänzung von Web Sessions gedacht, die weiterhin auf dem normalen Weg entstehen und vermessen werden. Weitere Infos zu diesen fundameltalen Unterschieden - und welche Konsequenzen dies hat -, findet sich in meinem Experiment zur Vermessung von Websites via GA4 Measurement-Protocol.
Aktivierung im GA4 Datenstrom
Bevor man loslegen kann, braucht man zwei Dinge: Die Measurement ID des Datenstroms und ein API Secret. Beides findet sich in GA4 unter Verwaltung > Datenstreams:
- Den gewünschten Datenstrom öffnen
- Die Measurement ID (Format: G-XXXXXXXXXX) notieren - sie steht oben im Datenstrom
- Weiter unten den Bereich Measurement Protocol API Secrets öffnen
- Auf "Erstellen" klicken und einen beliebigen Namen vergeben (z. B. "MP Test")
- Das generierte Secret kopieren und sicher aufbewahren
Das API Secret ist kein Bearer Token im klassischen Sinn - es verhindert zufällige Hits, nicht gezielte Manipulation. Für die eigenen Anwendungsfälle reicht das aber völlig aus.
Anatomie eines MP-Requests
Ein Measurement Protocol Request besteht aus drei Teilen: Dem Endpoint mit Authentifizierung, dem Content-Type Header und einem JSON-Body.
Endpoint
Die URL enthält Measurement ID und API Secret als Query-Parameter:
POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXX&api_secret=YOUR_SECRET Content-Type: application/json
JSON-Body
Der Body enthält mindestens eine client_id und ein Array von Events:
{
"client_id": "test.123456",
"events": [{
"name": "mp_test_event",
"params": {
"engagement_time_msec": 1,
"test_param": "Hallo vom Measurement Protocol!"
}
}]
}
Das war's. Kein Hit-Typ wie pageview oder transaction - in GA4 ist alles ein Event. Welche Parameter man mitschickt, hängt vom Anwendungsfall ab. Der Eventname ist frei wählbar (mit ein paar reservierten Ausnahmen wie purchase oder refund, die eine bestimmte Parameterstruktur erwarten).
Pro Request lassen sich bis zu 25 Events im Array bündeln - praktisch für Batch-Verarbeitung.
Mein erster eigener Hit!
Genug Theorie. Am besten versteht man das Measurement Protocol, wenn man es einmal selbst ausprobiert. Dafür braucht man nur die Measurement ID und das API Secret aus dem vorherigen Schritt - und einen Browser. Die Konsole der Entwicklertools (F12) reicht völlig:
fetch("https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXX&api_secret=YOUR_SECRET", {
method: "POST",
body: JSON.stringify({
client_id: "test.123456",
events: [{
name: "mp_erster_test",
params: {
engagement_time_msec: 1,
nachricht: "Es lebt!"
}
}]
})
});
Die eigene Measurement ID und das API Secret einsetzen, in die Konsole pasten, Enter drücken - und dann in GA4 unter Berichte > Echtzeit nachschauen. Das Ergebnis des Requests selbst ist unspektakulär: Es kommt ein 204 No Content zurück. Kein Zählpixel wie bei Universal Analytics, keine JSON-Antwort, nichts. Nur ein leerer Response mit Statuscode 204.
Wenn das Event in der Echtzeit-Übersicht auftaucht: Herzlichen Glückwunsch - der erste eigene Measurement Protocol Hit ist gelandet. Wenn nicht: Weiter zum nächsten Abschnitt.
Der Validation Server
Dass der produktive Endpoint immer mit 204 antwortet - egal ob der Payload valide war oder nicht - ist beim Entwickeln etwas unpraktisch. Deshalb gibt es einen Debug-Endpoint: Gleicher Request, gleicher Body, nur eine andere URL:
POST https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXX&api_secret=YOUR_SECRET
Dieser Endpoint verarbeitet keine Daten (es landet also nichts in GA4), sondern gibt eine JSON-Response mit Validierungsergebnissen zurück. Fehlt ein Pflichtfeld oder stimmt ein Format nicht, sieht man das sofort. Ein Beispiel für eine Fehlermeldung bei fehlendem Eventnamen:
{
"validationMessages": [{
"fieldPath": "events",
"description": "Event at index: [0] has invalid name [].",
"validationCode": "NAME_INVALID"
}]
}
Die Empfehlung: Jeden neuen Request-Typ erst gegen den Validation Server testen, bevor man ihn produktiv einsetzt. Sonst feuert man im schlimmsten Fall wochenlang ungültige Requests in die Leere und wundert sich, warum nichts in den Berichten auftaucht.
Was man wissen muss
Das Measurement Protocol hat ein paar Eigenheiten, die man kennen sollte, bevor man damit arbeitet:
engagement_time_msec ist Pflicht
Technisch betrachtet ist engagement_time_msec kein Pflichtfeld - der Request wird auch ohne akzeptiert. Aber: Events ohne diesen Parameter tauchen in vielen GA4-Berichten schlicht nicht auf. Sie werden zwar verarbeitet, aber von GA4 als "nicht engagiert" eingestuft und aus diversen Standardberichten herausgefiltert. Die Lösung ist simpel: Immer "engagement_time_msec": 1 in die Event-Parameter schreiben. Eine Millisekunde reicht.
Session-Kontext: Nicht automatisch, aber möglich
Events, die über das Measurement Protocol eintreffen, haben von sich aus keine Session-Zuordnung. Es gibt kein source/medium, keine Kampagneninformationen, keine Landingpage. Die Events existieren quasi "im luftleeren Raum". Für viele Anwendungsfälle - Stornos, Offline-Daten, IoT-Signale - ist das kein Problem, weil die Zuordnung über andere Wege läuft (z. B. die transaction_id bei Refunds).
Wer ein MP-Event aber einer bestehenden Session zuordnen will, kann das inzwischen tun: Über den Event-Parameter session_id lässt sich die ga_session_id einer laufenden Session mitsenden - z. B. aus BigQuery oder dem eigenen Backend. So landet das Event in der richtigen Session und taucht auch in session-basierten Berichten auf. Das macht das Measurement Protocol nicht zum Ersatz für clientseitiges Tracking, aber es schließt eine Lücke, die anfangs noch offen war.
Rückwirkende Daten mit timestamp_micros
Über das optionale Feld timestamp_micros im Root-Objekt des JSON-Body lassen sich Events mit einem Zeitstempel in der Vergangenheit senden - bis zu 3 Tage zurück. Praktisch für Batch-Importe, bei denen Daten nicht in Echtzeit vorliegen:
{
"client_id": "batch.processor",
"timestamp_micros": 1712700000000000,
"events": [{
"name": "offline_purchase",
"params": {
"engagement_time_msec": 1,
"transaction_id": "STORE-2026-0401"
}
}]
}
Der Wert ist ein Unix-Zeitstempel in Mikrosekunden (nicht Millisekunden, nicht Sekunden). Wer das 3-Tage-Fenster verpasst, dessen Events werden verworfen.
Einsatzmöglichkeiten
Das Measurement Protocol ist ein Werkzeug mit vielen Anwendungsgebieten. Die weiteren Teile dieser Serie beleuchten einige davon im Detail:
- Stornos und Retouren: Über das refund Event lassen sich Transaktionen im Nachhinein stornieren - komplett oder als Teilstorno. Details dazu gibt es im Beitrag zu Transaktionen stornieren per Refund-Event.
- Serverseitiges Bot-Tracking: Wer wissen will, wie oft der Googlebot vorbeischaut und welche Seiten er sich anschaut, kann Logfile-Daten per Measurement Protocol in GA4 schieben. Mehr dazu unter Serverseitiges Tracking: Dem Googlebot zuschauen.
- LifeLogging: Dienste wie If This Then That lassen sich nutzen, um Alltagsereignisse als GA4-Events zu erfassen. Ein Beispiel mit IFTTT zeigt, wie das geht.
- IoT: Türsensoren, Bewegungsmelder, Kühlschranktemperaturen - alles, was ein Minicomputer mit Internetzugang messen kann, lässt sich über das Measurement Protocol in GA4 abbilden.
- Offline-Transaktionen: Kassensysteme, Telefonbestellungen, Daten aus dem ERP - per Batch-Import und timestamp_micros lassen sich diese Daten zeitversetzt in GA4 einbringen.
Wer sich darüber hinaus für die Eigenheiten und Grenzen des GA4 Measurement Protocols im Vergleich zur UA-Version interessiert, findet im Beitrag GA4 MP: Ein Zwischenstand einen detaillierten Vergleich. Und wer es ganz wild treiben will: Das Experiment zum Website-Tracking per Measurement Protocol zeigt, was passiert, wenn man eine komplette Website nur per MP trackt.
Weiter geht's
Wer jetzt Lust auf mehr bekommen hat: Im nächsten Teil der Serie gibt es Praxistipps und Einsatzmöglichkeiten für den realen Einsatz des Measurement Protocols - von sinnvollen Parametern über Debugging-Strategien bis hin zu typischen Stolperfallen.
Wer auf dem Weg in die Welt des Measurement Protocols Begleitung und Beratung sucht: Meine Beratungsangebote rund um Webanalyse und Tracking sind genau dafür da.
Einen Tee ausgeben ;)