How to build a tracking plan for your product - Data Research Analysis Collection

TL;DR

A tracking plan is a single document that defines every event your product fires, what properties each event carries, and who owns the data. You can build a solid first version in one to two days using nothing more than Google Sheets and a clear naming convention. Once you have more than five engineers or ten key flows, you will want a dedicated tool like Avo or Segment to manage it.

What You Need Before You Start

Access to your product (web app, mobile app, or both) and at least one real user session recording or session replay
A list of your top three to five business questions you need data to answer (write these down before you open any spreadsheet)
Google Sheets or Notion (free tier works fine for both)
A rough understanding of your current analytics setup, even if it is just “we have Google Analytics on the homepage”
Optional: Mixpanel free tier or Amplitude Starter plan for the destination you will send events to
Optional: a one-hour slot with one engineer who knows the codebase
Optional: Figma or a product spec so you can walk each screen while you plan

You do not need to know SQL. You do not need an existing data warehouse. The plan comes before the implementation.

Step 1: Write Down the Three Business Questions You Need to Answer

Before naming a single event, write down the three questions your team actually argues about in sprint reviews. Something like:

“Where do users drop off in the onboarding flow?”
“Which features do paying customers use most in their first 30 days?”
“What does the path to a second purchase look like?”

These questions become your north star. Every event you add to the plan should connect, directly or indirectly, to one of these questions. If an event does not help answer any of them, put it in a “backlog” tab and do not implement it yet.

Open a Google Sheet. Create a tab called Business Questions and paste your three questions in column A. In column B, write the metric each question maps to. For example, “Where do users drop off” maps to “funnel conversion rate by step.”

You should now see three rows in your sheet with a question and a metric side by side. This two-column table becomes the filter you run every proposed event through for the rest of the project.

Step 2: Map Your User Journey End to End

Draw the full journey from the moment a user lands on your site or opens your app to the moment they complete your core value action, which is the thing your product is actually built for. For a SaaS onboarding flow, that might be “user invites a teammate.” For an e-commerce app, it is “user completes checkout.”

Use a simple list, not a fancy diagram. Write each screen or step as a line item:

1. Landing page
2. Sign-up form
3. Email verification
4. Onboarding wizard step 1 (choose role)
5. Onboarding wizard step 2 (connect integration)
6. Dashboard (first view)
7. Core feature used for first time
8. Invite teammate modal

Do this for your top two or three flows: onboarding, core loop, and upgrade or conversion. Keep each journey to ten steps or fewer at this stage.

You should now see a plain-text list of every meaningful screen and decision point a user passes through. This becomes the skeleton your events hang off of.

Step 3: Choose a Naming Convention and Stick to It

Naming is where tracking plans fall apart. Teams end up with ButtonClicked, button_clicked, btn_click, and ClickedButton all meaning the same thing across different engineers and sprints.

Pick one format and document it. The most common and readable for product analytics tools is Object Action in title case:

Signup Completed
Onboarding Step Viewed
Invite Sent
Plan Upgraded

The object is the thing (Signup, Invite, Plan). The action is the past-tense verb (Completed, Viewed, Sent, Upgraded). Past tense matters because analytics tools record things that happened, not things that are happening.

Add a tab to your Google Sheet called Conventions. Document your format, two or three examples, and a short list of banned words like “Clicked,” “Tapped,” or “Pressed” on their own, since these tell you nothing about what was clicked.

You should now see a conventions tab that any new hire or contractor can read in five minutes and immediately write event names that match your existing ones.

Step 4: Identify Your Key Events

Go back to your journey maps from Step 2. For each step, decide whether it needs a track call. Not every screen view needs an event. Focus on actions that signal intent or completion.

A good rule: if missing this event would leave you unable to answer one of your three business questions, it is a key event. If it is just “nice to know,” put it in the backlog.

For a SaaS onboarding flow, your key events might be:

Signup Started
Signup Completed
Onboarding Step Viewed  (with a "step_name" property)
Integration Connected
Dashboard Viewed
Invite Sent
Plan Upgraded

Seven events. That is enough to answer all three of the example business questions from Step 1. Aim for seven to fifteen key events for your first version. Fewer is almost always better.

You should now see a named list of events that maps directly back to your business questions and your user journey. If an event on your list cannot be traced to both, cut it.

Step 5: Define Properties for Each Event

Properties are the dimensions that make events useful. Without properties, Onboarding Step Viewed tells you someone viewed a step. With properties, it tells you which step, from which referral source, in which plan tier, on which device.

For each event, list every property it needs. Use a table:

Event	Property	Type	Example Value
Signup Completed	plan_tier	string	“free”
Signup Completed	referral_source	string	“google_ads”
Onboarding Step Viewed	step_name	string	“connect_integration”
Onboarding Step Viewed	step_number	integer	2
Invite Sent	invitee_role	string	“viewer”

Keep property names in snake_case. Use consistent types: a boolean is always true or false, never "yes" or 1. Document the possible enum values for any string property that has a fixed set of options.

You should now see a full event-properties table. This is the core artifact of your tracking plan and the document your engineers will actually implement from.

Step 6: Build the Tracking Plan Document

Now consolidate everything into one canonical sheet. Your tracking plan should have these columns at minimum:

Event Name | Description | Trigger (when does it fire) | Properties | Owner | Status | Destination

Status can be Planned, In Dev, Live, or Deprecated. Owner is the team or squad responsible for keeping the event accurate. Destination is where the event goes, such as Amplitude, Mixpanel, or your data warehouse via Segment.

Add a Super Properties tab for properties that should appear on every event, like user_id, session_id, platform, and app_version. These are set once and attached globally rather than duplicated per event.

Color-code the status column. Green for Live, yellow for In Dev, grey for Deprecated. This makes it easy to scan which events are actually firing today.

You should now see a single document that a PM, engineer, and data analyst can all read without a briefing. That is the test of a good tracking plan.

Step 7: Review the Plan With Engineering

Book a 30-minute session with the engineer who will implement the events. Walk through the plan row by row. There are three things you are checking:

Is the trigger point technically feasible? Some events are hard to fire at the exact moment you described.
Are the property values available in the codebase at the point the event fires? A plan_tier property is useless if the app does not have that value in scope on the signup screen.
Are there any naming conflicts with existing events already in your analytics tool?

Update the plan based on their feedback before any code is written. Add a column called Engineering Notes for anything that needs follow-up.

You should now see a plan with red-flagged rows where technical constraints exist, plus a clear list of questions to resolve before implementation starts.

Step 8: Implement and QA Your Events

Once engineering builds the events, QA each one manually before you call it live. Use your analytics tool’s debugger or a tool like the Segment Source Debugger to watch events stream in real time as you walk through each flow.

For each event, check:

The event name matches the plan exactly (case sensitive)
All required properties are present
Property values are the correct type and fall within expected ranges
The event fires once per action, not twice or zero times

Create a QA checklist in a new tab. Mark each event as Passed or Failed. Failed events go back to engineering with a note describing what was wrong.

Event: Signup Completed
Expected properties: plan_tier (string), referral_source (string)
Actual: plan_tier missing on Google OAuth path
Status: FAILED - re-open ticket

You should now see a QA log showing which events passed and which need fixes, with enough detail that the engineer can reproduce the issue without a screen share.

Step 9: Set Up a Governance Process

A tracking plan that nobody updates is worse than no plan, because it gives false confidence. Set up a lightweight governance process before you call this project done.

At minimum:

Any new event requires a pull request to the tracking plan document before any code is written
The tracking plan owner (usually a PM or data analyst) reviews and approves the event name and properties
Deprecated events are marked grey but never deleted from the plan, because historical data still references them
A quarterly audit checks for events that have stopped firing or changed behavior without a plan update

Add a changelog tab. One row per change. Date, event name, what changed, who approved it.

You should now see a process that keeps the plan accurate over time, which is the difference between a tracking plan that helps you make decisions and one that becomes a liability.

Common Mistakes To Avoid

Tracking everything on day one. You end up with 200 events, no clear owner, and a data warehouse full of noise. Start with seven to fifteen events and add more when a specific question demands it.
Skipping the naming convention step. One inconsistency early on compounds. Six months later you have three versions of “Signup Completed” and no way to merge them without touching historical data.
Not including the trigger description. “When the user signs up” is ambiguous. “Fires after the API returns a 200 on POST /users, before redirect to onboarding” is not.
Forgetting to QA on mobile separately. Web and iOS often have different code paths. An event that passes QA on Chrome can still be missing on Android.
Treating the tracking plan as a one-time project. It is a living document. If it is not updated every sprint, it will be out of date within three months and nobody will trust it.
Omitting super properties. Forgetting to attach user_id or app_version to every event means you cannot segment any query by those dimensions later.

When To Level Up

The Google Sheets approach works well for teams of one to three people managing fewer than fifty events across one or two products. once you cross that threshold, the manual process breaks down.

Signs you need a dedicated tool: engineers are merging conflicting event name changes, your QA process takes longer than implementation, you have multiple products or platforms with overlapping events that need to stay in sync, or your analytics destination changed and you need to re-map 80 events manually.

At that point, look at Avo for collaborative tracking plan management, or a customer data platform like Segment or RudderStack for routing and schema enforcement at the pipeline level. Both enforce naming conventions programmatically and flag violations before they reach production.

You can find a full comparison of CDP options and analytics platforms at /category/data-analysis/ to help you decide which direction fits your stack.

Frequently Asked Questions

What is the difference between a tracking plan and an analytics spec?
An analytics spec is usually written by an engineer and describes how to implement events technically. a tracking plan is written by a PM or analyst and describes what to measure and why. in practice, a good tracking plan contains both layers, so you need only one document.

Do I need a tracking plan if I am already using Google Analytics 4?
Yes, especially with GA4. GA4’s event model is flexible, which means without a plan you will accumulate duplicate and inconsistent events quickly. a tracking plan tells you which GA4 custom events to create and exactly which parameters to attach.

How often should I update my tracking plan?
Update it before any new feature ships that changes user behavior. a quarterly audit catches events that drifted without an update. treat it like a README: it should reflect the current state of the product, not the state it was in at launch.

Can I use the same tracking plan for web and mobile?
Yes. use one plan document with a “Platform” column that marks each event as Web, iOS, Android, or All. properties that differ by platform get their own rows with a note explaining the difference.

What tool should I use to actually send the events once the plan is built?
That depends on your stack and budget. Segment and RudderStack are the most common CDPs for routing events to multiple destinations. if you are only sending to one tool like Amplitude or Mixpanel, their native SDKs are simpler. see /analytics-cdp-tools-comparison/ for a full breakdown.

Bottom Line

Building a tracking plan is not glamorous work, but it is the difference between a product that runs on intuition and one that runs on evidence. start with three business questions, map your user journey, lock in a naming convention, and identify the seven to fifteen events that actually answer your questions. build the properties table, get engineering sign-off, QA every event manually, and set up a process to keep the document alive. the whole first version can be done in Google Sheets in a day or two. once your team grows or your event count passes fifty, move to a proper governance tool. for a guide on what comes next after you have clean event data flowing, head to /category/data-analysis/.