Ein Event ist eine Entscheidung, die du getroffen hast, nicht etwas, das passiert ist
Jedes Produkt erzeugt unbegrenzt viele Dinge, die passieren: Klicks, Scrollen, Hovern, Routenwechsel. Ein Event ist die kleine Teilmenge davon, die du für einen Namen würdig befunden hast, weil sie dir etwas sagt, worauf du reagieren würdest. Diese Entscheidung, nicht die Instrumentierung, ist die eigentliche Arbeit.
Die praktische Folge: Ein Tracking-Plan ist ein Produktdokument und kein technisches. Wenn du nicht sagen kannst, was du anders machen würdest, je nachdem ob ein Event ausgelöst wird, muss es noch nicht existieren.
Events nach Ergebnissen benennen, nicht nach Oberflächen
clicked_blue_button stimmt nicht mehr, sobald das Design ein Redesign ausliefert. report_exported übersteht es, weil es benennt, was der Nutzer erreicht hat, statt worauf er geklickt hat.
Wähle eine Konvention und halte dich daran: Objekt zuerst, Aktion in der Vergangenheitsform, kleingeschrieben mit Unterstrichen — invite_sent, project_created, payment_failed. Einheitlichkeit zählt mehr als die Frage, welche Konvention du gewählt hast, denn uneinheitliche Namen sind es, die einen Event-Katalog nach zwei Quartalen undurchsuchbar machen.
Eine Namenskonvention zum Übernehmen
Die meisten Teams müssen keine Konvention erfinden, nur eine aufschreiben. Diese hier ist kurz genug, um sie sich zu merken, und streng genug, um einen Katalog durchsuchbar zu halten:
| Regel | So | Nicht so |
|---|---|---|
| Objekt zuerst, dann die Aktion | invite_sent | sent_invite |
| Vergangenheitsform, weil es schon passiert ist | project_created | create_project |
| Kleinschreibung mit Unterstrichen | plan_upgraded | PlanUpgraded, plan-upgraded |
| Das Ergebnis benennen, nicht das Bedienelement | report_exported | export_button_clicked |
| Varianten gehören in Eigenschaften | report_exported mit format: csv | report_exported_csv |
| Keine personenbezogenen Daten in Namen oder Werten | plan: team | email: ana@acme.com |
Stell die Konvention an den Anfang des Tracking-Plans und prüfe neue Events daran, so wie du Code gegen einen Styleguide prüfst. Ein schlechter Name kostet jedes Mal, wenn jemand nach dem Event sucht und es nicht findet.
Zehn bis zwanzig Events, nicht zweihundert
Der häufige Fehler ist, alles zu tracken, nach der Theorie, die Daten könnten später nützlich sein. Am Ende hast du einen Katalog, in dem sich niemand zurechtfindet, drei Events, die fast dasselbe bedeuten, und keine Einigkeit darüber, welches maßgeblich ist.
Beginne mit den Fragen, die ihr in Reviews ohnehin stellt — richten sich Menschen ein, kommen sie zurück, wo geben sie auf —, und instrumentiere nur, was sie beantwortet. Ein Tracking-Plan, der auf einen Bildschirm passt, wird gepflegt. Einer, der eine Tabelle füllt, nicht.
Ein Beispiel: ein Tracking-Plan für eine B2B-SaaS-App
So sehen zwölf Events für ein typisches teambasiertes SaaS-Produkt aus. Jedes existiert, weil es eine Frage beantwortet, die jemand schon im wöchentlichen Review stellt.
| Event | Wird ausgelöst, wenn | Wichtige Eigenschaften | Die Frage, die es beantwortet |
|---|---|---|---|
signup_completed | Das Konto existiert, nicht wenn das Formular abgeschickt wird | source | Welche Kanäle bringen Menschen, die tatsächlich abschließen? |
workspace_created | Der erste Workspace wird gespeichert | team_size | Wie viele Registrierungen kommen bis zur Einrichtung? |
teammate_invited | Eine Einladung wird verschickt | role | Verbreitet sich das Konto über eine Person hinaus? |
invite_accepted | Die eingeladene Person tritt bei | role | Werden aus Einladungen Teammitglieder? |
integration_connected | Eine Verbindung gelingt | integration | Welche Integrationen nutzen Teams, die bleiben? |
project_created | Ein Projekt wird gespeichert | template | Wird das Kernobjekt überhaupt erstellt? |
report_viewed | Ein Bericht ist fertig gerendert | report_type | Was schauen sich Menschen immer wieder an? |
report_exported | Die Datei wird erzeugt | format | Verlässt das Ergebnis das Produkt? |
plan_upgraded | Die Abrechnung bestätigt die Änderung | from_plan, to_plan | Was passiert, kurz bevor Menschen mehr bezahlen? |
payment_failed | Der Zahlungsanbieter meldet einen Fehlschlag | reason | Wie viel Churn ist unfreiwillig? |
subscription_cancelled | Die Kündigung wird wirksam | reason | Warum gehen Teams? |
feedback_submitted | Das Feedback-Formular wird abgeschickt | category | Worum bitten Nutzer, in ihren eigenen Worten? |
Zwei Dinge fallen auf. Die meisten davon werden bei einem Ergebnis ausgelöst, nicht bei einem Klick: Eine Einladung kann angeklickt werden und trotzdem fehlschlagen. Und die Abrechnungs-Events passieren überhaupt nicht im Browser. Sie kommen über die Webhooks deines Zahlungsanbieters, sodass reine Browser-Analytics sie nie sehen. Das ist in Ordnung, solange niemand einen Klick auf „Upgrade“ für Umsatz hält.
Aktivierung ist meist eine Kombination daraus statt eines einzelnen Events, zum Beispiel ein erstellter Workspace und ein eingeladenes Teammitglied innerhalb der ersten Woche. Wähle diese Definition bewusst; Benchmarks für Aktivierungs-Funnels erklärt, wie.
Eigenschaften tragen die Details; Events tragen das Verb
Widersteh einem eigenen Event pro Variante. report_exported_csv, report_exported_pdf und report_exported_xlsx sollten ein Event sein, report_exported, mit einer Eigenschaft format. Die Faustregel: Wenn du die Zahlen jemals zusammengezählt sehen wollen würdest, ist es ein Event mit einer Eigenschaft.
Halte die Werte von Eigenschaften überschaubar und stabil. Eine Eigenschaft mit einer rohen URL oder einem Freitext ist eine Spalte, nach der du nicht gruppieren kannst – also Dekoration statt Daten.
Fehler beim Event-Tracking, die Berichte still und leise kaputt machen
- Beim Klick auslösen statt beim Ergebnis. Ein Klick auf „Exportieren“ ist kein Export. Schlägt die Anfrage fehl, hat das Event bereits gelogen. Sende Ergebnis-Events erst, wenn die Sache gelungen ist.
- Doppeltes Auslösen in Single-Page-Apps. Eine Komponente, die neu rendert, oder eine Route, die zweimal mountet, kann dasselbe Event zweimal senden. Prüf ein paar Sessions von Hand, bevor du einer Zahl traust.
- Personenbezogene Daten in Eigenschaften. E-Mails, Namen und URLs mit Tokens im Query-String landen in jedem Bericht und jedem Export. Sende stattdessen eine ID oder eine Kategorie.
- Tracking vor der Einwilligung. Wo die DSGVO gilt, sollten Analytics erst starten, wenn der Besucher zustimmt. Das ist eine Eigenschaft deines Setups, nicht jedes einzelnen Events, also löse es einmal, mit einem Cookie-Consent-Manager, der das Tracking bis dahin zurückhält.
- Die Bedeutung eines Events ändern, ohne es umzubenennen. Wenn
project_createdplötzlich auch duplizierte Projekte zählt, widersprechen sich alle Diagramme vor und nach der Änderung, und niemand weiß, warum. Eine neue Bedeutung bekommt einen neuen Namen oder eine Eigenschaft, die beides unterscheidet. - Events ohne Verantwortlichen. Jedes Event im Plan braucht eine Person, die merkt, wenn es nicht mehr ausgelöst wird. Events ohne Verantwortliche verfallen zuerst und genießen am längsten Vertrauen.
Autocapture und explizite Events beantworten verschiedene Fragen
Autocapture zeichnet Interaktionen mit der Oberfläche auf, ohne dass du planen musst, was gerade am Anfang wirklich nützlich ist: Die Daten für eine Frage, an die du noch nicht gedacht hast, sind dann schon da, und das Deployment fällt aus der Schleife. Was es nicht kann, ist deine Domäne kennen. Nichts in einem Klickstrom weiß, dass ein Abo upgegradet wurde.
Die praktikable Lösung ist beides: Autocapture für die Erkundung und für Fragen, die du noch nicht gestellt hast, und eine kurze Liste expliziter, gut benannter Domänen-Events für die Zahlen, über die du berichtest und für die du Ziele setzt.
Events nachträglich definieren
Autocapture verändert die Frage von „Haben wir daran gedacht, das zu instrumentieren?“ zu „Finden wir es in dem, was erfasst wurde?“. PulsePanda zeichnet jeden Klick mit id, Klassen, sichtbarem Text, Tag und Position des Elements auf der Seite auf, sodass sich ein Event später daraus definieren lässt, und die Definition gilt auch für Klicks, die erfasst wurden, bevor es sie gab. Eine Frage, die am Donnerstag gestellt wird, lässt sich mit den Daten vom Montag beantworten.
Zuverlässig wird das durch einen stabilen Anker im Markup. Klassen ändern sich mit jedem Redesign, und sichtbarer Text ändert sich mit jeder Textänderung und Übersetzung. Eine id an der Handvoll Bedienelemente, die zählen, ändert sich nur, wenn jemand das entscheidet:
<button id="export-report">Export</button>
<button id="invite-teammate">Invite</button>
<a id="upgrade-plan" href="/de/billing">Upgrade</a>Ein Event, das als Klicks auf #export-report definiert ist, übersteht ein Redesign, und ein Klick auf das Icon oder die Beschriftung im Button zählt trotzdem, weil der erfasste Pfad bis zum nächsten Element mit einer id hinaufreicht.
Ein definiertes Event ist trotzdem ein Klick, mit der oben beschriebenen Grenze: Es sagt dir, dass jemand es versucht hat, nicht, dass es funktioniert hat. Für Ergebnisse ist das ehrlichere Signal oft die Seite, zu der ein Erfolg führt. Ein Funnel-Schritt „/onboarding erreicht“ nach „/signup erreicht“ zählt abgeschlossene Registrierungen ganz ohne Event.
So prüfst du ein Event, bevor du ihm traust
- Löse es selbst aus und finde deine eigene Session. Das Event sollte einmal erscheinen, mit allen Eigenschaften ausgefüllt.
- Vergleiche die Zahl mit einer verlässlichen Quelle. Wenn die Datenbank sagt, dass letzte Woche 140 Projekte erstellt wurden, und die Analytics 95 sagen, finde die Lücke, bevor jemand ein Diagramm darauf baut. Werbeblocker, Einwilligungen und fehlgeschlagene Anfragen machen Browser-Zahlen niedriger als Server-Zahlen. Die Lücke sollte stabil sein, keine Überraschung.
- Sieh dir ein Session Replay an, in dem es ausgelöst wurde. Eine Zahl sagt dir, dass es passiert ist; eine Aufzeichnung sagt dir, dass es dann passiert ist, wann du glaubst.
- Setz es in einen Funnel. Ein Event, das ohne den Schritt auftaucht, der davor kommen muss, wird an der falschen Stelle ausgelöst.
Wo du diese Woche anfangen solltest
Schreib die fünf Momente auf, die in deinem Produkt am meisten zählen, benenne sie mit der Konvention oben und instrumentiere nur diese. Prüf dann eine Woche später, ob jedes dann ausgelöst wird, wann du es erwartest, und ob seine Eigenschaften gefüllt sind — ein Event, das auf einem Code-Pfad ausgelöst wird, den niemand nutzt, ist schlimmer als gar keines, denn man wird ihm vertrauen.
Wenn du sehen willst, wie sich die Events verhalten, die du schon sendest, bevor du weitere hinzufügst, zeigt dir das Event-Tracking in PulsePanda jedes Event, sein Volumen und seine Eigenschaften an einem Ort und speist dieselben Daten direkt in Funnels und Pfade.