English
Deutsch
PolskiGA4 Measurement Protocol im Wartungsmodus: Was sich ändert und wann der Wechsel zur Data Manager API lohnt
Inhalt
Auf Googles Seite zum Measurement Protocol steht seit Juni 2026 ein Hinweis, der einen ungewöhnlichen Zustand beschreibt: Die Schnittstelle habe einen ausgereiften, endgültigen Produktzustand erreicht und bleibe in Betrieb, eine Abkündigung sei nicht geplant. Für serverseitige Anbindungen wird stattdessen die Data Manager API empfohlen, bezeichnet als zentrale Grundlage künftiger Neuerungen bei der Datenaufnahme.
Das heißt: Nichts wird abgeschaltet, und nichts kommt hinzu. Einen vorgegebenen Termin für den Wechsel gibt es nicht. Anwender müssen selbst entscheiden, wann der Umstieg auf die andere Schnittstelle sinnvoll ist.
Was der Wartungsmodus praktisch bedeutet
Eine bestehende Anbindung bleibt in Betrieb. Wer heute Bestellungen aus dem Warenwirtschaftssystem oder Abschlüsse aus dem Kundenverwaltungssystem an GA4 nachreicht, muss nichts anfassen, und es gibt kein Datum, an dem etwas aufhört zu funktionieren.
Was aufhört, ist die Weiterentwicklung. Jede künftige Möglichkeit bei der serverseitigen Datenaufnahme entsteht in der neuen Schnittstelle. Ein Aufbau, der auf dem Measurement Protocol steht, altert also nicht dadurch, dass er kaputtgeht, sondern dadurch, dass die Umgebung um ihn herum Fähigkeiten bekommt, die er nicht abrufen kann.
Die drei Unterschiede, die zählen
Der erste ist die Anmeldung. Das Measurement Protocol arbeitet mit einem api_secret, das in der Abfrage mitgeschickt wird – ein langlebiges Geheimnis in einer Zeichenkette, das in Protokollen landet und selten gewechselt wird. Die Data Manager API verlangt OAuth 2.0 mit dem Bereich datamanager. Damit fällt das gemeinsame Geheimnis weg, und die Berechtigung lässt sich an ein Dienstkonto binden und einzeln entziehen.
Der zweite Unterschied ist die Zahl der Ziele, die eine Anfrage erreichen kann. Das Measurement Protocol sendet Daten an Google Analytics. Für Google Ads oder Display & Video 360 braucht es eine andere Schnittstelle mit eigenem Schema, eigener Anmeldung und eigener Fehlerbehandlung. Die Data Manager API führt diese Ziele unter einem Datenmodell zusammen; ein Ereignis kann in einer Anfrage an mehrere davon gesendet werden.
Der dritte betrifft die Kennungen. Die neue Schnittstelle unterstützt bis zu zehn Nutzerkennungen je Datensatz und eine Verschlüsselung mit XChaCha20-Poly1305, deren Schlüsselverwaltung in Google Cloud oder in AWS liegen kann. Für abgeglichene Daten heißt das, dass die Kennung den eigenen Bereich verschlüsselt verlässt statt nur gehasht.
Dieselbe Aufgabe, zwei Wege
Measurement Protocol
POST /mp/collect?measurement_id=G-…&api_secret=…
ein Endpunkt, ein Ziel, Geheimnis in der Abfrage
Kennungen im Klartext oder gehasht
Data Manager API
REST oder gRPC, OAuth 2.0, Bereich "datamanager"
ein Aufruf, mehrere Google-Ziele
bis zu 10 Kennungen je Datensatz, XChaCha20-Poly1305
Freischaltliste: nur fuer GA-Ereignisse mit Transaktions-ID als zusaetzliche QuelleWas gegen einen sofortigen Wechsel spricht
Ereignisse mit Transaktions-ID als zusätzliche Datenquelle für GA4 erfordern in der Data Manager API die Aufnahme in eine Freischaltliste. Wer genau das benötigt, muss mit dem Umstieg auf den Zugang warten. Ein Migrationsplan darf sich nicht auf einen noch nicht erteilten Zugang verlassen.
Dazu kommt der Aufwand, der bei jedem Schnittstellenwechsel unterschätzt wird: OAuth verlangt ein Dienstkonto, eine Schlüsselverwaltung und einen Weg, abgelaufene Berechtigungen zu bemerken, bevor drei Tage Abschlüsse fehlen. Ein api_secret in einer Umgebungsvariablen hat diese Anforderungen nicht – das ist zugleich seine Schwäche und der Grund, warum die bestehende Anbindung so wenig Pflege braucht.
Wann sich der Wechsel rechnet
Drei Fälle sprechen klar dafür. Der erste ist eine geplante zweite Anbindung: Wer ohnehin gerade Abschlüsse auch an Google Ads liefern will, baut sonst eine zweite Integration neben der ersten und pflegt danach zwei. Der zweite ist der Umgang mit Personenbezug – wo Kennungen das Haus verlassen, ist eine Verschlüsselung mit eigener Schlüsselverwaltung ein anderes Gespräch mit der Datenschutzabteilung als ein Streuwert. Der dritte ist ein Neubau, denn eine Anbindung, die es noch nicht gibt, auf einer eingefrorenen Schnittstelle zu beginnen, kostet dieselbe Arbeit zweimal.
Wo keiner dieser Fälle vorliegt, ist Abwarten vertretbar und sogar naheliegend. Der Hinweis auf Googles Seite ist kein Countdown. Er ist die Auskunft, dass die eine Schnittstelle fertig ist und die andere weitergebaut wird, und diese Auskunft ändert sich nicht dadurch, dass sie ein halbes Jahr später gelesen wird.
Fragen und Antworten
Warum ist ein api_secret in der Abfrage mehr als ein Schönheitsfehler?
Weil eine Adresse samt Abfrage an vielen Stellen gespeichert wird, die niemand als Ablage für Geheimnisse betrachtet: in den Zugriffsprotokollen von Proxys und Load Balancern, in Fehlermeldungen, in Überwachungswerkzeugen und in den Protokollausgaben der eigenen Anwendung. Jede dieser Stellen hält das Geheimnis dann so lange vor, wie sie ihre Einträge aufbewahrt, oft länger, als es gültig sein sollte.
Wer das Geheimnis kennt, kann damit keine Daten aus GA4 lesen, aber beliebige Ereignisse in den Datenstream schreiben. Der Schaden ist deshalb kein Datenabfluss, sondern verfälschte Berichte, und er fällt spät auf, weil untergeschobene Ereignisse aussehen wie echte.
Solange die bestehende Anbindung weiterläuft, bleibt als Abhilfe der Wechsel des Geheimnisses. GA4 erlaubt je Datenstream mehrere solcher Geheimnisse, in den Einstellungen des Streams als „Measurement Protocol API secrets“ geführt; der Wechsel verläuft also so, dass ein neues erzeugt und ausgerollt und das alte erst danach gelöscht wird. OAuth 2.0 in der Data Manager API löst dasselbe Problem grundsätzlich, weil die Zugangstoken kurzlebig sind und nicht in einer Adresse stehen.
Lassen sich beide Schnittstellen während der Umstellung parallel betreiben?
Ja, solange nicht dasselbe Ereignis über beide Wege an dasselbe Ziel geht, sonst stehen Abschlüsse doppelt in GA4. Sauber ist eine Trennung nach Zielen, etwa GA4 weiter über das Measurement Protocol und Google Ads neu über die Data Manager API, oder ein harter Wechsel je Ziel zu einem festen Zeitpunkt.
Wie fällt eine fehlerhafte oder abgelaufene Anbindung auf, bevor Abschlüsse fehlen?
Bei den beiden Schnittstellen auf verschiedene Weise. Das Measurement Protocol antwortet auf jede empfangene Anfrage mit einem Erfolgsstatus, auch wenn das Ereignis fehlerhaft ist oder verworfen wird. Eine Prüfung gegen den Validierungsendpunkt /debug/mp/collect zeigt Fehler, gehört aber in die Entwicklung und nicht in jede Anfrage. Im Betrieb bleibt nur der Abgleich: die Zahl der gesendeten Ereignisse gegen die Zahl, die in GA4 ankommt.
Bei der Data Manager API führen fehlende oder abgelaufene Berechtigungen dagegen zu einer Fehlerantwort. Ein Alarm für Antworten außerhalb des Erfolgsbereichs macht das Problem bereits beim ersten Fehlschlag sichtbar, statt erst durch fehlende Abschlüsse. Voraussetzung ist, dass die Anbindung die Antworten überhaupt auswertet.
Passend dazu
