Das Measurement Protocol: Praxistipps und Einsatzmöglichkeiten
Dieser Beitrag ist Teil einer Artikelserie zum Measurement Protocol von Google Analytics. Nach einigen Anwendungsszenarien und Denkanstößen folgt ein technischer Praxisteil mit Hinweisen zum Einsatz des GA4 Measurement Protocol.
Alle Teile dieser Serie
- Überblick und Anwendung
- Praxistipps und Einsatzmöglichkeiten
- LifeLogging mit IFTTT
- Transaktionen stornieren per Refund-Event
- Serverseitiges Tracking: Dem Googlebot zuschauen
Reale Anwendungen für Websitebetreiber
Im ersten Teil hat sich gezeigt, dass man mit dem Measurement Protocol die Grenzen von Websites und Apps sprengen und neue Bereiche mit Google Analytics erobern kann. Es gibt aber auch im Zusammenhang mit dem Web - und speziell den Herausforderungen im Marketing - reichlich Anwendungsszenarien, die mit "klassischem" Tracking oft viel aufwändiger oder z. T. unmöglich sind. Einige Beispiele:
Sekundäres Tracking: Mehrere Datenströme versorgen
Um mehr als eine GA4-Property mit Daten zu versorgen, bieten Tag Manager und gtag.js entsprechende Lösungen an. Diese sind entweder schwierig zu implementieren, unübersichtlich, fehleranfällig... oder alles zusammen. Um einem zweiten Datenstrom nur in ausgesuchten Fällen Daten zu senden, steht schnell viel Konfigurationsaufwand an, der den Bestand an Triggern und Tags im Google Tag Manager deutlich steigert. Folgeaufwand für die Pflege ist ebenso nicht ausgeschlossen.
So ist es in der Praxis i. d. R. viel einfacher, die sekundäre Sammlung von Daten serverseitig per Measurement Protocol zu erledigen. Sollte es zwei oder drei weitere wesentliche Stellen mit zusätzlichen Events geben, verfährt man damit ebenso und ist in wenigen Minuten fertig. Ja: Quick & Dirty, dafür (kosten-) effizient und damit i. d. R. im Sinne des Kunden. Überzeugt man so vom Mehrwert eines zusätzlichen Datenstroms, folgen Budgets für tiefere Implementierungen viel einfacher 😉
Damit kann man nicht nur bei separat existierenden Properties für mehrere Sites schnell ein gemeinsames Tracking implementieren, sondern ausgewählte Daten mehrerer Domains in einen Topf werfen. Ein umgesetztes Beispiel aus der Online-Marketingpraxis: Ein Verbund mehrerer Shops sammelt via Measurement Protocol in einer gemeinsamen Property Daten zu Besuchern und Checkouts, die zur übergreifenden Auswertung dienen. Ohne aufwändige Implementierung von Cross-Domain-Tracking oder mehreren Instanzen des Standardtrackings. Dabei ist allerdings zu beachten, dass eine Property, die aussschließlich auf diesem Weg mit Daten versorgt wird, keine "attribuierbaren" Sessions erzeugen kann. Das muss den Wert aber nicht komplett negieren: Aufrufe, Events, Umsatz: Das alles ist auch auf diese Weise zählbar und Attribution kann zwar nicht in GA4 selbst, aber auf Basis der Daten durchaus hergestellt werden. Mehr dazu im Experiment zum Website-Tracking per Measurement Protocol.
Daten anreichern
Zusätzliche Daten wie Zeitpunkte von Tagespreisanpassungen, Wetterdaten, Änderungen im Produktportfolio u. Ä. immer direkt in der Webanalyse? Das geht unter Einsatz des Measurement Protocols. So kann ein Dashboard z. B. den Verlauf des Transaktionsvolumens unmittelbar mit anderen Messdaten kombiniert darstellen. Und dank timestamp_micros können Events sogar bis zu 3 Tage rückwirkend erfasst werden - deutlich mehr als die 4 Stunden, die beim alten Universal Analytics Measurement Protocol möglich waren.
Online meets Offline
Wenn noch ein paar der Ideen aus dem ersten Beitrag hinzugefügt werden, finden sich weitere Kombinationen: Per Measurement Protocol und Lichtschranke erfasstes Kommen und Gehen, Bewegungsmuster in Ladengeschäften, Websitenutzung und ebenso eingeschossene Wetterdaten in einer GA4-Property erlauben Auswertungen, die sonst ohne Datenaufbereitung in Drittanwendungen nicht möglich sind. Direkt in Google Analytics.
Stornos und Retouren
Mit dem GA4 Measurement Protocol lassen sich Transaktionen stornieren, indem ein refund-Event mit der entsprechenden Transaktions-ID gesendet wird. Für die meisten Szenarien rund um E-Commerce-Korrekturen ist das der sauberste Weg. Weshalb dem Thema Stornos ein eigener Beitrag dieser Serie gehört.
Serverseitiges Tracking: Eher eingeschränkt
Um mit dem Measurement Protocol ein serverseitig implementiertes Tracking umzusetzen, braucht man überraschend wenig, wenn man sich selbst um die Verwaltung des Users - z. B. am Client in einem eigenen Cookie - kümmert. Oder sich in aufwändigeren Implementierungen selbst Tracking-Aufrufe vom Browser an den eigenen Server senden lässt, um dort per Measurement Protocol an GA4 weiterzuleiten. Wie im oben beschriebenen Experiment zu sehen ist, ist die Nutzung einer solchen GA4 Property aber nicht vergleichbar mit einer "normalen" - und auch das Thema Datenschutz ist nicht automatisch erledigt, nur weil ein anderer Weg genommen wird, um die Daten an GA4 zu senden. Transaktions-IDs sind immer noch ein DSGVO-Thema, Mailadressen in URLs immer noch zu vermeiden... und so weiter und so weiter.
Zudem werden Proxies, CDNs & Co. plötzlich zum Problem und auch "Details" wie die saubere Zuordnung einer Einstiegsseite eines Erstbesuchers sind in diesem Kontext problematisch (aber lösbar). Soll das Ganze die Performance der eigenen Website nicht zu sehr belasten, bringt die Implementierung einer asynchronen Lösung weitere Herausforderungen. Dafür bietet diese Variante ein paar nette Vorteile. So kommen z. B. nicht nur Besucher, sondern auch der Googlebot und seine Freunde in die Webanalyse. Weil das Thema so spannend ist, enthält diese Serie einen eigenen Beitrag zum serverseitigen Tracking mit Analytics voller Details und Beispielen 😉
Measurement Protocol im Einsatz: Praxistipps für GA4
Um von einer Idee zur lebenden Implementierung zu kommen, muss der Sprung in die Praxis her. Für alle, die sich auf technischer Ebene damit zu befassen haben, schließt dieser Beitrag daher mit Tipps ab, die den Einstieg erleichtern und typische Stolperfallen aufzeigen. Im Vergleich zum alten Universal Analytics Measurement Protocol hat sich einiges geändert - nicht alles zum Besseren.
Tipp 1: Validation Server nutzen
Die vielleicht wichtigste Neuerung gegenüber dem alten Measurement Protocol: Es gibt einen dedizierten Validation Server. Statt an den regulären Endpunkt zu senden, schickt man den Request an:
POST https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXX&api_secret=YOUR_SECRET
Die Antwort enthält ein JSON mit einer Liste von Validierungsmeldungen. Stimmt etwas nicht - ungültige Parameter, fehlende Pflichtfelder, falsches Format - findet man es hier. Im Gegensatz zum "echten" Endpunkt, der prinzipiell alles schluckt und nie meckert (dazu gleich mehr), gibt der Validation Server tatsächlich brauchbares Feedback. Jeder Request sollte hier zuerst getestet werden, bevor er auf die Produktiv-Property losgelassen wird.
Tipp 2: 204 heißt gar nichts
Im alten Measurement Protocol gab es immerhin ein Tracking-Pixel als Antwort - auch wenn der Status 200 keinerlei Garantie war, dass die Daten tatsächlich angekommen sind. Das GA4 Measurement Protocol geht noch einen Schritt weiter in Richtung Nichtssagen: Der Endpunkt antwortet immer mit einem 204 No Content. Egal ob der Request gültig, ungültig, komplett leer oder völliger Unsinn war.
Kein JSON zurück, kein Fehlercode, kein Hinweis. Das bedeutet: Wer sich auf den HTTP-Statuscode verlässt, um zu prüfen ob alles angekommen ist, wird sich wundern. Der Validation Server aus Tipp 1 ist daher kein "Nice-to-have", sondern Pflicht. Für die Produktivumgebung empfiehlt sich zusätzlich ein Blick in den DebugView von GA4, um zu sehen, ob die Events tatsächlich dort landen, wo sie sollen.
Tipp 3: Client ID und User ID
Die client_id ist weiterhin Pflichtfeld - ohne sie passiert nichts. Im JSON-Body des Requests sieht das so aus:
{
"client_id": "123456789.1234567890",
"events": [{
"name": "test_event",
"params": {
"engagement_time_msec": "100"
}
}]
}
Die gute Nachricht: Zum Testen funktioniert jeder String als Client ID. Wer es sauber machen will, nutzt die Client ID aus dem GA4-Cookie _ga des aktiven Users (Beispiel: GA1.1.123456789.1234567890 - der Teil nach dem zweiten Punkt ist die eigentliche Client ID). Bei rein serverseitigen Szenarien ohne Browser erzeugt man sich eine eigene UUID oder einen vergleichbaren eindeutigen Wert und verwaltet diesen selbst. Und bitte beachten: Wer einen serverside Google Tag Manager verwendet, wird i. d. R. die server-managed ID nutzen. Hier steckt die GA4 Client ID in einem FPID Cookie, ist im Browser nicht lesbar und hat einen anderen Inhalt (und ein anderes Format) als das reguläre JavaScript Cookie _ga.
Optional, aber oft sinnvoll: Die user_id kann zusätzlich im Body mitgegeben werden. Damit lassen sich eingeloggte Nutzer geräteübergreifend zusammenführen - genau wie beim clientseitigen Tracking mit gtag.js oder GTM. Und das auch nur unter den gleichen Bedingungen, wie sie auch für das clientseitige Bereitstellen einer User ID gelten: Kein PII, nicht aus einem Cookie auch bei nicht angemeldeten Usern, Auswirkungen auf Sessions... mehr dazu auch in der beyond pageviews Podcast Folge zur User-ID.
Tipp 4: Mehrere Events pro Request
Statt Aufrufe einzeln abzusetzen, können bis zu 25 Events in einem einzigen Request gesendet werden. Das events-Array im JSON-Body nimmt einfach mehrere Objekte auf:
{
"client_id": "123456789.1234567890",
"events": [
{
"name": "page_view",
"params": {
"page_title": "Startseite",
"page_location": "https://example.com/",
"engagement_time_msec": "100"
}
},
{
"name": "custom_event",
"params": {
"category": "navigation",
"engagement_time_msec": "100"
}
}
]
}
Einen separaten /batch-Endpunkt wie beim alten Measurement Protocol gibt es nicht mehr - das Batching ist direkt ins Format eingebaut. Wer zuvor in Logs zwischengelagerte Daten zu bestimmten Zeitpunkten verarbeitet und an Analytics überträgt, profitiert davon deutlich. Aber Achtung: Alle Events in einem Request teilen sich die gleiche client_id. Sollen Events für verschiedene Nutzer gesendet werden, braucht es separate Requests.
Tipp 5: timestamp_micros - die Zeitmaschine
Beim alten Measurement Protocol durfte ein Hit maximal 4 Stunden in die Vergangenheit reisen. Das GA4 Measurement Protocol ist hier deutlich großzügiger: Mit timestamp_micros lassen sich Events bis zu 3 Tage rückwirkend erfassen. Der Wert ist ein Unix-Timestamp in Mikrosekunden und wird auf oberster Ebene des Request-Bodys angegeben:
{
"client_id": "123456789.1234567890",
"timestamp_micros": "1712345678000000",
"events": [{
"name": "offline_purchase",
"params": {
"transaction_id": "T12345",
"value": 49.99,
"currency": "EUR",
"engagement_time_msec": "100"
}
}]
}
Das macht Szenarien wie die Verarbeitung von Offline-Daten oder Batch-Imports aus Drittsystemen deutlich komfortabler. Tägliche Verarbeitung reicht locker aus, auch am Wochenende geht nichts verloren. Alles was älter als 3 Tage ist, kommt allerdings definitiv nicht in Analytics an - ein Punkt, den man bei der Architektur seiner Verarbeitungspipeline berücksichtigen sollte.
Tipp 6: engagement_time_msec - der unsichtbare Pflichtparameter
Dieser Tipp ist vermutlich der wichtigste in der ganzen Liste und gleichzeitig der, über den man am wenigsten in der offiziellen Dokumentation findet. Ohne den Parameter engagement_time_msec in den Event-Parametern werden via Measurement Protocol gesendete Events nicht in den Standardberichten von GA4 angezeigt. Sie kommen zwar an (im DebugView sind sie sichtbar), aber GA4 filtert Events ohne Engagement-Zeit aus den meisten Reports heraus.
Es reicht, einen Wert größer als 0 mitzuschicken - "engagement_time_msec": "100" ist ein gängiger Standardwert. Wer reale Engagement-Zeiten messen kann (z. B. bei serverseitigem Tracking), sollte diese natürlich verwenden. Aber selbst ein symbolischer Wert ist besser als keiner. Das gilt für jedes Event, das über das Measurement Protocol gesendet wird.
Tipp 7: Session-Kontext - nicht automatisch, aber machbar
Events, die über das GA4 Measurement Protocol gesendet werden, haben von sich aus keinen Session-Kontext. Das clientseitige Tracking von GA4 verwaltet Sessions über die Parameter session_id und session_number, die bei jedem Hit mitgeschickt werden. Das Measurement Protocol macht das nicht von allein.
Wer die session_id (entspricht der ga_session_id aus BigQuery oder dem GA4-Cookie) kennt, kann diese aber als Event-Parameter mitsenden. Das Event wird dann der bestehenden Session zugeordnet und taucht auch in session-basierten Berichten auf. Damit werden auch Geo- und Geräteinformationen aus der Session übernommen - allerdings nur, wenn das MP-Event innerhalb von 24 Stunden nach Beginn der Session gesendet wird. Danach ordnet GA4 die zum Zeitpunkt der Verarbeitung aktuellsten Geo- und Gerätedaten der Client ID zu, was bei serverseitigen Szenarien zu unbrauchbaren Werten führen kann.
Für rein serverseitige Events wie Offline-Conversions, CRM-Daten oder Backend-Prozesse ist eine Session-Zuordnung in der Regel nicht nötig - solche Events gehören ohnehin nicht in einen Browse-Session-Kontext. Wer aber per Measurement Protocol Events sendet, die zur Website-Nutzung eines Users gehören (z. B. ein Backend-Event nach einem Checkout), sollte die session_id mitsenden und das 24-Stunden-Fenster im Blick behalten.
Inspiriert zu eigenen Anwendungen? Dann freue ich mich über Kommentare aller Art. Die nächsten Teile dieser Serie beleuchten ein paar der aufgeführten Szenarien im Detail - also gleich weiterlesen im Artikel zum LifeLogging mit IFTTT 😉
Einen Tee ausgeben ;)