tracking-plan

# Tracking Plan Designs the instrumentation *before* the feature ships, so the question you'll be asked in six weeks is answerable. Produces an event taxonomy with names, properties, triggers, and owners — plus the QA steps that catch the events that silently never fire. **Grounded in:** *Lean Analytics* — Croll & Yoskovitz: instrument the One Metric That Matters and its inputs deliberately, before you need them. Paired with the tracking-plan discipline standardized by Segment and Amplitude: one event per user intent, properties for the dimensions you'll slice by, and a naming convention decided once. **The load-bearing idea:** you cannot retroactively instrument the past. Every question you fail to anticipate costs a release cycle to answer. ## When to use this - A feature is about to ship and nobody has said what gets tracked. - You keep hitting *"we can't answer that from the data"* in metric reviews. - Event names have drifted — `signup_completed`, `completeSignup`, and `user_signed_up` all exist and mean the same thing. - You're standing up analytics on a product area for the first time. - An experiment is being designed and the metric it needs isn't instrumented yet. - Before a funnel analysis you already know you'll want (activation, onboarding, checkout). ## Before you start (gather these) - **The user journey for this area** — the actual steps, in order, including the failure paths. - **The questions you'll need to answer** — write them as questions, not metrics...