An analytics data tracking plan (a.k.a. tracking plan) is designed to document the data you need for product analytics: it covers everything you need to track in your product about how users are using it and how they engage with it.
A tracking plan is a collaborative document between dev, product, and marketing. It is critical in your product strategy because only by getting good quality data will you be able to trust the analysis that follows and understand how your product is used and how to improve it.
It’s the equivalent of the construction blueprint before you start building.
At a high level, the tracking plan contains information on:
The events and properties tracked are clearly defined and broken down further into additional dimensions for extra insights.
Business roles know what they want to analyze at a high level (activity within their app/onboarding). Still, they don’t always know what they need to track or how to give technical specifications to the dev team.
Technical roles know how to track but don’t know what is needed.
A tracking plan solves both of these problems and assures business teams that they are tracking the right data correctly.
It’s beneficial for the dev team, as they can work on integrations much more easily (without asking product or marketing too many questions). They will understand what tool is used for what purpose when collecting and processing data and how to track events and properties.
We now understand what a tracking plan is and why we need it. Next, we’ll look at how to build it. Remember not to track every possible event and piece of data within the product – but focus on what you need for a meaningful analysis.
Think about what you want product analytics for – and you’ll immediately understand what elements you need to include in the tracking plan.
Here are examples of questions that you will want product analytics to answer for you:
Then, you expand each question into more sub-questions.
For example, to determine the broader topic of improving onboarding, you’ll need to understand:
With this mindset, you will not miss any important events that need to be tracked to understand specific stages of the customer journey.
This brings us to a crucial point – before building your data tracking plan, you must first have your customer journey map in place. Only when you have a solid understanding of (and alignment!) the customer journey map will you know what elements to include in the tracking plan, and the questions above make total sense.
This chapter contains a list of events that need to be defined for tracking: core (main) events, UX events (describe the interaction with the product interface), and 3rd party events. Some tracking plans do not separate core from UX events into distinct categories. We recommend this separation for clarity.
SaaS businesses typically track 10-30 core events as part of their product analytics setup.
Think of core events as the critical events in your product for which you wish to know: who did it, what they did, and what the context was.
Here is how we recommend documenting these events:
Event name – should be unique in the Tracking Plan and as straightforward as possible.
Example: The following event: “Load campaign” doesn’t say if the user finished loading the campaign or just started. Using “Loaded campaign” or “Started loading campaign” clarifies things.
We recommend starting the event name with a verb and using past tense verbs as much as possible.
Event description – This is free text. Make sure to add a description for each event name, describing what it means accurately. By doing so, you avoid the situation where a team member says: “I thought this event meant something else,” especially six months after you reported it week-by-week to management.
The person who does the implementation should be encouraged to add details of how it is implemented.
Event properties – Every event should also carry properties that detail the event’s context. Event properties are specific per event, so it’s beneficial to be consistent every time you name them.
Example: An event such as “Saved document” could carry event properties like:
The tracking plan should also describe the expected values for each event property and if the data source is server-side or client-side.
Everywhere possible, track core events server-side as this method is the only one that guarantees 100% data accuracy. With client-side tracking technology, firewalls, proxies, or browser add-ons can block or even modify the data that is being sent from the user.
Here is an example of documentation for a core event:
Account properties attached to core events
Every time a core event can potentially impact an account property, that account property should also be included in the event. That way, the account properties will be up-to-date in real-time, without delay.
For example, an event like “Upgraded plan” should also have the plan name as an account property to ensure that the account is automatically part of the correct segment.
Every event should be associated with a user and, if you are B2B, with an account. This is critical for B2B SaaS businesses. You can read more about account-based analytics here.
These are the events that describe the interaction with your product interfaces, such as loading screens or pages, starting to fill forms or clicking.
Related to UX events, a tracking plan can capture information about:
Make all domains where the codes should be placed clear to the development team.
More sophisticated companies will often use a platform like Segment or a tag manager like the free one offered by Google so that all domains are managed in one place, and development teams will not be involved in activating or deactivating them.
These events happen in other applications, such as payment platforms, email marketing, CRMs, support platforms, etc., and are integrated into the product analytics platform.
These are important events – and you will use the information extensively to segment your user base for various automatic or manual campaigns, based on combined triggers – what happens in your product, correlated with third-party data.
If you use a product like Stripe or Paddle to charge your customers, the best data source for when people pay, what they paid for, or the subscription status would be the payment platforms directly.
When you combine third-party data with your analytics insights, you can trigger automated campaigns that will improve, for example, your free trial to paid conversion.
User and account identifiers are unique elements that will help you identify specific users and accounts across devices and time.
Adding multiple identifiers, such as ids and email addresses, will increase your chances of integrating your analytics data with marketing automation or CRMs.
Account identifiers must be set correctly from the beginning. Your product is either user-based (single user per account) or account-based, where multiple users can manage an account.
Incorrectly setting identifiers will set you up for difficult times ahead if accounts start getting merged when they shouldn’t be or if multiple identities represent a single account. Both of these scenarios will make your data unusable and non-trustable.
Here’s a hack: make sure to document the identifiers from third-party data sources in your own backend. Your backend should be aware of the payment information (e.g., Stripe), marketing automation or CRM (e.g., Hubspot), email marketing (e.g., Intercom) identifiers, or those for any other system where you hold customer data. Make that data available to your analytics systems.
This will enable you to gather analytics data quickly and easily in your marketing automation stack.
They are properties of users or accounts that enable segmentation.
If your product is user-based (most B2C products are), you can call them user properties. Their purpose is to enable segmentation.
The more you collect, the easier it will be to segment data; by now, you probably know that not all of your users are the same.
A crucial account property that you need to set is “created_at.“
It’s a property that contains the timestamp of when the account was created. This account property will enable cohort-based analytics (which, for product analytics, is the only one that matters).
Other powerful account properties we consider “a must” are any qualification information you collect as part of the registration process. Having such data available will make it easier to set up correct benchmarks for your onboarding process; customer lifetime value calculations as different segments will often have very different numbers.
You’ll also quickly define the best segment to focus on.
Other powerful account properties, and often a must:
Some account properties should be updated only on specific events (e.g., qualification questions, only with the signup events), and others should be sent regularly to product analytics so you can be sure of the accuracy of the data.
How to address this: every time a user logs in (including when they first created an account), they should automatically generate a request to the product analytics solution containing all the account properties.
When naming the account properties, make sure to keep consistency in style. It can eliminate a lot of problems in the future, and it will look professional.
The most common methods to name account properties:
Don’t use spaces in the names of the properties. It’s okay to use spaces in the values (e.g., planName: Pro Annual).
We hinted about this already; you will connect your product analytics tool via API (both data-in and data-out) to other tools that you are using so you can source data across your martech stack. Like this, you are making analytics actionable in an automatic fashion.
Many companies do not include integration data in their tracking plan, but doing so adds to the transparency of the data available for analysis.
Name the tools from which you collect data and list the event names, event properties, and account properties they are sending to you. Also, include a link to the documentation they have available regarding their data.
Building a data tracking plan is a significant step, but it’s not enough to have this in place before you start analyzing your data. The next and crucial step is data validation.
We cannot stress this enough.
You must have a way to compare the data piped into your product analytics with your source of truth for complete accuracy.
InnerTrends has developed a Data Validation Center exactly for this purpose, and we work with your team to solve any data validation issues.
Having all specifications documented and up-to-date is critical for your product analytics’ potential to drive healthy, valuable, and actionable insights.
A proper analytics setup is a critical milestone in your product analytics success – and the tracking plan is a massive part of this.
Besides, a tracking plan is an asset by itself. Your dev team will love you for it as you’ll make their life easier.
Getting team alignment on the metrics that matter is another important aspect of the product analytics setup – taking a step back and asking the right questions will help you move forward in the right direction. Working on your tracking plan is an excellent opportunity to do this.
You’ve got an ideal data analysis framework with a reliable, validated setup. Pus, you’ll be able to trust your data and the insights you get from it.