GA4 Measurement Protocol debuggen: Warum 2xx nichts beweist

Das GA4 Measurement Protocol gibt für fast alles, was Sie an es senden, einen 2xx-Status zurück: für ein gültiges Ereignis, ein falsch geschriebenes Ereignis, ein Ereignis ohne client_id und ein frei erfundenes Secret. Der Statuscode ist beim Debuggen daher nutzlos. Um Aufrufe des GA4 Measurement Protocol zu debuggen, senden Sie denselben Body an den Validierungsserver unter /debug/mp/collect, lesen die zurückgegebenen validationMessages, beheben die dort genannten Probleme und bestätigen erst danach den Eingang in DebugView oder Realtime.

Dieser letzte Schritt ist wichtiger, als viele erwarten. Warum? Der Validierungsserver prüft Ihr API-Secret nicht. Ein Payload kann also die Validierung bestehen, vom echten Endpunkt einen 204 erhalten und trotzdem nie in Ihrer Property ankommen. Ich habe schon erlebt, wie ein Team genau dadurch eine Woche verlor, bevor jemand auf die Idee kam, das Secret noch einmal zu kopieren.

Wenn Sie serverseitige Ereignisse zur Kampagnenmessung einrichten, erklärt der Grundlagenleitfaden UTMs von Anfang bis Ende verfolgen, was vor all dem im Link enthalten sein sollte. In diesem Beitrag geht es um den Moment, in dem Sie das Ereignis senden und nichts erscheint.

Warum das Measurement Protocol auf alles mit 2xx antwortet

Googles Protokollreferenz sagt es unmissverständlich: Der Endpunkt gibt einen 2xx-Statuscode zurück, wenn die HTTP-Anfrage empfangen wurde. Er gibt keinen Fehler zurück, wenn der Payload fehlerhaft ist oder die Daten nicht verarbeitet werden. Die Erfassung erfolgt ohne Rückmeldung. Ihr Server wartet nie auf die Verarbeitung.

Wir haben das selbst überprüft. Ein POST an /mp/collect mit dem Body {"garbage":true}, einer gefälschten Measurement ID und einem erfundenen Secret kam als HTTP 204 mit leerem Body zurück. Genau wie ein perfektes Ereignis.

Eine an Statuscodes geknüpfte Wiederholungslogik erkennt Netzwerkfehler. Sonst nichts. Sie kann Ihnen nicht sagen, dass GA4 Ihre Ereignisse verworfen hat. Dafür brauchen Sie den zweiten Endpunkt.

So verwenden Sie den Validierungsserver unter /debug/mp/collect

Der Validierungsserver des Measurement Protocol liegt auf demselben Host. Abfragezeichenfolge und Body bleiben gleich:

curl -s -X POST \
  "https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXXXX&api_secret=YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"events":[{"name":"session_start","params":{"firebase_x":1}}]}'

Er antwortet mit 200 und einem JSON-Body statt mit einem leeren Body. Dieser Test-Payload enthält drei Probleme, und der Server meldet das erste, auf das er stößt:

{
  "validationMessages": [
    {
      "fieldPath": "client_id",
      "description": "Measurement requires a client_id.",
      "validationCode": "VALUE_REQUIRED"
    }
  ]
}

Fügen Sie eine client_id hinzu, und der Server geht zu NAME_RESERVED für session_start weiter. Benennen Sie das Ereignis um, und als Nächstes ist das Präfix firebase_ an der Reihe. Jede Meldung enthält einen fieldPath, eine verständliche Beschreibung und einen Code. Zu den von Google dokumentierten Codes gehören VALUE_INVALID, VALUE_REQUIRED, NAME_INVALID, NAME_RESERVED, VALUE_OUT_OF_BOUNDS, EXCEEDED_MAX_ENTITIES und NAME_DUPLICATED.

Ein leeres Array, "validationMessages": [ ], bedeutet, dass die Struktur in Ordnung ist. Nichts, was an /debug/mp/collect gesendet wird, wird gespeichert. Verwenden Sie den Endpunkt während der Entwicklung so oft Sie möchten. Denken Sie nur daran, dass ein Debug-Aufruf niemals beweist, dass Daten angekommen sind.

Was der Validierungsserver nicht prüft

Die meisten Anleitungen übergehen diesen Punkt. Googles Seite zur Ereignisvalidierung sagt ausdrücklich, dass der Validierungsserver das api_secret nicht validiert. Bei unserem Test am 22. September 2026 prüfte er auch die Measurement ID nicht: G-FAKE123 mit dem Secret nonsense gab ein leeres validationMessages-Array zurück.

Ein falsches Secret wird akzeptiert. Dasselbe gilt für ein widerrufenes Secret, eines aus einem anderen Datenstream oder einen Tippfehler in G-. Das Measurement-Protocol-api_secret ist der häufigste Grund für "gültiger Payload, keine Daten", den ich sehe. Bestätigen können Sie es nur, indem Sie den Eingang eines Ereignisses beobachten.

Die zweite Lücke ist der Validierungsmodus. Standardmäßig läuft der Server im Modus RELAXED. In diesem Modus ließ er zwei Dinge durch, die Googles eigene Grenzen verbieten: ein Ereignis mit 26 Parametern und einen Parameterwert mit 120 Zeichen. Fügen Sie dem Debug-Body "validation_behavior": "ENFORCE_RECOMMENDATIONS" hinzu, und beide Prüfungen schlagen mit EXCEEDED_MAX_ENTITIES und VALUE_TOO_LONG fehl. Ich würde immer im strengen Modus validieren, auch wenn die Produktion im Modus RELAXED bleibt. Das ist der Unterschied zwischen einer echten Prüfung und bloßem Durchwinken.

Serverereignisse in GA4 DebugView und Realtime sehen

Sobald der Payload validiert ist, senden Sie ihn an den echten Endpunkt und beobachten Sie, wie er ankommt. Für Serverereignisse eignen sich zwei Ansichten. Die Standardberichte gehören nicht dazu, da sie 24 bis 48 Stunden hinterherhinken können.

DebugView benötigt eine Aktivierung pro Ereignis. Googles Leitfaden zur Verifizierung verlangt "debug_mode": 1 (oder true) in den Parametern des Ereignisses sowie ein positives engagement_time_msec. Nur Ereignisse mit diesem Kennzeichen werden angezeigt. Ein Batch, in dem es bei einem Ereignis fehlt, wirkt deshalb halb leer. Öffnen Sie Verwaltung und anschließend DebugView und warten Sie eine Minute.

Realtime benötigt nichts Zusätzliches. Scrollen Sie zur Karte "Event count by Event name" und suchen Sie nach Ihrem Ereignis. Google weist darauf hin, dass session_id und engagement_time_msec für die Anzeige der Nutzeraktivität in Realtime wichtig sind. Wenn ein Ereignis validiert wird, Realtime aber leer bleibt, prüfen Sie zuerst diese beiden Werte.

Ein weiterer Hinweis aus demselben Leitfaden: Bei Webstreams verwendet ein gültiges Ereignis laut Google eine client_id, die gtag.js bereits genutzt hat. Synthetische IDs werden weiterhin gezählt, jeweils als eigener Nutzer. Sie werden aber nie einer Browsersitzung zugeordnet. In einem auf Sitzungen basierenden Bericht erscheint das als langer Schweif von Nutzern mit nur einem Ereignis, den Sie erst erklären können, wenn Sie wissen, woher sie stammen. Mehr dazu im nächsten Abschnitt. Wenn nicht Ereignisse, sondern Kampagnendaten fehlen, behandelt UTM-Parameter werden in GA4 nicht angezeigt die DebugView-Seite dieses Problems.

Häufige Payload-Fehler und die Antwort des Validators

Die meisten fehlerhaften Ereignisse folgen einigen wenigen Mustern. Hier sehen Sie, was der Validierungsserver bei jedem davon zurückgab, als wir ihn am 22. September 2026 ausprobierten:

Zwei Zeilen verdienen einen Hinweis. Laut Referenz ist das Präfix ga_ reserviert. Der Validator akzeptierte ga_session_id bei unserem Versuch jedoch in beiden Modi. Betrachten Sie ein leeres Array daher nicht als Freigabe. Auch die Grenze von 100 Zeichen für Werte sorgt ständig für Probleme mit vollständigen Ziel-URLs: Eine Landingpage mit fünf UTM-Tags ist oft länger.

Die client_id selbst ist der knifflige Punkt. Jede Zeichenfolge besteht die Validierung im Modus RELAXED, aber der strenge Modus lehnte sowohl c1 als auch elido-12-4711 mit "It should be in . format" ab. Wenn Ihre Ereignisse mit Browsersitzungen verknüpft werden müssen, senden Sie den echten _ga-Wert. Der Leitfaden zur serverseitigen GA4-Erfassung erklärt diese Verknüpfung ausführlich.

So nutzen Elidos GA4-Event-Weiterleitung und der Verbindungstest diese Technik

Elido leitet Klicks auf Kurzlinks serverseitig an GA4 weiter. Sie fügen eine Measurement ID und ein Measurement-Protocol-API-Secret in der GA4-Karte unter Integrationen ein. Danach wird jeder Klick in diesem Arbeitsbereich zu einem link_click-Ereignis:

{
  "client_id": "elido-12-4711",
  "events": [
    {
      "name": "link_click",
      "params": {
        "workspace_id": 12,
        "link_id": 4711,
        "slug": "spring-26",
        "country": "DE",
        "device": "mobile",
        "destination": "https://shop.example/spring?utm_source=newsletter",
        "engagement_time_msec": 100
      }
    }
  ]
}

Die client_id lautet elido-<workspace>-<link>. Jeder Klick auf einen Link wird dadurch als derselbe GA4-Nutzer gelesen, und keiner wird einer Browsersitzung zugeordnet. Das ist der ehrliche Kompromiss dieser Methode ohne Cookie: Summen sowie Aufschlüsselungen nach Slug, Land und Gerät funktionieren, Nutzerzahlen und Sitzungstrichter jedoch nicht. Land und Gerät sind einfache Ereignisparameter. Registrieren Sie sie zunächst als benutzerdefinierte Dimensionen. Ein destination-Wert mit mehr als 100 Zeichen stößt außerdem an die oben genannte Grenze. Werten Sie stattdessen slug oder link_id aus.

Die Schaltfläche Test connection folgt der Reihenfolge, die dieser Artikel empfiehlt:

Zuerst sendet sie einen synthetischen link_click mit dem Kennzeichen elido_test: true an /debug/mp/collect. Wenn validationMessages nicht leer ist, schlägt der Test fehl und zeigt Googles Beschreibungen wortgetreu an. Wenn das Array leer ist, wird dasselbe Ereignis tatsächlich an /mp/collect gesendet. Unter der Schaltfläche sehen Sie die Antwort des Anbieters, also HTTP-Status, den Debug-Endpunkt mit Ihrer Measurement ID, aber niemals mit dem Secret, und Googles Body. Zusätzlich erscheint ein Hinweis, dass das Measurement Protocol das API-Secret nicht verifiziert.

Grün bedeutet also "gültig und von Google empfangen", nicht "in Ihrer Property vorhanden". Das Testereignis enthält debug_mode: 1 und elido_test: true, daher erscheint es in DebugView als link_click; auch Realtime funktioniert. Wenn Sie Klickereignisse in GA4 erfassen möchten, ohne auf jeder Landingpage ein Tag einzubauen, starten Sie einen Arbeitsbereich und richten Sie die GA4-Karte zunächst auf eine Test-Property.

Eine funktionierende Reihenfolge zum Debuggen des GA4 Measurement Protocol

Wenn GA4-Ereignisse nicht angezeigt werden, gehen Sie diese Reihenfolge durch und stoppen Sie beim ersten Fehler:

1. Senden Sie den Body an /debug/mp/collect mit validation_behavior auf ENFORCE_RECOMMENDATIONS. Beheben Sie jede Meldung.
2. Kopieren Sie das API-Secret erneut aus Verwaltung, Datenstreams, Ihrem Webstream, API-Secrets des Measurement Protocol. Prüfen Sie, ob es aus demselben Stream wie die G--ID stammt.
3. Senden Sie ein Ereignis an /mp/collect mit debug_mode: 1 und beobachten Sie DebugView zwei Minuten lang.
4. Entfernen Sie das Kennzeichen und prüfen Sie Realtime. Warten Sie anschließend ein bis zwei Tage auf die Standardberichte.

Bei Schritt 2 endet der größte Teil meines eigenen Debuggings. Googles Fehlerbehebungsseite beginnt mit denselben drei Fragen: Ist das Secret richtig, ist es noch gültig und wurde es exakt kopiert? Wenn die Zahlen schließlich fließen und trotzdem nicht mit Ihren Linkzahlen übereinstimmen, erklärt Kurzlink-Klicks im Vergleich zu GA4-Sitzungen die Abweichung. Serverseitiges Conversion-Tracking behandelt die Conversion-Ereignisse, die meist folgen. Dieselbe Gewohnheit, erst zu validieren und dann zu verifizieren, gilt auch für die anderen Ziele auf der Seite zum Conversion-Tracking.

Verwandte Beiträge im Blog

• Serverseitige GA4-Erfassung über Weiterleitungen - Zugangsdaten, Payload-Form und Verknüpfung der client_id.
• Mixpanel oder GA4 für Linkanalysen - welches Tool Ihre Klickdaten speichern sollte.
• Mixpanel-Link-Tracking - dieselbe Event-Weiterleitung an Mixpanel, mit dessen eigener Eigenheit, auf alles mit 200 zu antworten.
• UTM-Parameter werden in GA4 nicht angezeigt - die Variante dieses Debugging-Problems für Kampagnendaten.
• Serverseitiges Conversion-Tracking - GA4, Meta CAPI und TikTok im Vergleich.