Tracking plan for a launch

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.