How to make an analytics tracking plan, and get your team on the same (Notion) page
Founders and PMs swear by lean, iterative methodologies. Unfortunately, they all soon find out a move-fast-and-break-things approach is incompatible with good analytics.
The insights you gain from user data rely on the tracking choices you made many months and years prior. Careful planning in the earliest days of your project are therefore of utmost importance.
Below, I’ll share how we approach analytics at Pona, including:
- Considering the questions we’re going to be asking ourselves in the future
- Brainstorming criteria we’ll use to identify where each user is in the activation funnel
- Planning, naming and documenting tracking events and user traits
How to create and organize your tracking plan
At Pona, we keep all our company data in Notion, a delightful note taking software packed with power-user features, and wrapped in a clean and intuitive UI.
Within it, we have a Tracking plan page that covers everything our product, engineering and marketing teams might need to implement and understand user events.
Questions
The first step to a good tracking plan is a brainstorming session with your team, where you consider the most likely questions you’re going to be asking yourself in the future.
This helps ensure you’re tracking everything you will need down the line.
It also prevents you from collecting unnecessary data that will just bloat your analytics, and won’t help answer your most crucial questions.
Activation
Next, it’s time to consider the data you’ll need to track where your users are in the activation funnel.
In the examples below, I will use Discovered → Activated → Engaged → Retained, but feel free to adapt the funnel to your needs.
AARRR Pirate Metrics (Acquired → Activated → Retained → Referral → Revenue) are a popular choice in the startup world. Adding criteria for declaring a user as Churned may also be useful, depending on the nature of your business.
When deciding on the criteria for each stage, it is important not to jump straight into details, and consider the bigger picture. Otherwise, you risk limiting yourself to criteria that are easy to measure and quantify, rather than those that best match your users’ journey.
For this reason, I recommend you do this exercise in two passes.
First, describe the criteria in words:
After finalizing the rest of the tracking plan, come back and change the criteria to best approximations using quantifiable user traits and event counts:
Events
Now we have a good idea of the kind of data we’ll need to collect, it is time to create a single source of truth for what exactly we’re tracking, and how.
Naming
Believe me, there’s nothing more dispiriting than wading through years of inconsistent event data, trying to figure out the difference between signedUp, User Signed Up, and New User.
It is crucial to get the naming consistent from the very beginning.
If your company doesn’t have an existing naming convention, I recommend to follow the [Object] + [Action] template for your event names. It has a good balance of consistency, human readability, and ease of parsing in code.
Here are some examples of common events, and how you would name them using the Object-Action template:
signedUp → User Created
sale → Product Sold
Added card → Card Added
Payout Error → Payout FailedWe use camelCase for user traits and properties attached to events (ex. sellerID, deliveryHour, etc.), because they are easy to map in code, yet readable enough to quickly scan in your analytics software.
Documenting
I like to use the powerful database block in Notion for this section, divided into four columns.
Object
User, Order, Product, etc.
Action
Created, Failed, Viewed, etc.
You may want to colour code different actions to make the list easier to parse. At Pona, we mark positive events in green, negative in red, and neutral in blue.
Properties
Metadata attached to the event.
Here too, you may want to colour code them for better readability. At Pona, we mark supply-side properties in pink, demand-side properties in yellow, and all others in grey.
Tracking
Where the event will be tracked in your code. This may be, Client (app), Server (API), or even Offline.
You should discuss this part with your engineering team, as the location of the tracking code impacts the metadata you’ll have available in your analytics software (browser type, and so on).
We like to keep all our company data in Notion, and at the size of our team and project, the table above is enough to keep things clear and consistent.
If you have a large team, you may want to use Airtable instead, and create a separate table for Properties — each with its own set of columns describing whether it is a string or a number, what currency it is in, and so on.
This will take more time than what we just did in Notion, but it’ll save you the need to explain to marketers and developers the exact meaning or format of this or that property again and again.
User traits
Next, you’ll have to decide on the user traits you’re going to track. This is information about each individual user, updated each time they access your product.
I usually list user traits in a code block, which developers can copy and paste, replacing example data with actual user info.
You can also create a new table, similar to the one we just made for events.
In either case, make sure to include comments about different options (such as status codes) and types (Number, String, etc.).
Integrations
Finally, I like to include a list of all third-party integrations sending events or user traits to our analytics.
For example, additional traits might be coming from A/B testing such as VWO, or NPS software such as Wootric:
A living document
Congratulations, you’ve just created your very first tracking plan!
This means your team won’t have to cry six months later because you forgot to collect some crucial data, or misnamed events coming from different platforms.
That said, I can almost guarantee your plan has mistakes.
Bugs will also arise from flawed implementation, and even more inconsistencies will become apparent once you actually try to generate a report in your favourite analytics software.
This means it’s crucial to keep an eye on the data flowing in over time, particularly in the first few weeks after launch.
It also means you should not archive this file, and forget it. Treat your Tracking plan as a living document, which you come back to over time, updating not just events, but also the fundamental questions and funnel criteria, as you better understand your users.
