Write a tracking plan before you instrument anything

Here is a pattern we see in almost every analytics cleanup. Someone installed a tracking SDK during launch week, a few developers added events as features shipped, and two years later the event list has Sign Up, signup, user_signed_up and Signup Completed v2. Nobody knows which one the board deck uses. The funnel in the analytics tool disagrees with the database. Fixing it means archaeology, then a migration, then explaining to the team why last year's numbers changed.

All of that is avoidable with a document that takes an afternoon to write: a tracking plan. It is a list of every event you will collect, what triggers it, which properties it carries, and who owns it. You write it before anyone touches the SDK, and you change it before anyone ships a new event.

Why bother, in one number

Bad data is the default state, not the exception. In a peer-reviewed study of 75 data quality assessments across many organizations, Nagle, Redman and Sammon found that on average 47% of newly created data records had at least one critical error, and only 3% of the quality scores were acceptable. Their study covered business records in general, not analytics events specifically, but the mechanism is the same. Data that is created without a definition and a check drifts, and nobody notices until a decision depends on it.

Analytics events have an extra problem: they are expensive to fix after the fact. Amplitude's own instrumentation guide makes the point that event names, user identity and project structure are costly to change once data is flowing. Renaming an event does not rename the last two years of history.

Start from questions, not from clicks

The most common mistake is to start by listing every button in the product. You end up with hundreds of events and still cannot answer the questions that matter. Amplitude's data planning playbook frames it the right way round: define your business objectives, break down the key metrics, and only then choose the events and properties that measure them. Its prework guide is blunter, advising teams to track only the events that answer the business goals and warning that too much data obscures answers as easily as too little.

So the first section of the plan is a short list of questions. For a typical B2B SaaS product it might be:

• What share of signups reach the activation moment within seven days?
• Which acquisition channels produce accounts that convert to paid?
• Which features do retained accounts use in their first month that churned accounts do not?

Every event in the plan should trace back to at least one question. If it does not, leave it out for now.

Pick a naming convention and write it down

The vendors disagree on style, which is a useful hint that the specific style does not matter much. Segment recommends an object-action framework with Proper Case event names like Product Viewed and snake_case properties. Amplitude suggests a standard of noun plus past-tense verb, written from the user's perspective, so that Message Sent unambiguously means the user sent it. PostHog recommends lowercase snake case in a category:object_action pattern with present-tense verbs, such as signup_flow:account_create.

What they agree on is the important part. Segment's guide puts it plainly: the convention matters less than keeping it consistent. Choose one, put it at the top of the plan with three examples, and reject anything in code review that does not follow it.

Two rules apply regardless of style:

• No variable data in event names. Segment's example is an event named with a user's email address. Send Signed Up with an email property instead. Dynamic names make funnels unreadable and inflate event counts.
• One event with a property beats many near-duplicate events. Amplitude's playbook compares one Order Completed event with a Payment Method property against separate events per payment method, and favors the single event because it is easier to use in a funnel.

Define properties as carefully as events

Properties are where most quiet errors live. A plan should list each property with its type, allowed values and an example. Three habits help:

• Same object, same properties. Segment recommends that every action on a product carries the same core properties (category, product ID, price, brand) so you can compare across actions.
• No overloaded properties. Amplitude warns against a single Type property used for both items and payments; use Item Type and Payment Type instead.
• Keep the count down. Amplitude's guideline is no more than 20 properties per event. If you need more, the event is probably doing two jobs.

Decide where each event fires, and who the user is

For each event, the plan should say whether it is sent from the browser or app, or from your server. PostHog's guidance is that backend analytics are more reliable than frontend analytics, because ad blockers and interrupted page loads drop client-side events. Our rule of thumb: anything that counts money, signups or activation fires from the server; anything about how people move through the interface can fire from the client, where some loss is acceptable.

The plan also needs one paragraph on identity. Which ID represents a user, when do you call identify, and how do anonymous pre-signup events get linked? PostHog notes that an inconsistent ID format means "user-456" and "USER-456" become two different people. Write the format down once.

Give every event an owner

An event without an owner is an event nobody will notice breaking. The owner is the person who answers when someone asks "what exactly does this count?" and who approves changes. It is usually the product manager or analyst for the area, not the engineer who wrote the code.

A tracking plan can live in a spreadsheet to start. The columns we use are:

1. Event name, following the convention
2. Trigger definition, written precisely: "fires when the account record is created on the server," not "when user signs up"
3. Properties, with type and allowed values
4. Source, client or server
5. Question it answers, linking back to the first section
6. Owner
7. Status: planned, implemented, verified, deprecated

A first plan for an early-stage product is usually 15 to 30 events. That feels small. It is enough to answer the questions on your list, and every event in it will be trustworthy.

Handle change deliberately

Products change, and the plan has to change with them. Two practices keep history usable. First, when a flow changes enough that old and new events are not comparable, PostHog recommends versioning the event name rather than silently changing what an existing event means. Second, mark old events as deprecated in the plan instead of deleting the row, so anyone reading an old chart can find out what it measured.

Once the plan is stable, enforce it. Segment's guide recommends documenting events in a tracking plan and enforcing the convention with automated validation, so unknown event names or wrong property types get flagged instead of quietly landing in reports. Even a simple test that checks event names against the plan in CI catches most drift. That is a good second step. The plan itself comes first, because validation only works against something written down.

When not to bother

If you have 30 customers, you will learn more from talking to them than from a funnel chart, and a tracking plan can wait. Autocapture tools that record every click are also fine for exploration, as long as nobody builds a board metric on them. The moment a number shows up in a board deck, an investor update or a pricing decision, the events behind it belong in a plan with an owner.

A practical next step: write the three to five questions your team argues about most, and check whether your current events can answer them cleanly. The gaps you find are the first draft of your tracking plan.

Sources

• Naming conventions for clean data, Twilio Segment
• Plan your taxonomy (data planning playbook), Amplitude
• Instrumentation pre-work, Amplitude
• Product analytics best practices, PostHog
• Assessing data quality: A managerial call to action, Nagle, Redman and Sammon, Business Horizons (2020)