GA4 Measurement Protocol: Nutzlasten, Grenzen und Prüfung vor dem Versand

Das Measurement Protocol übermittelt Ereignisse vom Server an Google Analytics 4. Ein Beispiel ist eine Zahlung, deren Bestätigung erst später vom Zahlungsdienst eintrifft. Die Nutzlast ist der Inhalt dieser Übermittlung: ein JSON-Dokument mit Kennungen und Ereignisdaten. Das Protokoll ergänzt die Erfassung über das Google-Tag oder das Firebase-SDK. Ein Serveraufruf ersetzt weder eine vollständige Browserintegration noch die Entscheidung über zulässige Datenverarbeitung.

Die wichtigste Unterscheidung lautet: Eine HTTP-Antwort aus der 2xx-Gruppe bestätigt den Empfang der Anfrage, nicht die Aufnahme des Ereignisses in einen Bericht. Auch fehlerhafte Daten können ohne aussagekräftigen HTTP-Fehler bleiben. Ein fester Statuscode 204 für jede denkbare Anfrage ist dagegen keine zugesicherte Schnittstelleneigenschaft.

Adresse, Geheimnis und Inhalt

Der Versand erfolgt als HTTPS-POST an https://www.google-analytics.com/mp/collect. Für die Datenerhebung in der EU dokumentiert Google https://region1.google-analytics.com/mp/collect. Daraus allein folgt keine Zusage, dass sämtliche anschließenden Verarbeitungsschritte ausschließlich in der EU stattfinden.

Bei einem Web-Datenstrom stehen measurement_id und api_secret in den URL-Parametern. Die Mess-ID bezeichnet den Datenstrom; das API-Geheimnis erlaubt die Übermittlung. Nur das Geheimnis ist vertraulich. Browsercode, öffentliche Repositories und unbereinigte URL-Protokolle sind dafür ungeeignet. Für Apps tritt firebase_app_id an die Stelle der Mess-ID.

Im JSON steht bei Web-Ereignissen client_id, bei Apps die vom Firebase-SDK gelieferte app_instance_id. Für die Verbindung mit einem vorhandenen Webseitenbesuch muss die Client-ID zur Kennung des Google-Tags passen. Eine neue Zufallskennung bei jeder Zahlung erschwert diese Verbindung und kann Nutzerzahlen verfälschen. Daraus folgt jedoch nicht automatisch eine neue Sitzung pro Anfrage.

Ein kleines Kaufbeispiel

Das folgende JSON zeigt die Struktur eines Web-Kaufs. Alle Kennungen und die Interaktionsdauer sind Beispieldaten und vor einem echten Versand durch passende Werte zu ersetzen. Die optionale Interaktionsdauer darf nur tatsächlich gemessene Zeit seit dem vorherigen Ereignis abbilden; eine Hintergrundzahlung liefert dafür allein keine Messung. Ohne nachgereichten Zeitpunkt gilt die Empfangszeit.

{
  "client_id": "1234567890.1700000000",
  "events": [
    {
      "name": "purchase",
      "params": {
        "transaction_id": "T-8891",
        "currency": "EUR",
        "value": 20,
        "session_id": 1700000000,
        "engagement_time_msec": 100,
        "items": [
          {
            "item_id": "A-1",
            "price": 10,
            "quantity": 2
          }
        ]
      }
    }
  ]
}

Der Warenwert ergibt sich hier aus 10 Euro mal 2 Stück. value enthält den Warenwert ohne separat ausgewiesene Versandkosten und Steuern; currency bezeichnet die Währung. Eine stabile, eindeutige transaction_id unterstützt die Vermeidung doppelter Käufe. Eine Wiederholung derselben technischen Übertragung darf deshalb keine neue Bestellnummer erzeugen.

session_id verbindet das Ereignis mit einer Sitzung; eine neue Sitzungskennung kann eine neue Sitzung erzeugen. engagement_time_msec beschreibt Interaktionszeit in Millisekunden. Beide Werte helfen bei Sitzungs- und Interaktionskennzahlen sowie in Echtzeitberichten. Fehlende Werte erklären mögliche Lücken, beweisen aber nicht pauschal, dass ein Ereignis in jedem Bericht fehlt.

Optionale Felder gezielt einsetzen

user_id ist eine optionale interne Nutzerkennung. E-Mail-Adressen oder Telefonnummern gehören weder dort noch in gewöhnliche Ereignisparameter oder Nutzereigenschaften. Die gesonderte Funktion user_data hat eigene Voraussetzungen und Regeln zur Aufbereitung, etwa zur Normalisierung und zum Hashen bestimmter Angaben. Das Feld ist keine Erlaubnis für beliebige personenbezogene Inhalte.

user_properties beschreibt Eigenschaften wie eine Kundenstufe. user_location, ip_override und device können Standort- beziehungsweise Geräteangaben liefern. Zusätzliche Daten sind nur sinnvoll, wenn Herkunft, Genauigkeit und zulässige Verwendung geklärt sind. Ein unverändertes dataLayer-Objekt passt nicht automatisch in dieses Protokoll. Eigene Felder müssen nach der Referenz zugeordnet und geprüft werden; die Dokumentation sagt nicht, dass ein unbekannter Schlüssel in jedem Fall die gesamte Anfrage unbrauchbar macht.

Namen und wichtige Grenzen

Empfohlene Ereignisnamen haben eine festgelegte Bedeutung. purchase ist der Kauf; Purchase ist wegen der Großschreibung ein anderer Name. Reservierte Namen wie session_start sind kein Ersatz für eine korrekt gesetzte Sitzungskennung. screen_view, ad_impression und in_app_purchase sind für App-Datenströme vorgesehen.

Die Versand-Anleitung nennt höchstens zehn eigene Item-Parameter, die Ereignisreferenz bei purchase hingegen 27. Bis zur Klärung dieses Dokumentationswiderspruchs ist zehn die vorsichtigere Grenze für Measurement-Protocol-Anfragen. Die Tabelle fasst häufig relevante Grenzen zusammen und ersetzt keine Prüfung der jeweiligen Ereignisreferenz.

Zeichen und Bytes sind verschiedene Größen. Ein Umlaut benötigt in UTF-8 mehr als ein Byte. Entscheidend für die Anfragegröße ist deshalb das fertig serialisierte JSON, beispielsweise Buffer.byteLength(JSON.stringify(payload), 'utf8') in Node.js. Eine feste Grenze von 29 Artikeln pro Ereignis gibt es nicht: längere Produktnamen und zusätzliche Felder verändern die Größe. Ein Paket muss gleichzeitig zur Ereigniszahl und zur Byte-Grenze passen.

Zeitstempel ohne Einheitenfehler

timestamp_micros verwendet Mikrosekunden seit dem 1. Januar 1970. Für einen vorhandenen JavaScript-Zeitwert in Millisekunden ergibt eventTimeMs * 1000 die benötigte Einheit. Eine fälschlich als Mikrosekunden gesendete Millisekundenzahl bezeichnet rechnerisch einen Zeitpunkt im Jahr 1970.

Bei mehr als 72 Stunden alten Zeitpunkten unterscheidet Google zwei Fälle: Ohne validation_behavior oder mit RELAXED wird der Zeitpunkt auf 72 Stunden vor Empfang begrenzt. Mit ENFORCE_RECOMMENDATIONS wird das Ereignis abgelehnt. Der Einheitenfehler kann deshalb eine falsche zeitliche Zuordnung statt eines vollständigen Verlusts auslösen.

Für die Verbindung mit bereits vom Tag oder SDK erfassten Ereignissen nennt die Versand-Anleitung zusätzlich ein 48-Stunden-Fenster. Die zulässige Rückdatierung allein garantiert also keine korrekte Zuordnung zu Werbung oder früheren Besuchen.

Ein weiterer Dokumentationswiderspruch betrifft Zeitstempel einzelner Ereignisse: Die Versand-Anleitung zeigt timestamp_micros direkt am Ereignis, die Referenz führt den Wert unter den Ereignisparametern. Eine einfache Umsetzung verwendet den eindeutig dokumentierten Zeitstempel auf Anfrageebene und fasst nur Ereignisse mit demselben Zeitpunkt zusammen. Unterschiedliche Zeitpunkte benötigen dann getrennte Anfragen.

Einwilligung und Validierung

Das consent-Objekt kennt ad_user_data und ad_personalization mit GRANTED oder DENIED. Ohne dieses Objekt verwendet GA4 die Einstellungen zugehöriger Online-Interaktionen. analytics_storage und ad_storage sind hier keine dokumentierten Felder. Der Absender braucht deshalb vor dem Versand eine eigene Entscheidung, ob die Übermittlung stattfinden darf. Eine fehlende Client-ID oder ein Werbeblocker ist kein Anlass, eine Ablehnung durch erfundene Kennungen zu umgehen. non_personalized_ads ist veraltet; vorgesehen ist consent.ad_personalization.

Der Prüfendpunkt /debug/mp/collect liefert validationMessages. Diese Testereignisse erscheinen nicht in Berichten. Google empfiehlt im Test ENFORCE_RECOMMENDATIONS und im Produktivbetrieb das Weglassen von validation_behavior. Eine leere Meldungsliste ist trotzdem kein Ende-zu-Ende-Nachweis: Der Prüfendpunkt kontrolliert die Datenstromkennung und das API-Geheimnis nicht.