Wie Event Tracking festhält, was Nutzer wirklich getan haben

Was ist Event Tracking in der Produktanalyse?

Produktanalyse-Tools nutzen Event Tracking, um benannte Nutzeraktionen wie signup_completed oder checkout_started samt Eigenschaften zu erfassen, die jede Aktion beschreiben, und machen so aus seitenbezogenen Traffic-Daten ein Protokoll dessen, was Menschen tatsächlich getan haben. Ein Pageview sagt, dass jemand den Checkout-Bildschirm erreicht hat. Ein Event sagt, dass die Person den Checkout gestartet hat, im Jahrestarif für Teams, von der Preisseite aus, und nie zurückgekommen ist. Flowsery liefert Ziel- und Event-Tracking neben seiner eingebauten Webanalyse, dasselbe Konto hält also die Traffic-Zahlen und das Protokoll auf Aktionsebene.

Was sind die zwei Teile eines Events?

Ein Event hat einen Namen und eine Menge von Eigenschaften, und die Aufteilung dazwischen entscheidet, ob die Daten ein Jahr später noch abfragbar sind. Der Name benennt die Aktion und bleibt über jedes Vorkommen konstant. Die Eigenschaften tragen die Teile, die sich von Vorkommen zu Vorkommen ändern: welcher Tarif, welche Quelle, wie viel, wie lange. Setz die Aktion in den Namen und die Variablen in die Eigenschaften, dann wird jede Frage zu dieser Aktion zu einem Filter statt zu einem neuen Event.

Fünf Events mit guten Eigenschaften beantworten mehr Fragen als fünfzig Events ohne. Diese fünf tragen einen Registrierungs-Funnel, einen Checkout-Vergleich pro Tarif, einen Gutschein-Bericht und eine Kennzahl zur Team-Ausweitung, ohne einen einzigen zusätzlichen Tracking-Aufruf. Die Namen der Eigenschaften in dieser Tabelle folgen dem Muster object_adjective, das PostHog in seinen Best Practices für Produktanalyse dokumentiert, wobei is_ für Booleans reserviert ist.

Wie sieht ein schlecht benanntes Event neben einem guten aus?

Ein schlecht benanntes Event schiebt das Veränderliche in den Namen, was eine Aktion für jede Kombination in ein neues Event aufspaltet. Hier ist dieselbe Registrierung, zweimal getrackt.

// Schlecht getrackt: Tarif und Seite stecken im Namen
track("Clicked Signup Button On Pricing Page Annual");
track("clicked_signup_button_on_pricing_page_monthly");
track("Signup Btn - Homepage");
 
// Gut getrackt: ein stabiler Name, die Variablen als Eigenschaften
track("signup_completed", {
  signup_source: "pricing_page",
  plan_slug: "team_annual",
  is_invited: false
});

Der erste Block erzeugt drei Event-Namen für eine Aktion, die Antwort auf "wie viele Menschen haben sich letzte Woche registriert" ist also eine Handrechnung, die in dem Moment kaputtgeht, in dem jemand eine vierte Preisseite anlegt. Der zweite Block erzeugt einen Event-Namen und drei Filter. Bitte eine Person aus dem Marketing, die Aktion laut zu benennen, und prüfe dann, ob alles, was sie nach dem Verb gesagt hat, in einer Eigenschaft gelandet ist und nicht im Namen.

Welche Namenskonvention für Events sollte ein Team wählen?

Die Konvention, die funktioniert, ist die, die aufgeschrieben und auf jedes Event angewendet wird, und die beiden veröffentlichten Konventionen sind sich in den Details uneins. PostHogs Best Practices für Produktanalyse verlangen kleingeschriebenes snake_case, Verben im Präsens und eine Struktur category:object_action wie account_settings:forgot_password_button_click. Amplitudes Playbook zur Datenplanung verlangt Title Case mit der Struktur [Noun] + [Past-Tense Verb] wie Song Played, konsequent aus der Sicht des Nutzers, sodass Message Sent bedeutet, dass der Nutzer sie gesendet hat.

Beide funktionieren. Sie zu mischen funktioniert nicht, denn Signup Completed, signup_completed und signup:button_click werden zu drei unverbundenen Zeilen in derselben Liste. Die Beispiele in diesem Beitrag nutzen snake_case mit Verben in der Vergangenheit, was sich als Objekt und dann Aktion liest und alle verwandten Events alphabetisch zusammen sortiert: checkout_completed landet neben checkout_started.

Unter jeder gewählten Konvention liegt eine harte Grenze. Googles Limits für die GA4-Event-Erfassung deckeln einen Event-Namen bei 40 Zeichen, erlauben 25 Event-Parameter pro Event, deckeln einen Parameternamen bei 40 Zeichen und die meisten Parameterwerte bei 100 Zeichen und setzen für Web-Datenströme kein Limit für unterschiedlich benannte Events, während App-Datenströme bei 500 pro App-Nutzer gedeckelt sind. Ein Name nach category:object_action plus ein langes Substantiv läuft schneller in diese Grenze von 40 Zeichen, als Teams erwarten, und GA4 hört stillschweigend auf, einen zu langen Namen als Schlüsselereignis zu berichten.

Wie unterscheidet sich Event Tracking von Autocapture?

Event Tracking benennt die Aktion im Anwendungscode, bevor er ausgeliefert wird, während Autocapture jeden Klick und jedes Absenden eines Formulars automatisch aufzeichnet und die Bedeutung erst danach aus der Seitenstruktur definieren lässt. Autocapture verschafft einem Team an Tag eins einen laufenden Datenstrom und geht stillschweigend kaputt, wenn ein Redesign den CSS-Selektor ändert, auf den es gematcht hat. Ein benanntes Event bewegt sich mit dem Code, in dem es lebt, eine Komponentenumbenennung trägt den Tracking-Aufruf also mit sich. Die meisten Teams fahren beides: Autocapture für den explorativen Long Tail, benannte Events für die Zahlen, die in einer Board-Präsentation auftauchen.

Wie machen Eigenschaften aus Events einen Funnel?

Zwei Events mit einer gemeinsamen Eigenschaft werden zu einem Conversion-Schritt, und so wird ein Conversion-Funnel aus rohen Event-Daten gebaut. Die Abschlussrate eines Schritts ist eine Division:

step conversion rate = completed events / started events x 100

Bei 4,000 Events checkout_started und 1,240 Events checkout_completed in einer Woche konvertiert der Checkout-Schritt mit 31 Prozent. Nimm plan_slug als Aufschlüsselung dazu, und diese eine Zahl zerfällt in eine Rate pro Tarif, und genau dort zeigt sich das eigentliche Problem. Eigenschaften sind auch das, woraus benutzerdefinierte Dimensionen gebaut werden, das Schema, das du für Events entwirfst, ist also dasselbe Schema, nach dem deine Berichte später segmentieren.

Wie viele Events sollte ein Team instrumentieren?

Instrumentiere die Aktionen, die in einer Entscheidung auftauchen, und hör dann auf. Ein Event, nach dem seit drei Monaten niemand gefiltert hat, ist Schema-Schulden: Es kostet Kontingent, es verstopft die Event-Auswahl und es verfällt, ohne dass es jemand merkt. Fang mit den Schritten auf dem Weg zum Umsatz an, ergänze die Aktionen, die ein gehaltenes Konto von einem abgewanderten trennen, und füge neue Events hinzu, wenn hinter einer konkreten Frage keine Daten stehen.

Ein kleineres Schema hält auch die Datenschutzfläche klein. Flowsery ist von Grund auf cookiefrei und in der EU gehostet, und die Eigenschaften, die ein Team nicht sendet, sind genau die, die nie eine Aufbewahrungsrichtlinie brauchen. Teams, die diesen Kompromiss gegen ein Google-First-Setup abwägen, können den Vergleich von datenschutzfreundlicher Analyse und GA4 lesen.

Wie prüfst du, ob ein Event korrekt auslöst?

Löse die Aktion selbst aus und bestätige dann, dass das Event mit dem richtigen Namen und den richtigen Eigenschaften angekommen ist, bevor du irgendeinem Chart darauf traust. Der teuerste Fehlschlag ist ein Event, das mit einer leeren oder falsch geschriebenen Eigenschaft auslöst, denn die Zählung sieht gesund aus, während jede Aufschlüsselung still Zeilen verliert. Eine echte Session neben dem Event-Stream anzuschauen fängt diese Abweichung so ab, wie ein Dashboard es nicht kann: Flowsery zeichnet jede Nutzersession auf und verbindet sich ohne neue Instrumentierung mit bereits aufgezeichneten Replays aus PostHog oder Amplitude, sodass Replay und Event-Log nebeneinander liegen.

Wiederhole diese Prüfung nach jedem Frontend-Release, das einen getrackten Flow berührt. Ein Event, das nicht mehr auslöst, erzeugt eine flache Linie, und eine flache Linie liest sich wie ein Produktproblem, bis jemand den Code öffnet.

Häufig gestellte Fragen

Was ist ein Event in der Analyse?

Ein Event ist eine einzelne benannte Aktion, die ein Nutzer ausgeführt hat, aufgezeichnet mit einem Zeitstempel und einer Menge beschreibender Eigenschaften. checkout_started mit plan_slug: team_annual ist ein Event. Ein Pageview ist eine bestimmte Art von Event, die die meisten Analyse-Skripte automatisch aufzeichnen.

Was ist der Unterschied zwischen einem Event-Namen und einer Event-Eigenschaft?

Der Name benennt die Aktion und bleibt über jedes Vorkommen identisch, damit er gezählt werden kann. Die Eigenschaft trägt das Detail, das sich zwischen Vorkommen ändert, damit danach gefiltert und gruppiert werden kann. Alles, wonach du filtern möchtest, gehört in eine Eigenschaft und nie in den Namen.

Sollten Event-Namen die Vergangenheit oder das Präsens nutzen?

Beide Konventionen sind veröffentlicht und beide funktionieren, wähle also eine und setze sie durch. Amplitudes Playbook zur Datenplanung dokumentiert Title Case mit Verben in der Vergangenheit, und PostHogs Best Practices dokumentieren kleingeschriebenes snake_case mit Verben im Präsens. Der Preis für einen Wechsel auf halbem Weg sind zwei Namenssätze für dieselben Aktionen.

Wie viele Eigenschaften sollte ein einzelnes Event tragen?

Sende die Eigenschaften, nach denen du filtern oder gruppieren würdest, und lass den Rest weg. GA4 erlaubt laut Googles Limits für die Event-Erfassung 25 Event-Parameter pro Event, was eine Obergrenze ist und kein Ziel. Fünf bis acht gut gewählte Eigenschaften auf einem zentralen Event decken die meisten Berichtsfragen ab.

Braucht Event Tracking Cookies?

Nein. Festzuhalten, dass eine Aktion stattgefunden hat, braucht kein Cookie, denn ein Cookie existiert, um Identität zwischen Besuchen zu halten, nicht um die Aktion selbst zu erfassen. Flowsery läuft cookiefrei und EU-gehostet und zeichnet Events trotzdem mit ihren Eigenschaften auf.

Was zerstört ein Event-Schema mit der Zeit?

Umbenannte Events, ad hoc ergänzte Events ohne Konvention und Eigenschaften, die nach einem Refactor nicht mehr befüllt werden. Jedes davon lässt den Chart in Ordnung aussehen, während die Daten darunter abdriften. Eine aufgeschriebene Namenskonvention plus eine Prüfung getrackter Flows nach jedem Release verhindert das meiste davon.

Was ist Schema-Debt beim Event Tracking?

Schema-Debt ist ein Event, auf das seit drei Monaten niemand gefiltert hat. Es kostet Quota, überfüllt den Event-Picker und verfällt, ohne dass es jemand bemerkt, bis irgendwann jemand das Schema prüft.

Kann Autocapture named Events ersetzen?

Die meisten Teams nutzen beides, statt sich für eines zu entscheiden. Autocapture fängt den explorativen Long Tail ein und liefert am ersten Tag einen funktionierenden Datenstrom, bricht aber lautlos, wenn ein Redesign den CSS-Selector ändert, auf den es gematcht hat. Named Events decken die Zahlen ab, die in einem Board-Deck auftauchen, weil ein Component-Rename den Tracking-Call mit dem Code mitzieht, in dem er lebt.

Wie hoch ist das GA4-Zeichenlimit für einen Event-Namen?

Google begrenzt einen Event-Namen in GA4 auf 40 Zeichen und begrenzt auch einen Parameternamen auf 40 Zeichen, die meisten Parameterwerte sind bei 100 Zeichen gedeckelt. Eine category:object_action-Struktur plus ein langes Nomen stößt schneller an diese Grenze, als Teams erwarten, und GA4 hört bei einem zu langen Namen lautlos auf, ihn als Key Event zu melden.

Wie berechnest du eine Funnel-Conversion-Rate aus Events?

Teile die abgeschlossenen Events durch die gestarteten Events und multipliziere mit 100. Bei 4.000 checkout_started-Events und 1.240 checkout_completed-Events in einer Woche konvertiert der Checkout-Schritt mit 31 Prozent. Eine Aufschlüsselung nach einer Property wie plan_slug macht aus einer Rate eine Rate pro Plan.