Use when a feature is about to ship and you need to decide what to track rather than patch it later.
event-taxonomy-tracking-plan.md
You are a measurement engineer writing a tracking plan. You are not writing implementation code, only specifying what gets sent and why.
Feature or launch: {{FEATURE_DESCRIPTION}}
Questions we must be able to answer after launch: {{QUESTIONS_TO_ANSWER}}
Events already in use and the naming convention they follow: {{EXISTING_EVENTS}}
Platforms in scope: {{PLATFORMS}}
Output:
1. A question to event map: Question | Event that answers it | Parameters needed | Why nothing in {{EXISTING_EVENTS}} already answers it.
2. An event table covering every step of {{FEATURE_DESCRIPTION}}: Event name | Trigger, described precisely enough that two developers would fire it at the same moment | Parameters with type and example value | Platform from {{PLATFORMS}} | Required or optional.
3. Naming decisions, following the convention in {{EXISTING_EVENTS}}. If that convention is already inconsistent, say so and pick one.
4. Identity: which identifier is attached at each event, and what happens to events fired before sign in.
5. A QA checklist: for each event, what to do in the product and what should appear.
Rules:
- Do not add an event that no question in {{QUESTIONS_TO_ANSWER}} needs. List what you considered and dropped.
- Never put an email address, name, or free text field into a parameter. Flag any question that would require it.
- Where a question cannot be answered from client events alone, say what backend or billing data is needed instead.
- Keep the plan to 12 events or fewer.
Replace each placeholder with your own detail. The more specific you are, the less the model invents.
When do I write a plan rather than add events after launch?
Before the sprint starts, and specifically before event names get chosen in code. Events added afterwards have no history, so the first month of the launch stays unanswerable, and renaming later splits the series in two. Even when the feature ships this week, the plan is cheaper than the retrofit.
What do I need in front of me?
The feature described step by step, the questions you must answer after launch, existing event names with the convention they follow, and the platforms in scope. Write the question list with whoever asked for the feature. Questions nobody owns become events nobody queries, and they still cost implementation time.
What comes back?
A question to event map, an event table with triggers described precisely enough that two developers fire them at the same moment, parameters with type and example, naming decisions, identity handling before and after sign in, and a QA checklist. The trigger wording is what decides whether the data is usable later.
What is the mistake that costs me here?
Writing all in the platform column instead of one row per platform, because QA then gets skipped on the smaller one and you find out a month later. The other is a parameter carrying an email address, a name or free text. The prompt refuses those and flags the question that would need them.