Das Tracking-Problem, das kein Tracking-Problem war
Das Tracking-Problem, das kein Tracking-Problem war
"Wir brauchen ein Tracking-Konzept."
So fing das Gespräch an. Ein B2B-SaaS-Anbieter für Projektmanagement, solides Produkt, wachsende Nutzerbasis. Die Anfrage klang klar:
- Welche Daten sollen wir tracken?
- Nach welchem Schema?
- Welche Auswertungen brauchen wir?
Drei Fragen. Alle falsch.
Was sie wollten vs. was sie brauchten
Die Anfrage:
"Wir wollen Impact bei Änderungen erkennen, Nutzungsverhalten verstehen, und verschiedenen Stakeholdern ermöglichen, Entscheidungen auf Basis von Daten zu treffen."
Das Problem dahinter: Niemand hatte definiert, welche Entscheidungen das sein sollen.
"Impact erkennen" – und dann? Was passiert, wenn der Impact negativ ist? Wer entscheidet? Bei welchem Schwellenwert?
"Nutzungsverhalten verstehen" – für wen? Der CEO braucht andere Insights als der Product Owner. Ohne Stakeholder-Mapping ist das ein Dashboard, das niemand nutzt.
"Entscheidungen auf Daten basieren" – welche Entscheidungen? Ohne definierte Optionen gibt es keine Entscheidung, nur Beobachtung.
Der Reframe: Von Events zu Entscheidungen
Die eigentliche Frage ist nie "Was tracken wir?"
Die eigentliche Frage ist: "Welche Entscheidung wollen wir treffen – und welches Signal würde sie verändern?"
| Ihre Frage | Die richtige Frage |
|---|---|
| Welche Events tracken? | Welche Entscheidung steht an? |
| Welches Schema? | Wer braucht welches Signal? |
| Welche Auswertungen? | Bei welchem Wert ändern wir den Kurs? |
Ein Tracking-Konzept ohne Entscheidungslogik ist eine Liste von Events. Mehr nicht.
Was ein Evidence Brief liefert
Statt einer Event-Liste liefert ein Evidence Brief:
1. Eine Zielzahl – aber mit Schwelle
Das Konzept der "One Metric That Matters" stammt aus Lean Analytics. Die Idee: In jeder Phase fokussierst du auf eine Metrik statt auf einen KPI-Zoo.
Das Problem: Eine Metrik ohne Entscheidungsschwelle ist nur eine Zahl auf einem Dashboard.
Nicht: "Unsere Zielmetrik ist Activation."
Sondern: "Wenn Activation unter 35% fällt, stoppen wir den Rollout und analysieren die Drop-off-Punkte."
2. Guardrails mit Schwellen
Nicht "Churn beobachten". Sondern: "Wenn Churn > 3% → Rollout stoppen, Ursachenanalyse starten."
3. Maximal 12 Signale
Nur Events, die den nächsten Schritt verändern würden. Alles andere ist Noise.
4. If/Then-Logik
Für jede Metrik: Was tun wir, wenn sie über/unter der Schwelle liegt? Wer ist verantwortlich? Bis wann?
5. Stakeholder-Mapping
CEO sieht die Zielzahl und Guardrails. Product Owner sieht die Signale. Niemand braucht alles.
Der Unterschied
| Tracking-Konzept | Evidence Brief |
|---|---|
| Liste von Events | Entscheidungsarchitektur |
| "Was messen wir?" | "Was entscheiden wir – und bei welchem Wert?" |
| Dashboard für alle | Stakeholder-spezifische Views |
| Beobachtung | Handlungsfähigkeit |
Warum Tracking-Projekte scheitern
Teams, die ein "Tracking-Konzept" wollen, bekommen oft genau das: eine Liste von Events, ein Schema, ein Dashboard.
Sechs Monate später:
- Niemand schaut auf das Dashboard
- Entscheidungen werden weiter aus dem Bauch getroffen
- Das Tracking wird als "nicht hilfreich" abgestempelt
Das Problem war nie das Tracking. Das Problem war: Niemand hat vorher definiert, welche Entscheidung die Daten ermöglichen sollen.
Fazit
"Wir brauchen ein Tracking-Konzept" ist fast nie die richtige Anfrage.
Die richtige Anfrage ist: "Wir haben eine Entscheidung vor uns – und wissen nicht, welches Signal uns dabei hilft."
Ein Evidence Brief beantwortet das:
- Eine Zielzahl mit Schwelle
- 2-3 Guardrails mit Trigger-Punkten
- Maximal 12 Signale, die den nächsten Schritt verändern
- If/Then-Logik für jede Metrik
- Ein Owner pro Entscheidung
Alles andere ist eine Event-Liste mit Hoffnung.