Event-Tracking
Event-Tracking ist die Praxis, konkrete Nutzerinteraktionen wie Button-Klicks, Formularübermittlungen oder Quiz-Abschlüsse als einzelne Datenpunkte, sogenannte Events, zu erfassen. Jedes Event kann Parameter tragen, die Kontext wie Wert, Kategorie oder Score hinzufügen.
Das Wichtigste in Kürze
- Ein Event ist eine unveränderliche Tatsache mit Name, Zeitstempel, Akteur, Eigenschaften und Kontext.
- Auslösen beim Klick misst Absicht, Auslösen nach Serverbestätigung misst das tatsächliche Ergebnis.
- Typisierte Eigenschaften mit niedriger Kardinalität bleiben abfragbar, Freitext und Rohzahlen nicht.
- Ein Tracking-Plan mit Namen, Eigenschaften, Typen und Verantwortlichen verhindert Wildwuchs zwischen Teams.
- Events lassen sich nicht nachträglich befüllen, ungemessenes Verhalten bleibt dauerhaft unauswertbar.
Im Detail
Ein Event-Datensatz ist eine Tatsache mit fester Form: ein Name, ein Zeitstempel, eine Kennung der handelnden Person, Eigenschaften zu genau diesem Vorgang sowie Kontext wie Seite, Gerät und Kampagne. Er entsteht an einer bestimmten Codezeile, wandert zum Collector und wird nur angehängt, nie überschrieben. Genau diese Unveränderlichkeit ist der Kern. Ein Statusfeld wie lead_status lässt sich überschreiben und verliert dabei seine Historie, während eine Folge von status_changed-Events Reihenfolge und Zeitpunkte aller Veränderungen bewahrt. Auswertungen bauen deshalb immer auf dem Strom, nie auf dem Zustand.
Die Genauigkeit hängt vor allem davon ab, wo Sie den Auslösepunkt setzen. Beim Klick zu feuern misst Absicht, nach der Serverbestätigung zu feuern misst das Ergebnis, und die Differenz besteht aus jeder fehlgeschlagenen Übermittlung, die als Conversion gezählt wurde. Den Rest entscheidet der Eigenschaftsentwurf: wenige typisierte Felder mit niedriger Kardinalität bleiben jahrelang auswertbar, Freitext und unbegrenzte Zahlen werden unabfragbar. Jedes zusätzliche Event kostet zudem Nutzlast, Speicher und die Aufmerksamkeit derjenigen, die es später erklären müssen.
Das praktische Artefakt ist ein Tracking-Plan: eine Tabelle mit jedem Event, dem Auslösezeitpunkt, den Eigenschaften, deren Datentypen und erlaubten Werten sowie der verantwortlichen Person. Erfassen Sie Funnel-Meilensteine statt jeder Interaktion. In einem Quiz-Funnel sind das ein Start, ein Schritt-Event mit Fragenindex und der Angabe, ob beantwortet oder übersprungen wurde, sowie ein Abschluss mit der Score-Stufe. Drei sauber spezifizierte Events beantworten mehr Fragen als dreißig improvisierte. Genau diese Disziplin hält der Plan über Jahre aufrecht, auch wenn Teams und Werkzeuge wechseln.
Events beschreiben Verhalten, nicht Motivation. Ein Abbruch bei Frage vier zeigt, wo Menschen aussteigen, aber nie warum; die Daten liefern also eine Hypothese, die nur Nutzerforschung oder ein Test klären kann. Instrumentierung wirkt zudem nicht rückwirkend: Ein Event, das im letzten Quartal nicht definiert war, lässt sich in diesem nicht nachholen. Und weil Erfassung von Skripten und Einwilligung abhängt, sind absolute Zahlen stets eine Untergrenze, weshalb Verhältnisse zwischen Schritten belastbarer sind als Summen. Vergleichen Sie deshalb Quoten und nicht absolute Werte.
Beispiel aus der Praxis
So wird es gemessen
Prüfen Sie die Instrumentierung, bevor Sie irgendetwas auswerten. Gehen Sie den Ablauf je Event einmal durch und bestätigen Sie ein einmaliges Auslösen mit gefüllten Eigenschaften, und vergleichen Sie danach einen Tag erfasster Events mit den entsprechenden Zeilen in Ihrer Anwendungsdatenbank. Liegt das Volumen darüber, feuert etwas doppelt; liegt es darunter, gehen Events durch Blocker, fehlende Einwilligung oder einen Trigger verloren, der bestimmte Wege übersieht.
Lesen Sie vertrauenswürdige Events anschließend als Verhältnisse. Die Abschlussquote von Schritt zu Schritt isoliert die Schwachstelle weit besser als eine Gesamt-Conversion-Rate, und der zeitliche Abstand zweier Events zeigt Zögern, das reine Zählungen verbergen. Verfolgen Sie außerdem den Anteil der Events mit fehlenden oder leeren Eigenschaften als Gesundheitskennzahl, denn ein Anstieg dort kündigt kaputte Berichte Wochen im Voraus an und lässt sich leicht überwachen.
Häufige Fehler
Den Button statt das Ergebnis zu instrumentieren ist der Fehler, der jeden Bericht still aufbläht. Das Klick-Event feuert, danach läuft die Anfrage in einen Timeout oder die Validierung weist das Formular ab, und die Conversion-Zahl enthält Menschen, die nie durchkamen. Verlagern Sie das Auslösen in den Erfolgsfall, und brauchen Sie beides, vergeben Sie getrennte Namen wie versucht und abgeschlossen, damit die Differenz selbst zu einer auswertbaren Kennzahl wird.
Der zweite Fehler ist, Bedeutung in Namen zu pressen. Teams erzeugen quiz_complete_marketing, quiz_complete_sales und quiz_complete_v2 statt eines Events mit einer Segment-Eigenschaft, und jeder Bericht braucht danach eine gepflegte Liste aller Varianten. Halten Sie Namen stabil und legen Sie Unterschiede in Eigenschaften. Ebenso verbreitet ist es, alles auf einmal zu instrumentieren: Dutzende Events gehen live, niemand ist verantwortlich, und nach einem Jahr weiß keiner mehr, welche noch stimmen.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Event und Parameter?
Ein Event ist die benannte Aktion, etwa quiz_complete, während ein Parameter zusätzlicher Kontext dazu ist, wie ein Score- oder Kategoriewert. Parameter ermöglichen eine genauere Segmentierung und Analyse.
Was ist ein Data Layer beim Event-Tracking?
Ein Data Layer ist ein strukturiertes Objekt auf der Seite, das Nutzeraktionen und Kontext offenlegt, damit Tools wie Google Tag Manager sie lesen und die Events an Analytics- und Werbeplattformen weiterleiten können.
Wie sollte ein Event benannt werden?
Verwenden Sie ein einheitliches Muster aus Objekt und Aktion in der Vergangenheitsform, etwa quiz_started oder lead_submitted, in durchgängig gleicher Schreibweise. Entscheidend ist Vorhersagbarkeit: Jede Person sollte den Namen erraten können, bevor sie nachschlägt. Kodieren Sie keine Zielgruppen, Kampagnen oder Versionen in den Namen, denn diese gehören in Eigenschaften, wo sich danach filtern lässt.
Wie viele Events sollte ich erfassen?
Weniger, als das Bauchgefühl nahelegt. Beginnen Sie mit den Meilensteinen der Funnel-Stufen, für eine Marketing-Website meist fünf bis fünfzehn, und ergänzen Sie ein Event erst, wenn Sie die Entscheidung benennen können, die es stützt. Die Grenze ist nicht das Volumen, sondern die Pflege, denn jedes Event braucht jemanden, der weiß, ob es noch korrekt feuert.
Sollen Events aus dem Browser oder vom Server kommen?
Senden Sie vom Server, sobald ein Event ein bestätigtes Ergebnis darstellt, denn nur dort ist bekannt, ob der Datensatz wirklich geschrieben wurde. Senden Sie aus dem Browser für Interaktionsdetails wie Schritte, Zögern oder Abbruch, die der Server nie sieht. Viele Teams nutzen beides und verbinden es über eine gemeinsame Kennung, wobei der Server für Conversions führend bleibt.
Was ist ein Tracking-Plan?
Ein Tracking-Plan ist das gemeinsame Dokument, das jedes Event definiert: den Auslösemoment, die Eigenschaften, deren Datentypen und erlaubten Werte sowie die verantwortliche Person. Er sorgt dafür, dass Umsetzung, Analyse und Reporting dieselbe Bedeutung verwenden, ohne Code zu lesen. Ihn vor jedem Release durchzugehen verhindert, dass zwei Teams unterschiedliche Namen für dieselbe Nutzeraktion ausliefern.
Darf ich ein Event nach dem Start ändern?
Sie dürfen, doch die Historie ändert sich nicht mit. Ein Umbenennen zerteilt Ihre Daten, und die Bedeutung eines Events ohne Umbenennung zu verschieben ist schlimmer, weil Diagramme durchlaufen, während die Definition wechselt. Ändert sich die Semantik, führen Sie einen neuen Namen ein, betreiben Sie beide kurz parallel und dokumentieren Sie das Umstellungsdatum für spätere Auswertungen.
Warum unterscheiden sich meine Event-Zahlen je Werkzeug?
Weil jedes Werkzeug andere Sitzungslogik, Deduplizierung, Attribution und Filterung anwendet und jeweils einen anderen Anteil an Blocker und Einwilligung verliert. Ein Werkzeug, das Events von Ihrem Server empfängt, meldet in der Regel mehr als eines, das auf Browserskripte angewiesen ist. Bestimmen Sie je Fragestellung ein Referenzsystem und vergleichen Sie Verläufe statt identischer Summen.