Tracking plan

A tracking plan is the working document, usually a spreadsheet or dedicated tool, that lists every analytics event a product needs to fire: its name, the trigger condition, its properties and their expected types, which platforms it applies to, and who is responsible for implementing and maintaining it.

It sits downstream of an event taxonomy — the taxonomy sets the naming and structural rules, and the tracking plan applies those rules to a concrete list of events for a specific product or release. Engineers use it as an implementation checklist, QA uses it to verify instrumentation before launch, and analysts use it as the reference for what data should exist and what it means. This differs from a data dictionary, which documents the resulting stored data (tables, columns) after collection, rather than the intended collection itself.

A tracking plan matters because it turns event tracking into a coordinated, reviewable process instead of ad hoc calls scattered through code, catching missing or duplicate events before they reach production. The common pitfalls are letting the plan drift out of sync with what is actually implemented, and writing events for what's easy to log rather than what a specific analysis question actually requires — the plan should be driven by decisions the business needs to make, not just by what's technically convenient to capture.