Tutorial: Eine GA4-Collect-Anfrage Parameter für Parameter lesen

Eine GA4-Collect-Anfrage zeigt, welche Daten ein Browser an eine Sammelstelle zu senden versucht. URL, Anfragekörper und Header gehören zusammen. Der Anfragekörper enthält Daten außerhalb der URL; Header übermitteln Zusatzangaben zur Anfrage, etwa den Inhaltstyp. Eine Anfrage kann mehrere Ereignisse enthalten; der spätere Bericht hängt zusätzlich von Verarbeitung, Konfiguration und weiteren Datenquellen ab. Eine feste Liste von sechzig Parametern erklärt deshalb nicht jede Anfrage.

Die folgenden Kürzel dienen zur Diagnose des Browsertransports des Google-Tags. Das ist keine stabile öffentliche Schnittstelle zum Erzeugen eigener Anfragen. Dokumentierte gtag-Ereignisfelder und Measurement Protocol sind gesonderte Schnittstellen. Interne Kodierungen können wechseln; die aktuelle Google-Tag-Implementierung wurde am 24. Oktober 2026 geprüft.

Die gesamte Anfrage statt nur der URL

Die Aufzeichnung in DevTools beginnt vor der Testaktion; Preserve log erhält Einträge über Navigationen hinweg. Ein Filter auf collect ist ein sinnvoller Einstieg, kann aber andere Dienste erfassen und einen eigenen Pfad für die Datensammlung übersehen. Zieladresse, Methode, Auslöser, Zeitpunkt, Nutzdaten und Antwort bestimmen den tatsächlichen Weg.

Parameter können in der Abfragezeichenfolge, im POST-Körper oder in beiden stehen. Gebündelte Anfragen können gemeinsame URL-Parameter für mehrere Ereigniszeilen verwenden. Kleine GET- und große POST-Anfragen sind keine allgemeingültige Regel. Ein zeilenweise kodierter Stapel benötigt die gemeinsame Konfiguration und die einzelnen Ereignisdatensätze; beliebige Zeilen eines unbekannten Anfragekörpers sind nicht automatisch Ereignisse.

Das folgende künstliche Beispiel ist zur Lesbarkeit umbrochen und keine reale Anfrage. Die Kennungen sind Platzhalter. Der Kauf enthält Transaktionskennung, Wert, Währung und einen Artikel; das Beispiel dient zur Prüfung, nicht zum manuellen erneuten Senden eines Kaufs.

https://www.google-analytics.com/g/collect
  ?v=2&tid=G-EXAMPLE&cid=1234567890.1737041234
  &sid=1737041234&sct=4&dl=https%3A%2F%2Fshop.example%2Fcheckout
  &dt=Checkout&en=purchase&ep.transaction_id=ORDER-EXAMPLE-42
  &epn.value=129.9&cu=EUR
  &pr1=idSKU-42~nmChair~pr64.95~qt2

Ziel und Sitzungskontext

Nicht jede Anfrage enthält jedes Feld. Eine Mess-ID bezeichnet einen Web-Datenstream innerhalb einer Property. Eine Client-Kennung beschreibt eine Browserinstanz statt einer verifizierten Person; Speicherfreigabe, Konfiguration und domainübergreifende Messung beeinflussen Herkunft und Beständigkeit.

Automatisch erzeugte GA4-Sitzungskennungen verwenden Sekunden seit dem 1. Januar 1970 um 00:00 UTC, dem Beginn der Unix-Epoche. Die Sitzungskennung allein ist nicht weltweit eindeutig; selbst gesetzte oder serverseitig gelieferte Werte benötigen eine eigene Prüfung. Eine Lücke in einem internen Zähler beweist keinen Netzwerkverlust: Aufzeichnungsbeginn, Filter, Bündelung und mehrere Ziele können die sichtbare Folge beeinflussen. Fehlende Anfragen können auch durch Skriptfehler, CSP, andere Endpunkte oder nicht passende Auslöser entstehen. Netzwerkansicht, Konsole und Tag Assistant liefern ergänzende Nachweise.

Seitenkontext und sensible Daten

dl, dr und dt übertragen üblicherweise Seitenadresse, Verweis und Titel. Standardwerte stammen aus dem Browserdokument, können aber durch Vorgaben und Datenredaktion verändert werden. Ein fehlender Verweis beweist keinen direkten Einstieg: Browserregeln und Datenschutzmechanismen können den Wert unterdrücken. In Einzelseitenanwendungen wechseln Inhalte ohne vollständiges Neuladen des Dokuments. Dort müssen Ereigniszeitpunkt und ausdrücklich gesetzter Titel zur vorgesehenen Seite passen.

ul und sr beschreiben Sprache und Bildschirmauflösung. Englische Spracheinstellungen und 800×600 Pixel beweisen keine Automatisierung. Diese Angaben sind weder Identitätsprüfung noch zuverlässige Botklassifikation.

Die dekodierte Seitenadresse benötigt eine Prüfung auf sensible Pfade, Abfragewerte und andere unbeabsichtigte Angaben. Query-Inhalte werden nicht automatisch zu benutzerdefinierten Dimensionen; Seitenpfad und vollständige Seitenadresse sind verschiedene Dimensionen. Konfigurierte Datenredaktion kann ausgewählte Angaben vor dem Versand entfernen, erfasst aber nur die vorgesehenen Datenarten und garantiert keine vollständige Erkennung aller sensiblen Angaben. Eine unauffällige URL bewertet nicht die übrigen Parameter oder Header.

Ereigniswerte und Interaktion

en bezeichnet üblicherweise das Ereignis. Allgemeine Felder mit ep./epn. unterscheiden im geprüften Transport Text- und Zahlenwerte. up./upn. erfüllen eine ähnliche Aufgabe für Nutzereigenschaften; vordefinierte Felder können eigene Kürzel besitzen, etwa cu für Währung. Normalisiert eine Vorlage einen Eingabewert, bleibt die tatsächliche Anfrage die entscheidende Gegenprobe.

Ein Transportpräfix erzeugt nicht automatisch eine Berichtsdimension oder Kennzahl. Eigene Berichte benötigen die passende Definition; zahlenähnliche Dimensionszeichenfolgen kann Google als Zahlen interpretieren. Zahlenwerte sollten bereits an der Quelle zum dokumentierten Ereignisschema passen. Number allein genügt nicht zur Validierung: Eine leere Zeichenfolge wird zur Zahl 0, ein Dezimalkomma ergibt NaN, und Infinity ist kein brauchbarer endlicher Betrag.

_et steht üblicherweise für Interaktionsmillisekunden. Interaktion misst die Zeit mit fokussierter Seite oder Anwendung im Vordergrund, nicht einfach den zeitlichen Abstand zwischen HTTP-Anfragen. Der Wert kann einem späteren Ereignis zugeordnet werden oder ohne neue Interaktionszeit fehlen. Null oder fehlende Angabe beweisen keinen Besuch ohne menschliche Beteiligung.

Artikel und Kaufsummen

Im geprüften Browserformat können pr1, pr2 und weitere Felder jeweils einen gepackten Artikel enthalten. Die folgende Zuordnung häufiger Artikelkürzel hilft beim Lesen, ist aber keine vollständige Parser-Spezifikation. Trennzeichen, Kodierung und eigene Artikelparameter benötigen gesonderte Aufmerksamkeit.

Ein dokumentierter Artikel benötigt item_id oder item_name; beide Angaben sind empfohlen. Eine fehlende id allein bedeutet keine Verwerfung. Der Kaufwert entspricht der Summe aus Artikelpreis mal Menge ohne Versand und Steuer, zusammen mit einer passenden Währung. Im Beispiel ergeben 64,95 × 2 genau 129,90. Transaktionskennungen müssen tatsächliche Käufe konsistent bezeichnen, damit doppelte Übermittlungen erkennbar bleiben.

Das dokumentierte items-Array erlaubt bis zu 200 Elemente. Genau 200 Artikel beweisen keinen Transportüberlauf, und eine verkürzte Berichtsliste hat keine automatische Einzelursache. Eingabeaufbau, Ereignisgrenzen, Verarbeitung und Berichtsumfang benötigen einen Abgleich. Ereignisumsatz und Artikelumsatz besitzen unterschiedliche Bezugsbereiche; Abweichungen lassen sich auch in passenden Berichten oder Exporten untersuchen.

Einwilligungssignale und Grenzen

gcs überträgt Zustände für Werbe- und Analysespeicher. Häufige Werte sind G111 für beide erteilt, G100 für beide abgelehnt, G101 nur für Analysespeicher und G110 nur für Werbespeicher. Diese Werte decken zwei Signale ab, nicht die gesamte Einwilligungsimplementierung. gcd enthält detailliertere Angaben zur Einwilligung und wird auch ohne aktiven Consent Mode gesendet; das Feld beschreibt nicht lediglich Voreinstellungen.

Tag Assistant macht Voreinstellungen, Aktualisierungen und die vier relevanten Google-Signale verständlich prüfbar: ad_storage, analytics_storage, ad_user_data und ad_personalization. Die gemeldeten Zustände benötigen einen Abgleich mit Reihenfolge, tatsächlichem Tagverhalten, Speicherung und Bannerentscheidung einschließlich eines späteren Widerrufs.

Der erweiterte Consent Mode kann bei abgelehntem Analysespeicher Messungen ohne Cookies senden; der grundlegende Modus blockiert Google-Tags bis zur erforderlichen Einwilligung. Eine G100-Anfrage allein beweist weder korrekte Initialisierung noch das Fehlen aller Kennungen oder die Berechtigung zur Modellierung. Cookiefreie Signale können eine Zufallskennung je Seitenaufruf enthalten; eine neue Client-ID je Anfrage ist keine sichere allgemeine Annahme. Keine sichtbare Anfrage erklärt allein noch nicht den Blockierungsgrund.

Empfang und serverseitige Verarbeitung

HTTP 204 bedeutet eine Antwort ohne Inhalt. Das ist weder eine Schemafreigabe jedes Ereignisses noch eine Garantie für den späteren Bericht. DebugView erfordert den Debugmodus und kann Ereignisse bei clientseitigen Datenschutzmechanismen oder abgelehnter Analyse-Cookie-Einwilligung auslassen. Echtzeitansicht und verarbeitete Berichte beantworten andere Fragen und sind keine vollständigen Rohdatenprotokolle.

Bei serverseitigem Tagging zeigt der Browser gewöhnlich nur den Weg zum Servercontainer. Dessen Vorschau zeigt eingehende Anfrage, zuständigen Client, Ereignisdaten, ausgelöste Tags und ausgehende Anfragen. Damit werden ergänzte, entfernte oder veränderte Felder prüfbar. Browserdaten allein belegen nicht, was die nachgelagerte Sammelstelle empfangen und später verarbeitet hat.

Kann GA4 einen fehlenden Parameter niemals erfahren?

Ein fehlendes Feld belegt ausschließlich die Abwesenheit in diesem Teil der Aufzeichnung. Anfragekörper, Header, weitere Anfragen, Serverergänzungen und spätere Verarbeitung sind gesonderte Quellen.

Ist Collect das Measurement Protocol?

Der beschriebene Browsertransport und das dokumentierte JSON-Measurement-Protocol besitzen unterschiedliche Formate und Prüfabläufe. Eine Browser-Abfragezeichenfolge ist keine JSON-Nutzlast des Measurement Protocol.

Praxiskontrolle: mehrere Collect-Requests vergleichen

Der GA4-Parameter-Analyser kann mehrere Browser-Collect-Requests gemeinsam untersuchen. Je Zeile wird eine URL oder ein URL-kodierter Query-/Body-String eingetragen. Gehören Parameter zur gemeinsamen URL eines POST-Requests, macht das separate Feld für gemeinsame Parameter diesen Kontext in jeder Zeile sichtbar.

Die Übersicht zeigt Ereignisnamen, Mess-IDs und wiederholte Parameterschlüssel. Im Vergleich stehen nur Unterschiede: Ein fehlender Schlüssel ist etwas anderes als ein Schlüssel mit leerem Wert. Verschiedene Ereignistypen enthalten naturgemäß unterschiedliche Parameter; eine Abweichung allein belegt deshalb keinen Trackingfehler. Wiederholte Schlüssel bleiben in ihrer ursprünglichen Reihenfolge erhalten. Das Werkzeug behauptet nicht, welches Vorkommen der Empfänger verwendet.

Werte werden einmal dekodiert und als Text dargestellt, auch bei HTML-ähnlichem Inhalt. Die optionale CSV enthält die dekodierten Werte und ist nicht anonymisiert. Damit hilft der Analyser beim Untersuchen einer unerwarteten Seitenadresse oder eines Parameters, ist aber kein vollständiger Detektor für personenbezogene Daten. Ein unauffälliges Ergebnis belegt keine personenbezugsfreie Implementierung.

Kein eingefügter Request wird erneut abgespielt oder hochgeladen. Das Werkzeug beschreibt die Eingabe, nicht deren Annahme durch Google. Die tatsächliche Erfassung lässt sich gegebenenfalls über Google DebugView prüfen. Die Querydekodierung folgt den URL-Formkodierungsregeln; gepackte Artikelsegmente werden nur heuristisch aufgeschlüsselt. Für JSON-Nutzdaten des Measurement Protocol ist der separate Validator vorgesehen.

Quellen

• Google Analytics: Empfohlene Ereignisse und Kauffelder
• Google Tag Platform: Consent Mode im Überblick
• Google Analytics: Nutzerinteraktion
• Google Analytics: Konfigurationsreferenz
• Google Analytics: Benutzerdefinierte Dimensionen und Messwerte
• Google Analytics: Datenredaktion
• Chrome DevTools: Netzwerkfunktionen
• Google Analytics: Ereignisse in DebugView überwachen
• Google Tag Manager: Servercontainer in Vorschau prüfen
• Google Tag Platform: Consent Mode mit Tag Assistant prüfen
• Google Analytics: Sitzungen in Analytics
• Google Analytics: E-Commerce messen
• Google Tag: Ausgelieferte JavaScript-Implementierung, geprüft am 24. Oktober 2026
• IETF RFC 9110: 204 – Antwort ohne Inhalt
• MDN: JavaScript Number
• Google Analytics: Measurement-Protocol-Ereignisse prüfen