Data Manager API: Echter Ersatz für das Measurement Protocol?

Wenn Google eine Schnittstelle in den "Wartungsmodus" schickt und gleichzeitig einen glänzenden Nachfolger präsentiert, ist der (erwartete) Reflex ziemlich vorhersehbar: aufmerksam werden, Doku überfliegen, Migration einplanen. Denn nicht nur bei Google Ads Conversions und neuerdings auch Floodlight, sondern auch für Google Analytics soll die neue API die "vereinheitlichte" serverseitige Schnittstelle zur Anlieferung von Daten werden, wenn es nach Google geht.

Daher habe ich mir mein eigenes Experiment von 2022 zur Vermessung von Website-Traffic via Measurement Protocol vorgenommen und geschaut, ob sich a) ein Unterschied in den erzielbaren Daten ergibt und b) wirklich alles, was vorher mit dem GA4MP möglich war, auch mit der Data Manager API funktioniert.

TL;DR

Das selbe Experiment, mit der Data Manager API wiederholt, ergibt im Wesentlichen das altbekannte Ergebnis. Zumindest, was die Attribution angeht. Aber ein 1:1 Ersatz sieht anders aus. Authentifizierung und Latenz des Endpunkts liefern echte neue Herausforderungen.

Hier die lange Fassung für alle, die mehr wissen wollen oder den Einsatz der Data Manager API statt des Measurement Protocols nutzen wollen - vor allem in Grenzfällen, wie ich sie in meiner Serie zum Measurement Protocol seinerzeit beschrieben habe (siehe z. B. Anleitung zum Lifelogging oder für Tracking des Googlebot).

Measurement Protocol und GA4: Ein Downgrade seit Tag Eins

Im Juni 2022 habe ich hier das Measurement Protocol für Websites ausprobiert. Die Frage damals war simpel und für jeden interessant, der serverseitig Daten an GA4 schicken will: Kann man ausschließlich über das Measurement Protocol eigenständig Hits mit eigener Quelle und Attribution senden? Google selbst sagt klar, dass das GA4MP (anders als sein Universal-Analytics-Vorgänger) dazu gedacht ist, bestehende Web oder App Sessions zu ergänzen, aber nicht, um ausschließlich darüber attribuierbare Ergebnisse in der Webanalyse zu erzeugen.

Das hat das Experiment damals auch deutlich bestätigt. Egal wie man Referrer, URL-Parameter oder Quell-/Medium Informationen mitschickt, GA4 ordnet solche Hits keiner Quelle und keinem Kanal zu. Alles landet auf „Direct" und „Unassigned". Wer Attribution braucht, muss sie sich in BigQuery von Hand zusammenbauen.

Vier Jahre später scheint das Schicksal des GA4MP langsam besiegelt zu sein, wenngleich es nicht gleich verschwindet. Neue Entwicklungen sind nur bedingt erforderlich und es gibt noch kein Sunset-Datum. Dennoch: Ein API-Generationswechsel steht an, also lohnt sich auch die Erprobung. Daher habe ich das Experiment wiederholt.

Ergebnisse des Experiments

In Kurzform hier die Zusammenfassung dessen, was dabei herausgekommen ist:

• Attribution: Standalone gesendete Events bleiben ohne eigene Quelle. In BigQuery sieht man exakt das alte Bild - Session-Quelle (not set), Channel Unassigned, User-First-Touch (direct)/(none). UTM-Parameter in der URL werden ignoriert, manuell mitgegebene source/medium überleben höchstens als Event-Parameter und treiben die Attribution nicht an. Eine Quelle erbt ein Event nur über den „Session-Join" an eine bereits im Browser gemessene Session (gleiche clientId, gleiche session_id).
• User-Daten: Gehashte First-Party-Daten funktionieren wie gehabt, gleiche Regeln, gleiche Wirkung.
• Event-Modell: Dieselben Events, dieselben Parameter, nur in anderer Schreibweise. Was man mit dem GA4MP senden kann, kann man auch per Data Manager API senden. Funktional gibt es in dieser Hinsicht keine Unterschiede - aber eben auch keine Vorteile
• Format: unterscheidet sich ebenso deutlich wie auch die Komplexität: Statt eines einfachen Secrets wird Authentifizierung benötigt
• Validierung: Ebenso wie beim GA4MP kann man Hits vor dem Senden validieren. Neben einer reinen Empfangsbestätigung kann zudem der Verarbeitungsstatus anschließend abgerufen und kontrolliert werden (was man je nach Anwendungsfall auch tun sollte)
• Keine "Echtzeit-API": Die Latenz des Endpunkts ist deutlich größer bei der Data Manager API. Dieser ist zu langsam für eine "Echtzeitanbindung" und erfordert beim Einsatz selbst bei kleinen Websites ein Umdenken in der Architektur, um den Laden nicht lahm zu legen

Der Mehrwert der Data Manager API steckt also woanders - in der Reichweite über mehrere Produkte, vor allem Google Ads. Fürs reine GA4-Tracking ist sie ein schwergewichtigerer Transportweg für die ansonsten gleiche Fracht - und auch die Reichweite ist gleich.

Kurzfazit: Wer bisher Daten per GA4MP "direkt" in seine Property gesendet hat, sollte das so lange es noch geht auf die gleiche Weise weiterhin tun. Wer jetzt in das Game einsteigt, ist vermutlich besser damit bedient, gleich mit der Data Manager API zu arbeiten, wenn die Hürden zu nehmen sind, die Auth und Latenz aufgestellt haben (siehe unten).

Warum jetzt überhaupt eine neue API?

Google möchte offenbar gern alle Daten, die in das Zugpferd Google Ads einfließen, über eine gemeinsame Schnittstelle entgegennehmen können. Das ist nachvollziehbar, denn Enhanced Conversions für Google Ads können schon heute aus zahlreichen Quellen kommen. In Zukunft wird PII als Ersatz für Cookies zur Attribution von Erfolg nur noch wichtiger werden. Genau diese Rolle soll die Data Manager API spielen und über ein gemeinsames Datenmodell, den gleichen Endpunkt für mehrere Google-Produkte und einen vereinheitlichten Weg die Komplexität verringern. Google Analytics ist in dieser Rechnung nur eines der Produkte, Google Ads (Offline- und Enhanced Conversions, Customer Match) und Floodlight die anderen. Bisher. Tracking und Messung im Umfeld von Werbung sind aber klar die treibenden Themen.

Service-Account statt Secret

Hier liegt die größte Umstellung, und ehrlich gesagt auch der Moment, in dem die neue API ihren Komfortverlust am deutlichsten für viele Anwendungsfälle zeigt. Das Measurement Protocol braucht neben der measurement_id nur ein in der Property bzw. beim Datenstrom verwaltetes api_secret. Das ist eine Konstante und solange man diese mitsendet, ist das Thema "Authentifizierung" erledigt.

Die Data Manager API möchte aber OAuth 2.0 sehen. Das ist nachvollziehbar, weil hier ja auch Google Ads im Spiel ist. Serverseitig - also ohne Nutzer vor dem Bildschirm - heißt das in der Praxis: ein Service Account erzeugt ein selbst signiertes JWT, tauscht es am Token-Endpunkt gegen ein kurzlebiges Access-Token und hängt dieses als Authorization: Bearer … an jeden Request. Dabei kann ein Service Account Key verwendet werden, aber als wäre das nicht kompliziert genug, hätte Google es lieber, wenn Service Account Impersonation verwendet wird (siehe Anleitung von Google zur Einrichtung), was die Anforderungen an die Umgebung einer Anbindung nochmal anhebt.

Ein einfaches Pendant zum api_secret gibt es also nicht mehr. Wer automatisiert Daten anliefern will, holt sich zwangsweise die komplette OAuth- und JWT-Mechanik ins Haus, statt einen simplen String an die URL zu hängen. Für ein durchgeplantes Backend ist das sicher zu verkraften und umzusetzen, aber für Basteleien am Rande des eigentlichen Zwecks von GA bedeutet dies evtl. sogar das Aus.

Format und Antwortverhalten

Auch das, was "über die Leitung" geht, sieht bei der Data Manager API anders aus. Zum Vergleich hier derselbe page_view einmal in alt und einmal in neu.

Measurement Protocol:

{
  "client_id": "1234567890.1234567890",
  "events": [
    {
      "name": "page_view",
      "params": {
        "page_location": "https://www.example.com/dmapi-poc",
        "page_title": "DM API PoC"
      }
    }
  ]
}

Die Antwort des Endpunkts ist ein nacktes 204 No Content (wie versprochen ohne Body). Ob der Hit gut war, erfährt man produktiv also erstmal überhaupt nicht. Dafür gibt es den separaten Debug-Endpunkt /debug/mp/collect.

Im Vergleich dazu die Data Manager API:

{
  "destinations": [
    {
      "operatingAccount": { "accountType": "GOOGLE_ANALYTICS_PROPERTY", "accountId": "123456789" },
      "loginAccount":     { "accountType": "GOOGLE_ANALYTICS_PROPERTY", "accountId": "123456789" },
      "productDestinationId": "G-1T2E3S4T"
    }
  ],
  "consent": { "adUserData": "CONSENT_GRANTED", "adPersonalization": "CONSENT_GRANTED" },
  "events": [
    {
      "eventSource": "WEB",
      "eventName": "page_view",
      "eventTimestamp": "2026-06-04T12:53:00Z",
      "clientId": "1234567890.1234567890",
      "additionalEventParameters": [
        { "parameterName": "page_location", "value": "https://www.example.com/dmapi-test" },
        { "parameterName": "page_title",    "value": "DM API Test" }
      ]
    }
  ]
}

Diesmal kommt ein 200 OK mit einer requestId im Body zurück, etwa { "requestId": "9e2bb7b7-…" }. Das ist vergleichbar mit anderen Endpunkten wie der Meta CAPI, wo ebenfalls eine "Trace ID" zurück kommt, welche dem gleichen Zweck dient: Der anschließenden Kontrolle der Verarbeitung (siehe unten).

Validierung

Wer wissen will, ob ein Payload okay ist, kann ähnlich wie beim GAMP eine Validierung durchführen. Statt eines eigenen Endpunkts wird dazu nur ein Key validateOnly mit dem Wert true in die erste Ebene der Nutzlast gepackt und dann versendet. Statt der Verarbeitung bekommt man dann ein Validierungsergebnis zurück, das wie beim Measurement Protocol dabei hilft, evtl. Formatfehler oder fehlende Pflichtangaben zu korrigieren.

Format: Ziele -> Events

Die GA-Property steckt in destinations[].productDestinationId, adressiert über operatingAccount und loginAccount. Aus dem params-Objekt wird ein Array aus {parameterName, value}, aus timestamp_micros ein RFC-3339-Zeitstempel. Consent kann auch hier wieder optional übergeben werden.

Eine 200 mit requestId bedeutet allerdings erstmal nur: "angenommen". Ob die Daten die Verarbeitung auch überleben, steht auf einem anderen Blatt - und das verrät erst ein zweiter Aufruf:

GET https://datamanager.googleapis.com/v1/requestStatus:retrieve?requestId=<ID>

Diese zweistufige Logik (erst annehmen, später verarbeiten) kennt das Measurement Protocol so nicht. Im GA4-Alltag ist sie verschmerzbar, im Ads-Kontext wird sie zum entscheidenden Detail (mehr dazu in einem Folgebeitrag).

Das Mapping für die Umstellung

Für die eigentliche Migration muss man zum Glück nicht raten. Google liefert eine offizielle und ausführliche (und damit hilfreiche) Mapping-Tabelle: Field mappings - Measurement Protocol zur Data Manager API. Die für den Alltag wichtigsten Zeilen, eingedampft:

Eine beruhigende Nachricht: Die Regeln fürs Hashen von user_data (E-Mail, Telefon, Name normalisieren, dann SHA-256) sind dieselben wie beim Measurement Protocol und bei gtag.

Erste Schritte im OAuth 2.0 Playground

Statt gleich Code zu schreiben und den für den realen Einsatz erforderlichen Service Account anzulegen, lohnt ein manueller Test im OAuth 2.0 Playground mit den eigenen Credentials. Dort spielt man den ganzen Flow durch und kann danach seine Events testen und den neuen Weg relativ einfach erproben:

• in Step 1 den Scope https://www.googleapis.com/auth/datamanager autorisieren,
• in Step 3 die Methode POST, die URL https://datamanager.googleapis.com/v1/events:ingest und den JSON-Body eintragen.
• „Send the request" verwendet das aktuelle Bearer-Token und verschickt das Event (oder die Events, denn auch hier ist Batching möglich und sinnvoll).

Praktisch: Auch requestStatus:retrieve lässt sich hier mit dem Nutzer-Token abfragen. Dass die Events wirklich ankommen, zeigt anschließend auch der GA4-Bericht - im Screenshot tauchen die „EXP"-Testseiten und der dmapi_test_click brav auf, allerdings muss man hier ein wenig warten. "Echtzeit" ist hier nicht allzu ernst zu nehmen. Wenn die Zeitstempel der gesendeten Events aber in das Fenster passen, sieht man früher oder später die Ergebnisse seiner Tests auch hier:

Latenz: hier scheitert es in der Praxis

Wenn schon die Fähigkeiten gleich sind, entscheidet die Praxistauglichkeit. Und da fällt die Data Manager API für den synchronen Einsatz durch. Gleicher Rechner, gleiche Messmethode (Zeit bis zur HTTP-Antwort), je 50 Messungen:

(Werte in Millisekunden.)

Im Schnitt ist die Data Manager API rund 26-mal langsamer als gtag oder MP - knapp 2,7 Sekunden im Mittel, im p95 fast fünf, und das Ganze zudem ziemlich unvorhersehbar. Für einen synchronen Aufruf im Request-Pfad, der vielleicht nach 500 Millisekunden in ein Timeout läuft, ist das unbrauchbar. Mist, könnte man sagen, wenn man gehofft hatte, "einfach" den Endpunkt und das Format zu tauschen.

Wer die Data Manager API einsetzt, sollte sie niemals synchron aufrufen. Events spoolen, in einer Queue sammeln und im Hintergrund per Batch oder Worker abschicken, die requestId aufheben und den Status separat prüfen - das scheint der einzig vernünftige Weg zu sein, wenn man die Performance der eigenen Systeme nicht belasten will. Für GA4-Hits, die eigentlich „live" sein wollen, ist das ein Rückschritt. Für Conversions, die ohnehin asynchron eintreffen, stört es kein bisschen - und genau da wird die API interessant.

Muss man jetzt umstellen? Für GA4: Lieber nicht

Für Google Analytics fällt die Antwort wie oben schon verraten aus: Niemand muss heute wechseln. Die Data Manager API kann fürs GA4-Tracking nichts, was das Measurement Protocol nicht auch könnte, ist dabei aber langsamer und in der Authentifizierung deutlich aufwendiger. Wer sich dennoch jenseits des OAuth-Playground mit der Anbindung befassen will, braucht also einen Service Account und muss diesen für die zu nutzende Google Analytics Property als Nutzer eintragen.

Service Account anlegen, inkl. Ärger beim Zugriff

Einen Service Account legt man in einem Google-Cloud-Projekt (mit dort aktiver Data Manager API) an und erzeugt ggf. wie oben angesprochen einen JSON-Key (siehe Service Accounts erstellen, Keys verwalten).

Probleme beim Property-Zugriff: Für GA4 muss die so erzeugte Service-Account-Mailadresse als Nutzer der Property (Editor) hinterlegt sein. Trägt man sie aber in der GA4-Oberfläche unter „Verwaltung → Property-Zugriffsverwaltung" ein, wird sie nicht akzeptiert:

Das Problem ist bekannt, aber von Google bisher nicht gelöst. Alte SA mit Mailadressen in einem anderen Format funktionieren hingegen. Bis Google das bereinigt hat, hilft derzeit nur ein Umweg über den API Explorer der Admin-API.

So geht es:

1. API Explorer öffnen: properties.accessBindings.create, rechts den API-Tab aufklappen.
2. Im Feld parent die Property eintragen: properties/DEINE_GA4_PROPERTY_ID (die ID steht in der GA4-URL: analytics.google.com/analytics/web/#/pXXXXXXXXX).
3. Den Request Body mit der Mailadresse des SA wie folgt aufbauen:

   { "user": "[email protected]", "roles": ["predefinedRoles/editor"] }

4. „Execute" und mit einem Google-Konto anmelden, das GA4-Admin-Rechte hat.
5. Eine 200er-Antwort mit Mail und Rolle bestätigt den Erfolg.
6. Gegenprobe in GA4 unter „Verwaltung → Property-Zugriffsverwaltung": Der Service Account steht jetzt im Idealfall drin und kann verwendet werden.

Anschließend kann man über den Service Account auch ohne das eigene Login im Browser Daten an seine GA Property senden. Für den Einstieg habe ich ein entsprechendes Colab Notebook als GitHub Gist angelegt, in dem die erforderlichen Schritte demonstriert werden und ebenso wie im Playground mit eigenen Daten erprobt werden können.

Zum Colab-Notebook

Dieses Beispiel konzentriert sich ebenfalls auf Google Analytics als Destination für die Daten, zeigt aber auch Beispiele für "Enhanced Conversions for Leads" per Data Manager API. Denn es gibt ja noch Google Ads und da liegt der Hauptnutzen und Fokus der neuen API. Und bei Ads dreht sich der Spieß zudem komplett um: Da ist die Data Manager API schon jetzt für alle neuen Anbindungen der vorgesehene Weg, mit echten Deadlines. Wer heute damit anfangen will, Conversions per API zu liefern, kommt bereits nicht mehr über die Ads API zum Erfolg, sondern muss die Data Manager API verwenden. Inkl. ein paar fieser Fallstricke und einem Verhalten, das mich beim Testen mehr als einmal an mir zweifeln ließ - HTTP 200, alles grün, und im Konto trotzdem: nichts. Wie das kommt und was man dagegen tut, steht im nächsten Beitrag - der erscheint in der übernächsten Ausgabe des Analytics Pioneers Magazins. Bis dahin gilt für GA4: Never change a running mp/collect (wenn Du nicht musst). 😉