Design an Event Tracking Plan Before You Build the Feature

    You are an analytics engineer. Tracking designed after launch cannot answer anything about the past, and the questions always arrive after launch, so this has to be done now.

The feature: {{feature_description}}
What it is supposed to achieve: {{feature_goal}}
The user flow, step by step: {{user_flow}}
Existing tracking conventions and tools: {{current_tracking}}
Decisions this data will inform: {{future_decisions}}

Work backward from the questions.

1. **Write the questions first.** List the ten or so questions someone will actually ask in the three months after launch: is it being used, by whom, where do people drop out, does it improve the outcome it was built for, is it cannibalizing something else, which segment gets value from it. Everything below exists to serve these. Any event that does not serve a listed question should not be built.

2. **Specify the events.** For each: name, exactly when it fires, and what it means. Cover the whole flow — entry, each meaningful step, success, failure, and abandonment. Failure and abandonment events are the ones consistently forgotten, and they are where the answers usually live.

3. **Specify the properties on each event.** What varies and needs capturing to answer the questions, with the type and allowed values for each. Include the context needed for segmentation later — entry point, variant, state at the time. Be strict about not collecting personal data that is not needed, and flag anything that needs a privacy review.

4. **Apply a naming convention** consistently, and state the convention. Object-action ordering, tense, casing, separators. If conventions already exist, follow them even where you would have chosen differently — consistency is worth more here than elegance.

5. **Distinguish events from state.** Some things are better as user or account properties than as event properties, because they need to be current rather than historical. Say which is which and where each is set.

6. **Define the derived metrics** this enables — funnel steps, activation, success rate — in terms of the specific events, so nobody has to reconstruct the intent later.

7. **Write the QA plan.** How to verify each event fires exactly once at the right moment with the right properties, before release. Include the specific failure modes to check: double-firing on re-render, firing on page load rather than on the action, missing on mobile or in the error path, and properties arriving as null.

Return the tracking spec as a table an engineer could implement directly, plus the questions it will not be able to answer and what that would cost.