What is a tracking plan?

What goes in a tracking plan

For each event, a useful plan records:

• Name exactly as the code sends it, and a readable display name.
• Trigger — when it fires, in plain words: "after the order is confirmed by the payment provider", not "on click".
• Properties with type, whether required, and an example value.
• Platforms — web, iOS, Android, server.
• Owner and developer — who decides what it means, who implements it.
• Status — where it is in its life cycle.

The life of an event

Events move through stages, and a plan should show where each one is:

• Proposed — someone needs it; not scheduled yet.
• Developing — being implemented.
• Accepting — data is arriving; checking that required properties are filled.
• Live — verified and safe to use in reports.
• Deprecated — no longer collected, kept for history.

The "accepting" step is the one most teams skip, and it is where most bad data comes from: an event that fires but without its value property looks fine until someone sums revenue.

Tracking plans in TapCub

TapCub keeps the tracking plan in the console, linked both ways with event definitions. You can start it from events already collected or from an industry pack, import it from CSV or JSON, export it to a spreadsheet, and move each item through the five statuses above.

Live verification shows, for each planned event, its hits in the last 24 hours and the coverage of required properties, so "accepting" is a check rather than a guess. Event names that arrive through track() but are not in the definitions are listed as unplanned events, which is how spelling variants are caught before they reach a dashboard.

A tracking plan only holds up if every event name follows one pattern; see event naming conventions for rules and examples.

Common mistakes

• A spreadsheet nobody updates. A plan disconnected from live data drifts within weeks. Link it to what is actually collected.
• Triggers described as clicks. "Clicked buy" and "order paid" are different events with different counts.
• No owner. Without one, nobody can say whether an event can be renamed or removed.
• Skipping deprecation. Deleting an event silently breaks old dashboards; mark it deprecated first.

Related guides: Event Tracking, Web Analytics Best Practices and Web Analytics Audit. See also track custom events.

See also

• Data Taxonomy for Analytics: Naming Rules and a Cleanup Example
• Create a tracking plan

See also: What are data types? Programming, statistical and analytics examples.