Was in einen Tracking-Plan gehört und was er nicht erkennen kann

Was ist ein Tracking-Plan?

In der Produktanalyse ist ein Tracking-Plan die schriftliche Spezifikation, die jedes Event eines Produkts auflistet, dazu den genauen Moment, in dem es feuert, die Properties samt Typen, die Quelle, die es sendet, und die Person, der es gehört, abgestimmt, bevor irgendjemand Tracking-Code schreibt. Die Protocols-Dokumentation von Segment definiert ihn als "a data spec outlining the events and properties you intend to collect across your Segment Sources." Amplitudes Fassung ergänzt für jede Zeile den Grund: "A tracking plan defines every event and property you collect, why you collect each one, and which source emits it."

Der Plan ist der Vertrag, der Tracking-Code ist die Umsetzung. Wenn beide sich widersprechen, muss jemand entscheiden, welcher von beiden falsch ist, und ohne Plan gibt es nichts, woran man den Code prüfen könnte. Event-Tracking ist die Praxis, festzuhalten, was Nutzer getan haben. Der Tracking-Plan ist das Dokument, das für jedes Event festlegt, was "getan" bedeutet.

Welche Spalten braucht ein Tracking-Plan?

Ein Tracking-Plan braucht eine Zeile pro Event und so viele Spalten, dass ein Entwickler das Event umsetzen kann, ohne eine einzige Rückfrage zu stellen. Die Spalten unten sind die, die spätere Streitereien verhindern. Der Tracking-Plan-Editor von Segment nutzt eine Teilmenge davon, mit den Namen Name, Description, Status, Data Type und Permitted Values.

Die Liste der Datentypen von Segment ist ein vernünftiger Standard für die Spalte Typ: "any, array, object, boolean, integer, number, string, null, Date time", wobei Datums-Zeit-Werte "required to be in ISO-8601 format" sind. Die Spalte Permitted Values akzeptiert "simple regular expressions to validate property values", und das funktioniert nur bei String-Properties.

Wie sieht eine ausgefüllte Zeile im Tracking-Plan aus?

Eine ausgefüllte Zeile liest sich wie eine kleine Spezifikation. Hier ist ein Event aus dem Registrierungsablauf eines SaaS-Produkts, so geschrieben, wie ein Plan in einem Repository es ablegen würde:

event: signup_completed
trigger: >
  Fires once, from the server, after the account row is written.
  Not on button click. Not on page load of /welcome.
answers: Signup-to-activation funnel, weekly signups by channel
source: backend
owner: growth-eng
status: live
properties:
  plan:
    type: string
    required: true
    allowed: [team, pro]
  signup_method:
    type: string
    required: true
    allowed: [email, google, github]
  invited:
    type: boolean
    required: false

Den Trigger-Text machen die meisten Pläne falsch. "Feuert bei der Registrierung" sagt nicht, ob ein fehlgeschlagenes Absenden des Formulars zählt, ob ein erneuter Versuch doppelt feuert und ob das Event aus dem Browser oder vom Server kommt. "Not on button click" schließt das häufigste Duplikat aus, bei dem der Klick feuert und der Server das Formular danach ablehnt. Der Namensstil ist eine eigene Entscheidung, und wer eine Namenskonvention für Events festlegt, bevor die erste Zeile steht, spart sich später eine Umbenennung.

Was kann ein Tracking-Plan-Tool prüfen und was nicht?

Ein Tracking-Plan-Tool prüft die ankommenden Events gegen die Events, die der Plan beschreibt, und es kann Ihnen nichts über Events sagen, die nie ankommen. Diese zweite Hälfte ist das Nützlichste, was man über diese Tools wissen kann, und die Anbieter sagen es selbst.

Die Dokumentation von Segment beschreibt die Prüfseite: "Violations generate when an event doesn't match the spec'd event in the Tracking Plan." Dann, in der Beschreibung der Spalte Status: "You can't require a Track call because Segment is unable to verify when a Track call should be fired." Segment kann prüfen, ob ein Event seine Pflicht-Properties hat, aber es kann nicht wissen, dass das Event hätte feuern sollen und es nicht getan hat.

Amplitude deckt die Gegenrichtung ab. Events, die ankommen, ohne im Plan zu stehen, erscheinen als "Unexpected", und Amplitude schreibt: "You can add them to your plan, or delete them to stop ingestion and remove them from your data catalog." Für die fehlende Richtung veröffentlicht Amplitude eine eigene Anleitung mit dem Titel "Planned events that never arrived: confirm the problem", die dazu auffordert: "Compare your tracking plan with observed data and your planning records to find planned events that never reached Amplitude." Dieselbe Seite sagt "Data Assistant doesn't identify these entries" und dass Observe, die Ansicht, die zeigt, ob ein Event angekommen ist, "the selected time range, up to 14 days" abdeckt.

Ein grünes Validierungs-Dashboard heißt also, dass jedes angekommene Event zu seiner Spezifikation passte. Es heißt nicht, dass jedes Event der Spezifikation auch ankommt. Die praktische Lösung ist eine Prüfung pro Release. Listen Sie die im Plan als live markierten Events auf, fragen Sie für jeden Namen die jüngsten Daten ab und markieren Sie alle mit null Treffern. Amplitudes Anleitung fügt die richtige Vorsicht hinzu: Ein Event ohne Aktivität "might belong to a rare workflow, a disabled feature, or a future release", also fragen Sie den Owner, bevor Sie die Zeile löschen.

Welche Limits der Ziel-Tools gehören in den Plan?

Die Limits jedes Tools, in das die Events fließen, gehören in den Plan, weil eine Zeile, die ein Limit reißt, im Ziel-Tool stillschweigend scheitert. Google Analytics sagt es deutlich: "Google Analytics doesn't log events, event parameters, and user properties that exceed the following limits."

Die beiden Tools scheitern unterschiedlich, wenn ein Plan sie überschreitet. GA4 verwirft das Element, sein Beispiel lautet: "Analytics doesn't process the 26th user property nor does it process an event name with more than 40 characters." Amplitude nimmt weiter Daten an, aber "stops indexing new values", die Daten existieren also in Exporten, lassen sich in Charts aber nicht abfragen. Amplitude ergänzt, dass Events jenseits des Event-Typ-Limits "still count toward the monthly event volume". Ein außer Kontrolle geratener Tracking-Bug kostet also Geld für Daten, die niemand in einem Chart sehen kann.

Segment hat ein eigenes Limit für Pläne, die als Dateien verwaltet werden: Eine hochgeladene Tracking-Plan-CSV "must be smaller than 15 mb" und muss "have fewer than 100,000 rows and 2,000 rules."

Wie viele Events sollte die erste Version enthalten?

Die erste Version sollte die wenigen Events enthalten, die die Fragen beantworten, die das Team ohnehin jede Woche stellt, und sonst nichts. Amplitudes Implementierungsleitfaden sagt "resist the urge to track everything upfront" und empfiehlt "starting with two important events in your product to give you initial insights." Sein Taxonomie-Playbook ordnet die Arbeit so: zuerst Geschäftsziele, dann Schlüsselkennzahlen, dann die Events und Properties, die diese Kennzahlen brauchen.

Diese Reihenfolge ist richtig. Beginnen Sie bei der Kennzahl aus dem Wochenreview, etwa der North Star Metric, schreiben Sie die Frage auf, die sie aufwirft, und fügen Sie nur die Events hinzu, die zu ihrer Beantwortung nötig sind. Ein Registrierungsablauf, der eine Funnel-Analyse braucht, braucht ein Event pro Schritt und eine Property, die das Ergebnis aufteilt, nicht vierzig Events für jeden Klick auf der Seite. Wenn Sie Flowsery nutzen, gilt für sein Goal-Tracking: Es "erfasst Anmeldungen, Käufe, Downloads und benutzerdefinierte Events an einem Ort", und im Plan entscheiden Sie, welche dieser Goals es wert sind, definiert zu werden.

Wie halten Sie einen Tracking-Plan aktuell?

Ein Tracking-Plan bleibt aktuell, wenn eine Änderung am Tracking-Code nicht gemergt werden kann, ohne dass der Plan passend mitgeändert wird. Alles andere ist eine Erinnerung, die Leute ignorieren.

Die Spalte Status erledigt den Großteil der Arbeit. Wer ein Event als veraltet markiert, statt seine Zeile zu löschen, verhindert, dass ein neuer Entwickler sechs Monate später den alten Namen wieder einführt. Beide Tools führen eine Historie. Segment sagt, dass per Upload gemachte Planänderungen "reflected in the Audit Trail and Tracking Plan changelog" sind, und sein CSV-Export benennt jede Datei workspaceSlug-trackingPlanName--yyyy-mm-dd--hh-mm-utc. Ein Plan, der im Repository neben dem Code liegt, bekommt die Historie aus der Versionskontrolle gratis dazu.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem Tracking-Plan und einer Namenskonvention für Events?

Eine Namenskonvention für Events ist eine einzelne Regel innerhalb eines Tracking-Plans: wie Namen gebildet werden, etwa object_action in Snake Case. Der Tracking-Plan ist die vollständige Liste der Events, die dieser Regel folgen, mit Trigger, Properties, Typen, Quelle und Owner für jedes Event.

Wem sollte der Tracking-Plan gehören?

Eine namentlich genannte Person sollte Änderungen freigeben, und zwar aus dem Team, das die Daten am meisten liest, während Entwickler neue Zeilen vorschlagen. Ein Plan, den jeder ohne Review bearbeiten kann, driftet in denselben Zustand wie gar kein Plan.

Sollte ein Tracking-Plan in einer Tabelle oder in einem Tool liegen?

Eine Tabelle reicht für eine erste Version mit ein paar Dutzend Events. Ein Tool wie Segment Protocols oder Amplitude Data prüft eingehende Events zusätzlich gegen den Plan, und eine Datei im Code-Repository bringt Review und Historie über Pull Requests mit.

Gehören serverseitige Events in denselben Tracking-Plan?

Ja. Führen Sie einen einzigen Plan mit einer Spalte Quelle, denn derselbe Event-Name, vom Browser und vom Server gesendet, zählt doppelt, wenn der Plan nicht festlegt, welcher der maßgebliche ist. Amplitudes eigene Definition eines Tracking-Plans enthält "which source emits it".

Wie finden Sie geplante Events, die nie gefeuert haben?

Vergleichen Sie die im Plan als live markierten Events mit den Event-Namen in den jüngsten Daten und markieren Sie alle mit null Treffern. Segment schreibt, dass es keinen Track-Call verlangen kann, und Amplitude sagt, dass sein Data Assistant diese Einträge nicht erkennt, also meldet kein Validierungs-Dashboard das Problem von selbst.

Macht Autocapture einen Tracking-Plan überflüssig?

Nein. Autocapture zeichnet Klicks und Seitenaufrufe auf, aber nicht, was ein Klick bedeutete, etwa welchen Tarif ein Nutzer gewählt hat oder ob der Server das Formular angenommen hat. Die Events, die Umsatz- und Aktivierungskennzahlen speisen, brauchen weiterhin einen schriftlichen Trigger und eine Property-Liste.

Was sollte in der Spalte Trigger stehen?

Der eine Moment, in dem das Event feuert, in einfachen Worten, samt dem, was nicht zählt. "Feuert bei der Anmeldung" lässt offen, ob ein fehlgeschlagenes Formular oder ein Retry zählt und ob Browser oder Server das Event sendet. "Feuert einmal vom Server, nachdem die Account-Zeile geschrieben ist. Nicht beim Klick auf den Button" lässt nichts zu raten.

Mit wie vielen Events sollte ein Tracking-Plan starten?

Starten Sie mit den wenigen Events, die Fragen beantworten, die das Team jede Woche stellt. Amplitudes Implementierungsleitfaden sagt "resist the urge to track everything upfront" und empfiehlt, mit zwei wichtigen Events zu beginnen. Fügen Sie weitere nur hinzu, wenn eine Kennzahl sie braucht.

Was passiert, wenn ein Plan die Limits von GA4 oder Amplitude überschreitet?

GA4 verwirft das Element, sodass eine 26. User Property oder ein Eventname mit mehr als 40 Zeichen nie verarbeitet wird. Amplitude nimmt weiter Daten auf, indexiert aber keine neuen Werte mehr. Die Daten tauchen in Exporten auf, lassen sich aber nicht in Charts abfragen. Events über dem Limit für Event-Typen zählen weiter zum monatlichen Eventvolumen.

Warum ein Event als deprecated markieren, statt die Zeile zu löschen?

Eine Zeile mit dem Status deprecated verhindert, dass ein neuer Entwickler den alten Namen Monate später wieder einführt. Außerdem bleibt die Historie im Plan. Fragen Sie vor dem Löschen einer Zeile ohne Aktivität den Owner, denn das Event "might belong to a rare workflow, a disabled feature, or a future release".