{"id":17207,"date":"2026-10-10T12:30:00","date_gmt":"2026-10-10T10:30:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=17207"},"modified":"2026-10-09T22:41:29","modified_gmt":"2026-10-09T20:41:29","slug":"ga4-measurement-protocol-nutzlasten-jedes-feld-jede-grenze-und-warum","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/de\/digital-analytics-de\/ga4-measurement-protocol-nutzlasten-jedes-feld-jede-grenze-und-warum\/","title":{"rendered":"GA4-Measurement-Protocol-Nutzlasten: Jedes Feld, jede Grenze und warum der Endpunkt auf kaputtes JSON mit 204 antwortet"},"content":{"rendered":"

Eine Measurement-Protocol-Anfrage ist ein einziger HTTPS-POST: eine Abfragezeichenfolge mit zwei Zugangsdaten und ein JSON-Rumpf mit den Ereignissen. So kommen Daten in eine GA4-Property, die nicht aus einem Browser stammen \u2014 Offline-Conversions aus einem CRM, eine per Webhook best\u00e4tigte Zahlung, ein App-Backend, das Nachreichen von Treffern, die ein Werbeblocker verschluckt hat.<\/p>\n

Es ist zugleich der einzige Einlieferungsweg im ganzen Aufbau, der nie sagt, ob er funktioniert hat.<\/p>\n

\n\"Links
Woraus eine Nutzlast besteht und was der Produktivendpunkt antwortet, wenn Teile davon falsch sind.<\/figcaption><\/figure>\n

Was der Endpunkt antwortet<\/h2>\n

Neun Anfragen gingen am 9. September 2026 an https:\/\/www.google-analytics.com\/mp\/collect<\/code>, alle mit einer erfundenen Mess-ID, damit nirgends etwas erfasst werden konnte. Sieben davon waren absichtlich kaputt.<\/p>\n

Acht der neun kamen als 204 No Content<\/strong> zur\u00fcck, in rund 100 Millisekunden und mit leerem Rumpf. Nicht nur die g\u00fcltige: auch das Ereignis, dessen Name mit einem Unterstrich beginnt, das leere events<\/code>-Array, die Nutzlast mit einem erfundenen Feld ganz oben, die Anfrage ohne client_id<\/code> und ein Rumpf, der \u00fcberhaupt kein JSON war. Eine Anfrage ganz ohne Abfragezeichenfolge<\/strong> \u2014 ohne Mess-ID, ohne API-Geheimnis \u2014 kam ebenfalls mit 204 zur\u00fcck.<\/p>\n

Genau zwei Dinge erzeugten einen HTTP-Fehler, und keines davon ist ein Urteil \u00fcber die Nutzlast. Ein Rumpf von 140 kB wurde mit 413<\/strong> und einer HTML-Fehlerseite des Vorbaus abgelehnt, weil er die dokumentierte Grenze von 130 kB \u00fcberschritt, bevor \u00fcberhaupt etwas gelesen wurde. Ein GET<\/code> wurde mit 405<\/strong> abgelehnt.<\/p>\n

Der europ\u00e4ische Endpunkt region1.google-analytics.com<\/code> verh\u00e4lt sich gleich. \u00dcber je f\u00fcnf L\u00e4ufe lag die Umlaufzeit vom selben Server bei beiden Hosts im Mittel bei 90 Millisekunden.<\/p>\n

Der Antwortcode best\u00e4tigt also nur, dass die Anfrage angekommen ist. Ob das Ereignis verstanden und gespeichert wurde oder ein Parameter verloren ging, l\u00e4sst sich daraus nicht erkennen. Beim Senden bleiben diese Probleme unsichtbar; erst Stunden sp\u00e4ter fallen sie als fehlende Daten im Bericht auf.<\/p>\n

Wohin die Nutzlast wirklich geh\u00f6rt<\/h2>\n

Zwei Teile, und die Verwechslung liegt nahe.<\/p>\n

Die Abfragezeichenfolge<\/strong> tr\u00e4gt die Zugangsdaten: measurement_id<\/code> f\u00fcr einen Web-Datenstrom (oder firebase_app_id<\/code> f\u00fcr einen App-Datenstrom) und api_secret<\/code>, das je Datenstrom in der GA4-Verwaltung angelegt wird. Keines von beiden geh\u00f6rt ins JSON. Dort werden sie zu unbekannten Feldern, und ein unbekanntes Feld wird nicht \u00fcbergangen \u2014 es macht die gesamte Nutzlast unlesbar.<\/p>\n

Der Rumpf<\/strong> ist ein JSON-Objekt mit einem festen Satz erlaubter Schl\u00fcssel:<\/p>\n

{\n  \"client_id\": \"1234567890.1700000000\",\n  \"user_id\": \"crm-88213\",\n  \"timestamp_micros\": 1788000000000000,\n  \"consent\": { \"ad_user_data\": \"GRANTED\", \"ad_personalization\": \"DENIED\" },\n  \"user_properties\": { \"kundenstufe\": { \"value\": \"gold\" } },\n  \"events\": [\n    {\n      \"name\": \"purchase\",\n      \"params\": {\n        \"transaction_id\": \"T-8891\",\n        \"currency\": \"EUR\",\n        \"value\": 20,\n        \"session_id\": \"1700000000\",\n        \"engagement_time_msec\": 100,\n        \"items\": [\n          { \"item_id\": \"A-1\", \"item_name\": \"Hemd\", \"price\": 10, \"quantity\": 2 }\n        ]\n      }\n    }\n  ]\n}<\/code><\/pre>\n
Daneben erlaubt die Referenz user_data<\/code>, user_location<\/code>, ip_override<\/code>, device<\/code>, user_agent<\/code>, non_personalized_ads<\/code> und validation_behavior<\/code>. Das ist die vollst\u00e4ndige Liste. Alles andere \u2014 ein aus einem dataLayer-Objekt mitkopierter event<\/code>-Schl\u00fcssel, eine ecommerce<\/code>-H\u00fclle, eine Notiz f\u00fcr die Kollegin \u2014 kostet die ganze Anfrage.<\/p>\n
Die Kennungsfelder<\/h2>\n
client_id<\/code> ist auf einem Web-Datenstrom Pflicht und das eine Feld, das entscheidet, ob ein Ereignis zu einem vorhandenen Nutzer st\u00f6\u00dft oder einen neuen erfindet. Die empfohlene Form sind zwei positive Zahlen, durch einen Punkt verbunden \u2014 genau das, was gtag('get')<\/code> herausgibt und was die eingebaute Variable Analytics Client ID im Google Tag Manager liefert. Der volle Wert des _ga<\/code>-Cookies, GA1.1.1234567890.1700000000<\/code>, wird ebenfalls angenommen; die beiden Zahlen stecken darin.<\/p>\n
Ein auf dem Server erfundener Wert wird auch angenommen, und das ist der teure Fehler. Eine frische Kennung je Anfrage erzeugt jedes Mal einen frischen Nutzer und eine frische Sitzung \u2014 eine Property, die belebt aussieht und ausschlie\u00dflich aus Sitzungen mit je einem Ereignis besteht.<\/p>\n
App-Datenstr\u00f6me nutzen stattdessen app_instance_id<\/code>: 32 hexadezimale Zeichen aus dem Firebase-SDK, keine client_id unter anderem Namen. Beides zu senden schadet nicht und n\u00fctzt nicht; das Feld der jeweils anderen Datenstromart wird \u00fcbergangen.<\/p>\n
user_id<\/code> ist freiwillig, bis zu 256 Zeichen lang und muss eine Zeichenkette sein. Es ist ein Verkn\u00fcpfungsschl\u00fcssel, keine Person: Eine Mailadresse oder eine Telefonnummer in diesem Feld ist ein personenbezogenes Datum, was die Nutzungsbedingungen von Google Analytics verbieten und was als Grund f\u00fcr die L\u00f6schung einer Property gen\u00fcgt. Dasselbe gilt f\u00fcr jeden Ereignisparameter und jede Nutzereigenschaft.<\/p>\n
Die zwei Parameter, an denen h\u00e4ngt, ob die Berichte aufgehen<\/h2>\n
Ein Ereignis ohne session_id<\/code> geh\u00f6rt zu keiner Sitzung. Gespeichert und z\u00e4hlbar ist es trotzdem, aber Sitzungen, engagierte Sitzungen und die sitzungsbezogenen Dimensionen gehen nicht auf, und in der Echtzeit fehlt das Ereignis unter Umst\u00e4nden ganz.<\/p>\n
Ein Ereignis ohne engagement_time_msec<\/code> tr\u00e4gt nichts zur durchschnittlichen Interaktionsdauer bei, die f\u00fcr den so eingelieferten Verkehr dann bei null steht.<\/p>\n
Beides ist nicht Pflicht, beides erzeugt nirgends eine Warnung, und beides ist die \u00fcbliche Antwort auf \u201edie Ereignisse kommen an, aber der Bericht stimmt nicht”. session_id<\/code> muss eine positive Ganzzahl sein \u2014 im Regelfall ein Zeitstempel \u2014 und darf als Zahl oder als Ziffernkette gesendet werden. Buchstaben darin werden abgelehnt.<\/p>\n
Das Ereignis und sein Name<\/h2>\n
Ein Ereignis ist ein Objekt mit genau zwei erlaubten Schl\u00fcsseln, name<\/code> und params<\/code>. Ein Zeitstempel, der als dritter Schl\u00fcssel danebengesetzt wird, macht die Nutzlast kaputt; der Zeitstempel je Ereignis geh\u00f6rt als timestamp_micros<\/code> in die params<\/code>.<\/p>\n
Namen m\u00fcssen mit einem Buchstaben beginnen und d\u00fcrfen nur Buchstaben, Ziffern und Unterstriche enthalten. Bindestriche, Punkte und Leerzeichen werden rundweg abgelehnt. Namen unterscheiden Gro\u00df- und Kleinschreibung<\/strong>, und das ist der stille Fall: Purchase<\/code> wird angenommen, wird gespeichert und ist ein anderes Ereignis als purchase<\/code> \u2014 in den E-Commerce-Berichten taucht es nie auf, weil die am kleingeschriebenen Namen h\u00e4ngen.<\/p>\n
Einunddrei\u00dfig Namen beh\u00e4lt Google f\u00fcr sich, darunter session_start<\/code>, first_visit<\/code>, user_engagement<\/code>, app_remove<\/code> und error<\/code>. Drei weitere \u2014 screen_view<\/code>, ad_impression<\/code> und in_app_purchase<\/code> \u2014 gibt es, sind aber nur auf App-Datenstr\u00f6men erlaubt. Auf einem Web-Datenstrom werden sie schlicht nicht erfasst, und niemand sagt das irgendwo.<\/p>\n
Parameter und die Grenzen, die f\u00fcr sie gelten<\/h2>\n
Alle Grenzen des Protokolls an einer Stelle:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Was<\/th>\nGrenze<\/th>\n<\/tr>\n
JSON-Rumpf<\/td>\nunter 130 kB<\/td>\n<\/tr>\n
Ereignisse je Anfrage<\/td>\n25<\/td>\n<\/tr>\n
Ereignisname<\/td>\n40 Zeichen<\/td>\n<\/tr>\n
Parameter je Ereignis<\/td>\n25<\/td>\n<\/tr>\n
Parametername<\/td>\n40 Zeichen<\/td>\n<\/tr>\n
Parameterwert<\/td>\n100 Zeichen, 500 bei einer Analytics-360-Property<\/td>\n<\/tr>\n
Nutzereigenschaften je Anfrage<\/td>\n25<\/td>\n<\/tr>\n
Name einer Nutzereigenschaft<\/td>\n24 Zeichen<\/td>\n<\/tr>\n
Wert einer Nutzereigenschaft<\/td>\n36 Zeichen<\/td>\n<\/tr>\n
user_id<\/code><\/td>\n256 Zeichen<\/td>\n<\/tr>\n
Items je Ereignis<\/td>\n200<\/td>\n<\/tr>\n
Eigene Parameter je Item<\/td>\n10<\/td>\n<\/tr>\n
R\u00fcckdatierung<\/td>\n72 Stunden<\/td>\n<\/tr>\n<\/table>\n
Parameternamen d\u00fcrfen nicht mit _<\/code>, firebase_<\/code>, ga_<\/code>, google_<\/code> oder gtag.<\/code> beginnen, und firebase_conversion<\/code> ist rundweg reserviert. F\u00fcr Namen von Nutzereigenschaften gelten dieselben Pr\u00e4fixregeln und zus\u00e4tzlich f\u00fcnf reservierte Namen, von denen user_id<\/code> derjenige ist, zu dem versehentlich gegriffen wird \u2014 die Nutzerkennung geh\u00f6rt ganz nach oben, nicht in user_properties<\/code>.<\/p>\n
Nur items<\/code> darf ein Array sein. Jeder andere Parameter nimmt einen Einzelwert; ein verschachteltes Objekt f\u00e4llt weg, und im Bericht erscheint der Parameter als fehlend statt als falsch.<\/p>\n
Wo die beiden H\u00f6chstwerte aneinandergeraten<\/h2>\n
F\u00fcnfundzwanzig Ereignisse je Anfrage und zweihundert Items je Ereignis sind beide dokumentiert, und beide zusammen gehen nicht. Gemessen an erzeugten Nutzlasten mit realistischen Item-Feldern \u2014 Kennung, Name, Marke, Kategorie, Variante, Preis, Menge:<\/p>\n