Einleitung
Viele Teams investieren viel Zeit in Tracking, Events und Parameter. Und trotzdem passiert es ständig, dass Reports leer sind, Segmente keinen Sinn ergeben oder Kennzahlen plötzlich widersprüchlich wirken. In sehr vielen Fällen liegt es nicht am Tracking selbst, sondern an einem Detail, das in GA4 schnell unterschätzt wird. Custom Definitions und vor allem der richtige Scope.
Warum Custom Definitions überhaupt so wichtig sind
GA4 sammelt zwar sehr viele Daten, aber benutzerdefinierte Parameter sind nicht automatisch in den Standard Reports sichtbar. Erst wenn du eine Custom Definition anlegst, kannst du diese Parameter sauber in Berichten, Explorationen und Segmenten nutzen. Wer das nicht macht, hat zwar Daten in den Rohdaten, aber nicht im Reporting Alltag.
Das Problem?!? Der Scope wird falsch gewählt!
Der Scope entscheidet, auf welcher Ebene GA4 deinen Parameter speichert und auswertet. Und genau hier entstehen die typischen Fehler.
Event Scope:
Event Scope ist in der Webanalyse für Informationen gedacht, die zu einer einzelnen Aktion gehören. Also zu einem konkreten Event wie Klick, Checkout Schritt, Formular Absenden oder Fehleranzeige. Diese Werte können sich bei jeder Aktion ändern.
User Scope:
Der User Scope ist in der Webanalyse für Informationen gedacht, die den Nutzer beschreiben. Diese Werte sind eher stabil und sollen für Segmentierung über mehrere Sessions hinweg genutzt werden.
Wenn der Scope nicht passt, entstehen zwei typische Symptome:
- Du willst segmentieren, aber es funktioniert nicht sauber, weil der Wert nur eventweise existiert.
- Du willst einen Prozess analysieren, aber die Werte wirken zufällig, weil sie auf Nutzer Ebene zusammengezogen werden.
Eine einfache Regel:
Wenn du es in einem Funnel Schritt oder bei einer Aktion analysierst, nutze Event Parameter.
Wenn du es als Segment nutzen willst, nutze User Property.
Praxisbeispiele für den Checkout
Payment Type im Checkout: Der payment_type ist ein klassischer Event Parameter. Denn er gehört zu einer konkreten Auswahl in einem Checkout Moment. Ein Nutzer kann heute PayPal wählen und morgen Kreditkarte. Das ist keine dauerhafte Nutzer Eigenschaft.
Login Status
Der login_state ist typischerweise eine User Property und kommt in unsere Welt der Digital Analytics superhäufig vor. Denn sie beschreibt, ob ein Nutzer gerade eingeloggt ist oder nicht. Das ist hilfreich für Segmentierung, zum Beispiel um Funnels für eingeloggte gegen nicht eingeloggte Nutzer zu vergleichen. (Tipp: Vergleich der Conversion Rate oder CTR).
CTA Name
cta_name gehört klar zum Event Scope. Es beschreibt den konkreten Klick, zum Beispiel kostenloser SEO Check oder Demo oder „bei IT-WINGS Kunde werden“ anfragen.
Checkout Step
Der checkout_step gehört ebenfalls zum Event Scope, weil du genau den Prozess und die Abfolge der Aktionen auswerten willst.
So sieht das im Data Layer aus:
Ein sauberer Data Layer hilft dir, diese Logik eindeutig zu trennen. Hier ein simples Beispiel mit zwei Blöcken.
Einer für ein Event im Checkout und einer für den Nutzer Kontext.
<script>
window.dataLayer = window.dataLayer || [];
/* Event Scope Beispiel */
dataLayer.push({
event: "payment_method_select",
payment_type: "paypal",
checkout_step: 3,
currency: "EUR"
});
/* User Scope Kontext Beispiel */
dataLayer.push({
event: "user_context",
login_state: "logged_in",
customer_type: "b2b",
user_language: "de"
});
</script>
Wichtig ist nicht, dass du einen user_context Event exakt so verwendest.
Wichtig ist, dass du konzeptionell klar trennst.
Event Details kommen mit dem jeweiligen Event. Nutzer Eigenschaften werden als User Properties geführt oder mindestens konsistent mitgegeben, wenn es technisch nicht anders geht.
Die drei Checks, wenn Reports leer sind:
Viele denken sofort an einen Implementierungsfehler. In der Praxis sind diese drei Checks schneller.
- Custom Definition wurde angelegt und Name stimmt exakt
Ein Tippfehler in der Schreibweise reicht, damit du im Report nichts siehst. - Richtiger Scope gewählt
Wenn du dir nicht sicher bist, frag dich, ob sich der Wert pro Aktion ändert oder den Nutzer beschreibt. - Nicht rückwirkend
Custom Definitions wirken nicht rückwirkend. Daten vor dem Anlage Zeitpunkt erscheinen nicht in diesen Auswertungen. Das ist einer der häufigsten Gründe für leere Reports.
Custom Definitions sind ein Produkt, keine spontane Idee:
Wenn du zu viele Parameter anlegst, wird es schnell unübersichtlich. Ich empfehle einen klaren Prozess.
- Lege nur Definitions an, die Entscheidungen verändern.
- Dokumentiere jede Definition mit Zweck, Owner, Event Name, Parameter Name, Scope, Beispielwerten.
- Alles andere analysierst du über Rohdaten Export, zum Beispiel in BigQuery oder Databricks, wo du keine Reporting Limitierungen hast.
Ein kurzer Leitfaden für die Entscheidung
Nimm Event Scope, wenn du Prozess Schritte, Klicks, Fehler, Formulare, Checkout Auswahl analysieren willst.
Nimm User Scope, wenn du Nutzer Eigenschaften, Kundentypen, Login Zustand, Sprache oder Vertragsstatus segmentieren willst.
Fazit
Du kannst perfektes Tracking haben und trotzdem wertlose Reports, wenn Custom Definitions falsch angelegt sind. Der Scope ist dabei der Hebel, der am meisten unterschätzt wird. Wer ihn sauber konzeptioniert, spart sich Debugging Schleifen, Diskussionen über Datenqualität und kann viel schneller Entscheidungen treffen.