What is an analytics tracking plan?

It is a single documented source of truth that lists every event your product sends, what each event means, which properties it carries, where it fires and who owns it. The plan is written before the code, so engineers implement an agreed specification instead of inventing names on the fly.

Who should own the tracking plan?

One named person should own it, usually a product manager, growth lead or analyst. Engineers implement it and analysts consume it, but without a single owner the plan drifts within a few sprints as different people add overlapping events.

How many events should a product track?

Fewer than most teams expect. A focused set covering signup, activation, core value actions, payment and churn signals usually answers the important questions. Hundreds of loosely defined events mostly create confusion and reporting disagreements.

Should event names be past tense or present tense?

Either works as long as you pick one and never mix. A common convention is object plus past-tense verb, such as invoice_created or subscription_cancelled, written in lowercase with underscores. Consistency matters more than the specific style.

What should we do about the messy events we already have?

Do not delete history. Build the new plan, map old events to new ones, run both in parallel for a short period, then deprecate the old ones with a documented cut-off date so dashboards can be rebuilt without losing comparability.

How to Build an Analytics Tracking Plan Before Adding Events

Most product teams start tracking the same way. Someone installs an analytics tool, adds a handful of events while building a feature, and ships. Three months later there are four events that all sort of mean "user signed up", half of them carry a property called plan and the other half call it planName, and nobody can say with confidence how many people activated last week.

This is not a tooling problem. It is a planning problem. The fix is an analytics tracking plan: a written specification of what you measure, agreed before any instrumentation code is written. This guide shows how to build one that survives contact with a fast-moving team.

Why ad hoc tracking fails

Events added opportunistically reflect whoever wrote them, on the day they wrote them. The result is a dataset where the structure encodes the history of your sprints rather than the structure of your product. Three predictable failures follow.

Duplicate meaning. Several events describe the same user action, so every metric depends on which one the analyst happened to pick.
Missing context. An event records that something happened but not the properties needed to segment it, so you cannot answer the obvious follow-up question.
Silent breakage. A refactor removes a call, nobody notices for weeks, and a chart quietly flatlines while the team keeps making decisions from it.

The practical cost is that leadership stops trusting the numbers. Once trust goes, decisions revert to opinion, and the whole investment in analytics is wasted.

Step 1: Start from questions, not events

Before naming a single event, write the questions the business needs answered. Good questions are specific and tied to a decision. For example:

What share of new signups complete their first meaningful action within seven days?
Which acquisition source produces users who stay past the second month?
Where exactly in the onboarding flow do people abandon?
Do customers who use the integration feature renew more often?

Each question implies the events and properties you need. Working backwards this way keeps the plan small, because an event that answers no question on the list does not need to exist yet.

Step 2: Define a naming convention and stick to it

Pick one convention and document it on the first page of the plan. A widely used pattern is object_action in lowercase with underscores, where the action is past tense: project_created, invite_sent, subscription_cancelled. Decide and record:

Case and separators. Lowercase with underscores, or title case with spaces. Never both.
Tense. Past tense for things that happened.
Granularity. One event per meaningful user action, with variation expressed through properties rather than through new event names.
Reserved words. Names your analytics tool treats specially, so you avoid collisions.

The granularity rule deserves emphasis. If you create button_clicked_blue and button_clicked_green, you have pushed data into names, where it cannot be filtered or grouped. One event with a variant property is far more useful.

Step 3: Specify properties with types and allowed values

Properties are where most of the analytical value lives, and where most of the mess accumulates. For each event, list every property with its data type, whether it is required, and its allowed values if it is an enumeration.

Also define a small set of properties attached to every event, such as the user identifier, account identifier, plan tier, platform and app version. Consistent global properties mean any event can be segmented the same way, which is what makes cross-feature analysis possible at all.

Be deliberate about what you do not collect. Personal data in event properties creates compliance obligations and makes deletion requests harder to honour. Keep sensitive fields out of the analytics layer and respect the retention rules you have published, a topic we cover in our guide to data retention and deletion policies for SaaS.

Step 4: Write the plan in a shared, reviewable place

A spreadsheet is enough to start. One row per event with columns for name, description in plain language, trigger location, properties, owner, status and the question it answers. The format matters less than two qualities: everyone can find it, and changes are visible.

Treat additions like code changes. A new event is proposed, reviewed by the owner, then implemented. This small amount of friction is what prevents the taxonomy from sprawling back into chaos.

A real-world example

Consider an illustrative scenario. A B2B scheduling tool wants to know why trial conversion feels inconsistent. The team has roughly sixty events, added over a year by four different engineers. Two events fire when a booking is made, depending on which part of the UI was used, and neither records whether the booking came from a shared link or the dashboard.

The team runs a two-week reset. They write down six core questions, which reduce to eighteen events. They define booking_created as the single event for a successful booking, with properties for source, duration, attendee count and whether a reminder was enabled. They map the two legacy events to the new one, run both for three weeks so dashboards can be rebuilt with comparable history, then retire the old names.

The payoff is not a prettier spreadsheet. With one well-propertied event, the team can finally compare trial cohorts by booking source and see that users who create bookings from shared links behave very differently from those who never leave the dashboard. That is a finding they could not have reached before, and it points directly at an onboarding change. Pairing that analysis with cohort retention analysis turns a single insight into a repeatable measurement habit.

Step-by-step process to build your plan

Collect the questions. Interview founders, product, sales and support about the decisions they need data for.
Map the user journey. List the stages from first visit to renewal, and mark the moments that signal progress.
Derive the events. For each stage, name the minimum events that prove the user reached it.
Define properties. Add the dimensions you will want to slice by, including global properties on every event.
Agree the convention. Document naming, casing, tense and granularity rules at the top of the plan.
Review with engineering. Confirm each event can be fired reliably at the point described, ideally server-side where accuracy matters.
Assign an owner. One person approves changes and keeps the document current.
Implement in batches. Ship the activation funnel first, verify it, then move on.
QA every event. Trigger each one in a test environment and confirm the payload matches the specification exactly.
Review quarterly. Retire events nobody queries and add the ones new questions demand.

Where to fire events: client or server

Client-side tracking is easy to add but lossy. Ad blockers, closed tabs, flaky mobile networks and browser privacy features all remove data, and the loss is not evenly distributed, which quietly biases your numbers. Server-side tracking is more reliable for anything that touches money or compliance.

A reasonable default is to fire interface interactions from the client and business facts from the server. A click on an upgrade button is a client event. A completed payment is a server event, because the server is the only place that knows it truly succeeded. Our guide to server-side tracking and conversions APIs goes deeper on the implementation.

Key benefits of a tracking plan

Trusted numbers. When everyone agrees what an event means, reporting disagreements stop consuming meetings.
Faster analysis. Analysts spend their time answering questions instead of reverse engineering event names.
Cheaper engineering. Instrumentation is specified once rather than renegotiated in every pull request.
Easier tool migration. A documented taxonomy can be reimplemented in a new analytics platform without starting from scratch.
Better compliance posture. You know exactly what data you collect and where it goes, which makes privacy requests answerable.

The value of product analytics is capped by the clarity of its definitions. No dashboard can rescue data that nobody can interpret the same way twice.

Common mistakes to avoid

Tracking everything. Volume is not insight. Start narrow and expand when a real question demands it.
Letting the tool define the plan. Build the taxonomy around your product, not around a vendor's template.
Skipping QA. An event that fires twice or carries the wrong property is worse than no event, because it looks trustworthy.
No deprecation path. Without an agreed way to retire events, old and new definitions coexist forever.
Ignoring identity. If anonymous visitors are never linked to the accounts they become, your funnel breaks exactly where it matters most.

Conclusion

A tracking plan is one of the cheapest pieces of infrastructure a growing company can build. It takes a few focused days, needs no new tooling, and determines whether the next year of product data is an asset or a liability. Start from the questions, keep the event list small, specify properties carefully, give the document an owner, and review it on a schedule.

If you want help designing the measurement layer of a product, or rebuilding one that has drifted, see how we approach SaaS product development or get in touch through our contact page.

Frequently Asked Questions

What is an analytics tracking plan?: It is a single documented source of truth that lists every event your product sends, what each event means, which properties it carries, where it fires and who owns it. The plan is written before the code, so engineers implement an agreed specification instead of inventing names on the fly.
Who should own the tracking plan?: One named person should own it, usually a product manager, growth lead or analyst. Engineers implement it and analysts consume it, but without a single owner the plan drifts within a few sprints as different people add overlapping events.
How many events should a product track?: Fewer than most teams expect. A focused set covering signup, activation, core value actions, payment and churn signals usually answers the important questions. Hundreds of loosely defined events mostly create confusion and reporting disagreements.
Should event names be past tense or present tense?: Either works as long as you pick one and never mix. A common convention is object plus past-tense verb, such as invoice_created or subscription_cancelled, written in lowercase with underscores. Consistency matters more than the specific style.
What should we do about the messy events we already have?: Do not delete history. Build the new plan, map old events to new ones, run both in parallel for a short period, then deprecate the old ones with a documented cut-off date so dashboards can be rebuilt without losing comparability.