# Tracking plan for a launch

> Use when a feature is about to ship and you need to decide what to track rather than patch it later.

## Preencher antes de executar

- `{{FEATURE_DESCRIPTION}}`
- `{{QUESTIONS_TO_ANSWER}}`
- `{{EXISTING_EVENTS}}`
- `{{PLATFORMS}}`

## Prompt

```
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.
```

## Como obter um resultado melhor

- Write section 1 with whoever asked for the feature; questions nobody owns produce events nobody queries.
- Give one platform per row rather than "all", or the QA step gets skipped on the smaller platform.
- Freeze the event names before the sprint starts; renaming after launch splits the history in two.

---

Da biblioteca de prompts da QuQi - https://www.quqi.io/pt/prompts/event-taxonomy-tracking-plan