Was ein Tracking-Plan ist
Ein Tracking-Plan ist ein einziges Dokument, das jedes Event auflistet, das Ihr Produkt erfasst, dazu die Eigenschaften jedes Events, den genauen Moment, in dem es ausgelöst wird, und die Person, die dafür verantwortlich ist. Er ist der Vertrag zwischen dem Code, der Daten sendet, und den Dashboards, die sie lesen. Behandeln Sie ihn als lebende Spezifikation, die sich mit dem Produkt ändert, nicht als Dokument, das Sie einmal schreiben und vergessen. Die Kurzfassung in einem Satz finden Sie unter Tracking-Plan; dieser Leitfaden zeigt, wie Sie einen erstellen.
Warum ein Plan besser ist als Ad-hoc-Tracking
Ohne Plan wuchert das Tracking. Ein Entwickler sendet signup, ein zweiter Sign Up, ein dritter user_registered – drei Namen für eine Aktion, und jeder Funnel, der die Anmeldung berührt, zerfällt oder bricht unbemerkt. Das ist Wildwuchs, und er ist der Hauptgrund, warum Analysen kein Vertrauen mehr genießen. Ein Plan legt das Vokabular fest, bevor der Code live geht, sodass die Zahlen, die Sie in sechs Monaten abrufen, immer noch bedeuten, was Sie denken. Saubere, einheitliche Events sind auch die Grundlage einer Experiment-Roadmap – Sie können einen Test nicht an einer Kennzahl messen, die Sie auf drei verschiedene Arten erfassen.
Events nach object_action benennen und dabei bleiben
Die Konvention, die die meisten Analyse-Tools empfehlen, ist object_action: erst das Objekt, dann was damit passiert ist – subscription_started, invite_sent, checkout_completed. Segment, Amplitude und PostHog beschreiben jeweils eine Variante (Segment nutzt „Object Action“, PostHog snake_case in Kleinbuchstaben, Amplitude ein Substantiv plus ein Verb in der Vergangenheitsform). Die genaue Schreibweise zählt weit weniger, als eine zu wählen und sie nie zu brechen. Zwei Regeln bringen den größten Nutzen: Halten Sie die Zeitform der Verben einheitlich, und bauen Sie Event-Namen nie dynamisch zusammen – ein Event namens plan_${name}_upgraded erzeugt ein Event pro Kunde und lässt sich nicht abfragen.
Die 8–10 Events, die Ihren Funnel abbilden
Widerstehen Sie der Versuchung, alles zu tracken. Starten Sie mit der Handvoll Events, die einen Nutzer vom ersten Kontakt bis zur Bezahlung verfolgen – Anmeldung, Aktivierung und Umsatz –, und instrumentieren Sie diese gründlich, bevor Sie in die Tiefe gehen. Unten finden Sie ein Start-Set für ein typisches B2B-SaaS; benennen Sie die Events nach den Begriffen Ihres Produkts um. Jedes wird zu einer Zeile in Ihrem Plan, und zusammen bilden sie Ihren ersten First-Party-Datensatz – das Rohmaterial für jeden Funnel, jede Kohorte und jede Retention-Kurve, die Sie bauen werden. Wo jedes Event instrumentiert wird – im Browser oder auf dem Server –, ist eine eigene Entscheidung: Serverseitiges vs. clientseitiges Tracking behandelt die Aufteilung.
| Event | Wann es ausgelöst wird | Warum es zählt |
|---|---|---|
| account_created | Der Nutzer schließt die Anmeldung ab, und ein Datensatz existiert | Anfang des Funnels; der Nenner für jede Conversion-Rate |
| onboarding_started | Der Nutzer beginnt den Einführungsablauf beim ersten Start | Trennt Anmeldungen, die mit dem Setup beginnen, von denen, die abspringen |
| activation_reached | Der Nutzer erreicht Ihren definierten Aha-Moment (z. B. erstes Projekt geteilt) | Das aussagekräftigste frühe Event; prüfen Sie es, statt es vorauszusetzen |
| feature_used | Ein Kern-Feature wird genutzt, mit einer Eigenschaft feature_name | Tiefe des Engagements; Grundlage für Segmente und Retention |
| invite_sent | Der Nutzer lädt ein Teammitglied ein | Frühindikator für Expansion und Bindung im B2B |
| trial_started | Eine Testphase oder ein kostenloser Tarif beginnt | Öffnet den Umsatz-Funnel; Ankerpunkt für die Trial-to-Paid-Rate |
| subscription_started | Der Nutzer wechselt in einen bezahlten Tarif | Der Umsatzmoment; verbindet Growth-Arbeit mit Geld |
| subscription_cancelled | Der Nutzer kündigt einen bezahlten Tarif | Churn-Signal; speist Rückgewinnung und Retention-Analyse |
Eigenschaften tragen die Details, Owner halten Ordnung
Setzen Sie auf wenige, allgemeine Events und verlagern Sie Details in Eigenschaften. Statt eines eigenen Events für jeden Tarif senden Sie subscription_started mit den Eigenschaften plan_name und amount_usd – ein ausführlich beschriebenes Event bleibt abfragbar. Halten Sie die Eigenschaften jedes Events schlank – eine Handvoll, die Sie tatsächlich abfragen, schlägt Dutzende, die Sie nie abfragen. Legen Sie dann die Verantwortung fest: In den meisten kleinen Teams liegt sie bei einem Growth Engineer oder bei der Person, die die Instrumentierung ausliefert, und jedes neue Event sollte über ihren Tisch gehen, damit Plan und Code nie auseinanderlaufen. Wissen Sie schließlich, wo die Events landen. Sie an ein gehostetes Analyse-Tool oder eine CDP zu senden, geht schnell, legt Ihre Verhaltensdaten aber auf fremde Server; sie als First-Party-Daten zu behalten – selbst gehostetes Postgres, Ihr eigenes Data Warehouse –, hält sie in Ihrer Hand. Das ist der zentrale Zielkonflikt zwischen Open Source und SaaS bei Engagement-Tools.