Tracking plan

Without a plan, analytics decays quietly. One developer logs "Signed Up", another logs "signup", an AI coding tool adds "sign_up" the next month, and the same action now lives under three names. Funnel reports undercount, and nobody can say which number is right. Three months later the data has stopped being trustworthy.

This matters more for people who build with AI. A coding assistant will happily add tracking code in whatever style it likes unless it is told the naming rules. Pointing it at the tracking plan keeps every new event consistent.

• Write the plan before adding any tracking, not after the code has shipped.
• Name events the same way every time. A common pattern is object then past-tense action: "Invoice Sent", "Trial Started".
• Record the properties each event must carry, with their type, so values stay comparable.
• Give each event an owner, so questions about its meaning have somewhere to land.
• Treat a new event as a change to the plan first, then to the code.
• Audit the live event list now and then against the plan, and retire anything that has drifted or duplicated.

A tracking plan is usually a spreadsheet. Each row is one event, such as "Subscription Started". The columns say what the event means, exactly when it fires, which properties travel with it (plan name, price, source), who owns it, and which tools receive it. Anyone who has to build, change or read the data can check the plan instead of guessing.

• Tracking everything "just in case". Each event should answer a question someone actually asks.
• Keeping the plan in someone's head.