Blog · GA4
GA4 als Transportschicht: wenn ein Request alles tragen muss
Viele Setups nutzen das GA4-Tag im Browser als Lieferwagen zum Server-Container. Meta, Google Ads, TikTok und Pinterest holen sich dort ihre Daten ab. Das ist praktisch, bis GA4 selbst an seine Grenzen stößt.
Das Muster
Im Browser läuft ein GA4-Tag. Es sendet an den eigenen Server-Container statt an Google. Dort liest der GA4-Client den Request, und alle Server-Tags arbeiten mit denselben Event-Daten. Also packt man alles in den GA4-Request, was irgendeine Plattform braucht: Kundendaten für Meta, Event-IDs für die Deduplizierung, Klick-IDs für Ads.
Das Problem: Am Ende landet der gleiche Request auch in GA4. Und GA4 hat feste Grenzen.
| Grenze (Standard-Property) | Wert |
|---|---|
| Parameter pro Event | 25 |
| Länge Parametername | 40 Zeichen |
| Länge Parameterwert | 100 Zeichen (page_location 1.000) |
| Nutzereigenschaften | 25 pro Property, Wert max. 36 Zeichen |
| Benutzerdefinierte Dimensionen (Event) | 50 pro Property |
Was über die Grenzen geht, verwirft GA4 stillschweigend. Der Server-Container merkt davon nichts.
Config-Parameter zählen bei jedem Event
Parameter in den Einstellungen des Google-Tags hängen an jedem Event. Zehn Parameter dort bedeuten: Jedes Event startet mit zehn belegten Plätzen, bevor die eigentlichen Event-Daten dazukommen.
Dazu kommt ein Timing-Problem. Werte wie user_id oder Adressdaten sind beim Laden des Tags oft noch leer. In der Config gesetzt, landen sie leer im Request. Sie gehören auf Event-Ebene, wo sie zum richtigen Zeitpunkt gelesen werden.
Zwei Hebel
- Im Browser aufräumen. Doppelte, leere und konstante Parameter entfernen. Was nur ein Server-Tag braucht, nur an die Events hängen, bei denen dieses Tag feuert.
- Im Server-Container filtern. Das GA4-Tag im sGTM kann Parameter vom Versand ausschließen. Die Trigger und alle anderen Tags sehen weiter die vollständigen Event-Daten. So bekommt Meta seine Kundendaten, und GA4 bleibt schlank.
Was eine Bestandsaufnahme zeigt
In einem Projekt haben wir jeden Parameter des GA4-Requests einzeln bewertet. Die Muster, die dabei auffielen:
| Befund | Beispiel | Maßnahme |
|---|---|---|
| Doppelt | Dieselbe Kunden-ID unter zwei Namen | Einen Namen behalten |
| Leer | Adressfelder, die in GA4 zu 0 % befüllt waren | Nur auf Event-Ebene oder für GA4 ausschließen |
| Konstant | Container-ID, die bei jedem Event gleich ist | Entfernen |
| Wertlos | Eine Zufalls-ID pro Event, trotzdem als Dimension registriert | Entfernen, Dimension archivieren |
| Verwaist | Cookie-Werte, die nur ein Tag gelesen hätte, das niemand nutzt | Entfernen |
| Kritisch | Eine Klick-ID, die das Tracking für leer hielt, die das Data Warehouse aber für die SEA-Zuordnung nutzte | Behalten |
Die letzte Zeile ist der wichtigste Punkt: Aus Tracking-Sicht wirkte der Parameter überflüssig. Im BigQuery-Export war er bei einem relevanten Teil der Events befüllt und Grundlage für die Kanalzuordnung. Deshalb entscheide ich nie allein, was weg kann. Jede Zeile bekommt eine Antwort vom Data-Team: „Wird das in BigQuery oder einem Report genutzt?“ Wie ich das festhalte, steht im Beitrag zu Dokumentation und Data Contracts.
Auch Event-Mengen haben Grenzen
Parameter sind eine Seite, die Anzahl der Events die andere. In einem Headless-Shop feuerte view_item_list für alle Produkte einer Liste, sobald die Liste im Viewport erschien, statt erst bei Sichtbarkeit des einzelnen Produkts. Es war mit Abstand das häufigste Event. Das bläht den BigQuery-Export auf, und für Standard-Properties ist der tägliche Export begrenzt.
Quelle: Google: GA4-Erfassungslimits