Correctly tracking how users are using your product and how they engage with it is the key to healthy product analytics.
?Hint: A successful analytics tracking plan is the key to healthy product analytics
Let’s simplify: what’s a tracking plan, and what does it contain??
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:
- Events – what users or accounts perform at each stage;
- Properties associated with each event;
- Account & user properties.
The events and properties tracked are clearly defined and broken down further into additional dimensions for extra insights.
Why is a tracking plan needed – the business context??
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.
What the tracking plan will enable you to do ✔️
- Set the events behind the main metrics to track; the events pertain to any customer journey pillars – acquisition, activation, etc.
- Determine how the events are tracked: server-side, client-side, from a specific integration;
- See the events’ tracking status;
- Understand the context of each performed event (through event properties)
- Set account properties that need to be tracked, which will be helpful in segmentation.
How to approach the elements of the tracking plan as a product or marketing person ?
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:
- Which are our most efficient acquisition channels? (pillar: Acquisition)
- How can I improve the onboarding process? (pillar: Activation)
- What feature usage influences stickiness? (pillar: Retention)
- What determines accounts to upgrade to higher packages? (pillar: Revenue)
- What activity patterns are most likely to trigger referrals? (pillar: Referral)
Then, you expand each question into more sub-questions.
For example, to determine the broader topic of improving onboarding, you’ll need to understand:
- How long does it take accounts to get onboarded?
- Where do users drop off during the onboarding process?
- What actions and emails influence onboarding success in a positive (or negative) way?
- Etc.
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.
How to approach the elements of the tracking plan as a product or marketing person ?
Events
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.
Core events
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:
- documentId
- documentName
- numberOfCharacters
- numberOfWords
- template
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.
UX events
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:
- Tracking page views – content about how the page views are tracked.
- UI interaction events – clicks, drags and drops, and form submissions are the most common UX tracked actions.
Make sure to include all of the tools that you want to use for UX tracking. Companies will often use more than one, such as Clarity for video recording, Google Analytics for media attribution, etc.
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.
- UX event properties – the properties that need to be sent with any UX event. Sent client-side.
- Account properties attached to UX events – This section contains the account properties that need to be tracked together with UX events.
Third-party events
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.
Account / User identifiers
User and account identifiers are unique elements that will help you identify specific users and accounts across devices and time.
Examples:
- User id
- Company id
- Email address
- Phone number
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.
Account/User properties
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:
- Paid plan details
- Account status (trial, free, paid, etc.)
- Country
- Company size
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:
- Using underscores: plan_name
- Using camel copy: planName
Don’t use spaces in the names of the properties. It’s okay to use spaces in the values (e.g., planName: Pro Annual).
Integrations
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.
Testing & validation
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.
Wrap-up on the importance of the tracking plan
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.
