Was ist das Measurement Protocol?
Normalerweise misst Google Analytics im Browser: Das Tag auf deiner Website sieht Seitenaufrufe, Klicks und Käufe. Aber was passiert, wenn der wichtigste Moment gar nicht im Browser stattfindet?
Das Measurement Protocol ist die Antwort. Es ist eine Schnittstelle von Google Analytics 4, über die dein Server, dein CRM oder ein Automatisierungs-Tool Ereignisse per HTTP-POST direkt an Google schickt. Kein Browser, kein Tag, nur eine Anfrage.
- Ein Lead aus dem Kontaktformular wird Wochen später im CRM zum Auftrag.
- Ein Kunde kauft im Laden, nachdem er online gestöbert hat.
- Eine Retoure wird in der Warenwirtschaft gebucht.
- Ein Abo verlängert sich automatisch.
So funktioniert es
Die Anfrage geht an google-analytics.com/mp/collect. In der Adresse stehen zwei Pflichtangaben: die Mess-ID deines Datenstreams und ein API-Secret. Das erzeugst du in GA4 unter Verwaltung → Datenstreams → Measurement Protocol.
Der wichtigste Teil steckt im Inhalt der Anfrage: die client_id. Sie verbindet dein Server-Ereignis mit dem Besucher, der vorher auf deiner Website war. Ohne sie weiß GA4 nicht, woher der Kunde kam.
Die client_id holst du im Browser mit gtag('get', …, 'client_id', …) und speicherst sie zum Beispiel mit dem Formular im CRM. Bei Apps heißt das Gegenstück app_instance_id.
Die Limits
Was
Grenze
Ereignisse je Anfrage
25
Parameter je Ereignis
25
Ereignisname
40 Zeichen
Parameterwert
100 Zeichen
Rückdatierung
72 Stunden
Mit dem Feld timestamp_micros datierst du ein Ereignis bis zu 72 Stunden zurück. Damit es sauber mit den Browser-Daten zusammenspielt, empfiehlt Google den Versand innerhalb von 48 Stunden.
Welche Fristen zählen?
Hier wird es knifflig, denn je nach Ziel gelten andere Fristen. Sie zählen ab dem letzten Online-Ereignis derselben client_id:
- Zuordnung zur Sitzung: spätestens 24 Stunden nach Sitzungsstart.
- Export an Google Ads: spätestens 63 Tage danach.
- Zielgruppen: im Web spätestens 30 Tage danach.
Beispiele aus der Praxis
Fallzahlen zum Nutzen veröffentlicht Google nicht. Die Regeln hinter zwei typischen Einsätzen sind aber klar.
Case A · B2B-Dienstleister
Auftrag im CRM
63 Tage
Frist für Google Ads
1
Ereignis close_convert_lead
client_id beim Formular speichern, beim Abschluss zurückschicken
Läuft der Versand über n8n, Make oder Zapier, reicht ein HTTP-Baustein. Mit Wert gehört auch die Währung dazu.
Case B · Onlineshop
Retoure aus der Warenwirtschaft
1
Pflichtfeld transaction_id
72 h
Rückdatierung
Ereignis refund mit der Bestellnummer senden
So stimmt der Umsatz in GA4 mit dem, was wirklich hängen bleibt.
Measurement Protocol oder Server-Side Tracking?
Beim Server-Side Tracking betreibst du einen eigenen Tag-Manager-Container auf einem Server. Er nimmt die Anfragen aus dem Browser an und verteilt sie weiter. Das ist eigene Infrastruktur mit Hosting und Pflege.
Das Measurement Protocol ist nur ein Endpunkt, den jedes System direkt ansprechen kann. Das Gegenstück bei Meta heißt Conversions API. Für große Datenmengen auf einmal gibt es in GA4 außerdem den Datenimport per CSV.
Häufige Fehler
Fehler 1 · Ohne Tag tracken wollen
Das Protokoll ist kein Ersatz für das GA4-Tag. Ohne Browser-Daten fehlen Quelle, Kampagne und Gerät — GA4 trägt im Web dann einfach „Desktop“ ein.
Fehler 2 · Die client_id nicht speichern
Wer eine erfundene ID schickt, erzeugt einen neuen Nutzer ohne Herkunft. Der Abschluss ist dann gezählt, aber keiner Kampagne zugeordnet.
Fehler 3 · Nicht testen
Keine Fehlermeldung heißt nicht, dass es geklappt hat. Jeder neue Ereignistyp gehört erst an den Debug-Endpunkt, dann in den Echtbetrieb.
Fehler 4 · Klartext-Daten und offenes Secret
E-Mail-Adressen oder Telefonnummern im Klartext verbietet Googles Richtlinie für das Protokoll. Und das API-Secret gehört auf den Server, nie in den Code der Website. Google rät, es regelmäßig zu erneuern.
Was tun?
- Lücke benennen: Welcher wichtige Schritt passiert außerhalb der Website?
- client_id sichern: Beim Formular oder Checkout mitspeichern.
- Einwilligung beachten: Die Datenschutzkonferenz sieht eine ID aus einem Cookie als personenbezogenes Datum. Fehlt die Einwilligung beim Setzen, wirkt das auf die spätere Verarbeitung fort.
- Testen: Erst Debug-Endpunkt, dann DebugView, dann live.
Häufige Fragen
Brauche ich mit dem Measurement Protocol noch das GA4-Tag?
Ja. Google sieht das Protokoll als Ergänzung zu gtag.js, Tag Manager oder Firebase. Ohne Tag fehlen Herkunft, Kampagne und Gerät der Besucher.
Wie lange darf ein Offline-Kauf zurückliegen?
Der Zeitstempel darf höchstens 72 Stunden zurückliegen, Google empfiehlt 48 Stunden. Für den Export an Google Ads gilt eine Frist von 63 Tagen ab dem letzten Online-Ereignis.
Woher bekomme ich die client_id?
Im Browser über gtag mit dem Befehl get. Speichere sie beim Absenden des Formulars oder beim Checkout zusammen mit dem Datensatz, dann kannst du sie später mitschicken.
Wie teste ich, ob meine Ereignisse ankommen?
Schick sie zuerst an den Endpunkt /debug/mp/collect. Er meldet Fehler wie reservierte Namen oder zu lange Werte. Testereignisse landen nicht in den Berichten.
Ist das Measurement Protocol dasselbe wie serverseitiges Tracking?
Nein. Serverseitiges Tracking nutzt einen eigenen Tag-Manager-Container auf einem Server. Das Measurement Protocol ist nur ein Endpunkt, an den jedes System Ereignisse schicken kann.
Quellen
- Google for Developers: Measurement Protocol (GA4)
- Google for Developers: Ereignisse senden
- Google for Developers: Measurement Protocol Referenz
- Google for Developers: Anwendungsfälle
- Google for Developers: Ereignisse validieren
- Google for Developers: Measurement Protocol Policy
- Datenschutzkonferenz: Orientierungshilfe Digitale Dienste
