Tracking Plan

A tracking plan is the single source of truth that defines every analytics event you collect — its name, when it fires, and the properties attached to it. It's a spreadsheet or schema (Avo, Segment Protocols, and Iteratively formalize it) that keeps `Signup Completed` from also appearing as `signup_complete`, `Sign Up`, and `SignupDone` across three developers. For builders, an untracked or inconsistently tracked product is one where every funnel and cohort is quietly wrong, and nobody notices until a board metric looks off. The plan enforces naming conventions (usually object-action, past tense), a typed property schema, and an owner for each event. Practical note: write the plan *before* instrumenting, version it in git, and validate incoming events against it in CI so a rogue `event: undefined` gets rejected at build time rather than polluting your warehouse for months. Treat it as a data contract between product, engineering, and analytics — renaming a live event breaks every downstream report.