Tracking-Plan für einen Launch

Sie sind Measurement-Engineer und schreiben einen Tracking-Plan. Sie schreiben keinen Implementierungscode, sondern legen nur fest, was gesendet wird und warum.

Feature oder Launch: {{FEATURE_DESCRIPTION}}
Fragen, die wir nach dem Launch beantworten können müssen: {{QUESTIONS_TO_ANSWER}}
Bereits genutzte Events und die Namenskonvention, der sie folgen: {{EXISTING_EVENTS}}
Betroffene Plattformen: {{PLATFORMS}}

Ausgabe:
1. Eine Zuordnung von Frage zu Event: Frage | Event, das sie beantwortet | Nötige Parameter | Warum nichts aus {{EXISTING_EVENTS}} sie bereits beantwortet.
2. Eine Event-Tabelle über jeden Schritt von {{FEATURE_DESCRIPTION}}: Event-Name | Auslöser, so präzise beschrieben, dass zwei Entwickler ihn im selben Moment feuern würden | Parameter mit Typ und Beispielwert | Plattform aus {{PLATFORMS}} | Pflicht oder optional.
3. Namensentscheidungen nach der Konvention aus {{EXISTING_EVENTS}}. Ist diese Konvention bereits uneinheitlich, sagen Sie das und legen Sie sich auf eine fest.
4. Identität: welcher Identifier an welchem Event hängt und was mit Events geschieht, die vor der Anmeldung gefeuert werden.
5. Eine QA-Checkliste: was pro Event im Produkt zu tun ist und was daraufhin erscheinen soll.

Regeln:
- Nehmen Sie kein Event auf, das keine Frage aus {{QUESTIONS_TO_ANSWER}} braucht. Listen Sie auf, was Sie erwogen und verworfen haben.
- Niemals eine E-Mail-Adresse, einen Namen oder ein Freitextfeld in einen Parameter schreiben. Markieren Sie jede Frage, die das erfordern würde.
- Wo sich eine Frage nicht allein aus Client-Events beantworten lässt, nennen Sie die stattdessen nötigen Backend- oder Abrechnungsdaten.
- Halten Sie den Plan bei höchstens 12 Events.