# A tracking plan: events that answer questions

> How to build an analytics tracking plan from questions rather than buttons: event names, properties, where to send them from, and avoiding event soup.

Published: 2026-04-30 · Source: https://subxcat.com/articles/tracking-plan · Author: SUBXCAT

Analytics in a young product usually gets wired up one of two ways. Either someone turns on autocapture for everything that moves, or a developer adds events along the way and names them whatever comes to mind. Six months later there are three hundred events, half of them duplicates, and nobody can answer a simple question: how many people reached checkout last week? A tracking plan exists to prevent that.

## Start with questions

The plan doesn't start with a list of buttons. It starts with a list of questions the team wants answered regularly. For example:

- how many new users reach the key action, and how long it takes them;
- where they drop off along the way;
- whether they come back after a week and after a month;
- which channels bring the people who stay;
- how paying users differ from free ones.

Every event in the plan should help answer at least one of these. If an event answers nothing, don't add it, even if it "might come in handy later." Later, something else will come in handy.

## Names

Agree on a format once and stick to it everywhere. A convenient one is object plus past-tense action: `project_created`, `invoice_sent`, `plan_selected`. One case style, one tense, so names are easy to search and sort.

What to avoid:

- synonyms: `signup`, `user_registered` and `account_created` for the same thing;
- names based on the UI: `blue_button_clicked` stops meaning anything once the button turns gray;
- data that should be a property: `plan_selected_pro` and `plan_selected_basic` instead of one event with a `plan` field.

## Properties

Properties are what make one event useful across many breakdowns. For `plan_selected`, that's the plan, the billing period and the price. For `invoice_sent`, the amount, the currency, the delivery method, and whether it's the user's first invoice.

Separate event properties from user properties. Plan, country, signup date and source are user properties: set them once and update them when they change. Don't attach them to every event by hand. Sooner or later you'll forget one somewhere.

Don't send personal data to analytics: email, phone, name, message contents. A user ID is enough, and if you really need to, you can tie it to a person in your own database.

## Where to send from

Actions that change state, such as signup, payment or creating an object, should be sent from the server, and only once the operation has actually succeeded. A browser event can be lost to an ad blocker or sent twice, and a payment that failed but landed in analytics is worse than no record at all.

Send from the client what happens only in the interface: screen views, onboarding steps, interaction with hints.

## The document

The plan is an ordinary spreadsheet kept somewhere people will find it. For each event it lists:

- the name and a one-line description;
- exactly when it fires;
- its properties and their allowed values;
- where it's sent from, server or client;
- which question it answers;
- who owns it.

A new event appears in the plan first, then in code. That feels like bureaucracy right up until the first time someone spends a day figuring out how `checkout_started` differs from `checkout_begin`.

## Staying afloat

A couple of dozen events is plenty for a first version. Add new ones when a new question appears, not when a new button does. Once a quarter, go through the list and delete whatever nobody has looked at. After every release, check that key events arrive with the right properties: analytics usually breaks silently, and you find out a month later when a report shows zero.

A good tracking plan is boring. It has few events, they have clear names, and they answer the questions the whole thing was set up for.

SUBXCAT can help draw up a tracking plan around your product's actual questions and wire in events you can trust.