Getting started with product analytics: create a tracking plan
The second step of a successful Product Analytics strategy is a well-though tracking plan
The second step of a successful Product Analytics strategy is a well-though tracking plan
Table of Contents
Title
Title
Title
Welcome to the second episode of our mini-series about Product Analytics.
In our last article, we started defining our business goals; today, we’ll see how to create a tracking plan and prepare for the actual implementation.
As a product analytics manager, you are responsible for ensuring that the correct data is collected and tracked to gain actionable insights into how your product is being used. To do this, you need to create a tracking plan that outlines what data needs to be collected and how it should be tracked.
What is a tracking plan?
A product analytics tracking plan (or simply a tracking plan) is a document that helps you map your business goals to specific events and properties that you want to track. Collecting and analyzing data from these events and properties will help answer questions about your business goals.
Your implementation plan is also a map for your developers when they implement a product analytics platform.
Why create a tracking plan at all?
There are so many things that you could track. If you track everything without knowing upfront the types of questions you want to be able to answer, you're going to end up with a lot of data and no idea of what to do with it.
A tracking plan helps you understand your business's goals, questions and answers and focus on collecting the data that will help you understand your business’s progression.
A living document
A tracking plan starts with the business goals you defined in the previous step (check out our article "Getting started with product analytics: define business goals").
For each goal, note down the key questions you want to understand about your product and the user behavior in your product.
Then, identify the user flows or behavior patterns that will help you answer each question.
Finally, pinpoint the specific events and their related properties that map to those flows.
Like many other product-related assets, the tracking plan is a living document that will evolve over time. It will start as a tracking plan you create upfront, which your developer can implement.
However, as you make changes to your product, the tracking plan will need to be amended and updated with new events and properties that become important.
Some examples of changes to the product can include:
flows being altered within the product,
revisions being made to key behaviors that are being driven through the product,
new features being launched.
How to create a tracking plan
Let's see how we could approach a hypothetical project management app tracking plan.
Imagine that our goal is to have more active users in the app.
Our first objective should be to identify the key activity that will accurately indicate that we are helping our users achieve this goal. In this case, we might assume that if a user invites another user, they get value out of the product. For this reason we could decide to track an event called "Member Invited".
However, this is not enough! We also need to track what the user does before they invite someone (to optimize that funnel) and what the user does afterward (to ensure they continue to get value from the product). Therefore, we should add two other events to our "Member Invited" event: "Account created" and "Workspace configured".
These are the three key events we'll track in our flow.
Tracking events allows you to understand why people are more or less successful at completing each step. For example, if you find out that users who have a hard time configuring their workspaces are also less likely to invite someone, it might be worth thinking about how to optimize the “configure your workspace” experience.
We would have this situation:
Goal: Have more active users
User flow: Account created -> Workspace configured -> Member invited
Events
Account created
Workspace configured
Member invited
Now for each of the events we have listed here, we have multiple properties that we want to track. These properties provide details about the event that might give you insight when doing your analysis later.
This would bring us to this:
Goal: Have more active users
User flow: Account created -> Workspace configured -> Member invited
Events
Account created
Property 1: plan | Example Value: (trial, premium)
Property 2: company_id | Example Value: (12342)Workspace configured
Property 1: company_id | Example Values: (12342)
Property 2: onboarding_variant | Example Values: (Test A, Test B, Control)
Property 3: plan | Example Values: (trial, premium)Member invited
Property 1: invite_method | Example Values: (Email, Url, QR Code)
When defining properties, something to keep in mind is the human desire to track absolutely everything. If you fall into this trap, you risk having so much data that it becomes hard to extract the meaningful pieces of the data that drive impact.
What to include in a tracking plan
It's helpful to note there's no one right way to fill out a tracking plan.
You can define the triggers, events, and properties you want to track, and that could be it. If you have the technical experience, you could also fill in implementation considerations.
The great thing about a tracking plan is it provides a central place for you to have a constructive conversation with your technical team, even if you're not very technical.
So, what should be included in a tracking plan? These could be good default values:
Event Name: The name of the event to trigger
Related business goal: What KPI/Goal is associated with that event
Trigger: When the event should be triggered
Event Definition: A description of the event
Property list: with name, type, and definition
Sample Values: One of the most important fields: it can solve many discussions or misunderstandings
Implemented?: A simple true/false field
Notes
A simple spreadsheet can get you a long way before you need something else, so I would advise starting with that.
If you don’t want to start from scratch, Mixpanel and Segment have great templates you can use.
Conclusion
A good tracking plan is a stepping stone for a successful product analytics strategy.
Linking your events to your business goals will help you focus on the correct data to track and will avoid many headaches during analysis 😅
In the following article of this mini-series, we will see how to get insights from a correctly implemented tracking plan, looking at some examples using Mixpanel.
If you enjoyed this article, please share it on Linkedin or Twitter and let us know your feedback at hello@donux.com.
Welcome to the second episode of our mini-series about Product Analytics.
In our last article, we started defining our business goals; today, we’ll see how to create a tracking plan and prepare for the actual implementation.
As a product analytics manager, you are responsible for ensuring that the correct data is collected and tracked to gain actionable insights into how your product is being used. To do this, you need to create a tracking plan that outlines what data needs to be collected and how it should be tracked.
What is a tracking plan?
A product analytics tracking plan (or simply a tracking plan) is a document that helps you map your business goals to specific events and properties that you want to track. Collecting and analyzing data from these events and properties will help answer questions about your business goals.
Your implementation plan is also a map for your developers when they implement a product analytics platform.
Why create a tracking plan at all?
There are so many things that you could track. If you track everything without knowing upfront the types of questions you want to be able to answer, you're going to end up with a lot of data and no idea of what to do with it.
A tracking plan helps you understand your business's goals, questions and answers and focus on collecting the data that will help you understand your business’s progression.
A living document
A tracking plan starts with the business goals you defined in the previous step (check out our article "Getting started with product analytics: define business goals").
For each goal, note down the key questions you want to understand about your product and the user behavior in your product.
Then, identify the user flows or behavior patterns that will help you answer each question.
Finally, pinpoint the specific events and their related properties that map to those flows.
Like many other product-related assets, the tracking plan is a living document that will evolve over time. It will start as a tracking plan you create upfront, which your developer can implement.
However, as you make changes to your product, the tracking plan will need to be amended and updated with new events and properties that become important.
Some examples of changes to the product can include:
flows being altered within the product,
revisions being made to key behaviors that are being driven through the product,
new features being launched.
How to create a tracking plan
Let's see how we could approach a hypothetical project management app tracking plan.
Imagine that our goal is to have more active users in the app.
Our first objective should be to identify the key activity that will accurately indicate that we are helping our users achieve this goal. In this case, we might assume that if a user invites another user, they get value out of the product. For this reason we could decide to track an event called "Member Invited".
However, this is not enough! We also need to track what the user does before they invite someone (to optimize that funnel) and what the user does afterward (to ensure they continue to get value from the product). Therefore, we should add two other events to our "Member Invited" event: "Account created" and "Workspace configured".
These are the three key events we'll track in our flow.
Tracking events allows you to understand why people are more or less successful at completing each step. For example, if you find out that users who have a hard time configuring their workspaces are also less likely to invite someone, it might be worth thinking about how to optimize the “configure your workspace” experience.
We would have this situation:
Goal: Have more active users
User flow: Account created -> Workspace configured -> Member invited
Events
Account created
Workspace configured
Member invited
Now for each of the events we have listed here, we have multiple properties that we want to track. These properties provide details about the event that might give you insight when doing your analysis later.
This would bring us to this:
Goal: Have more active users
User flow: Account created -> Workspace configured -> Member invited
Events
Account created
Property 1: plan | Example Value: (trial, premium)
Property 2: company_id | Example Value: (12342)Workspace configured
Property 1: company_id | Example Values: (12342)
Property 2: onboarding_variant | Example Values: (Test A, Test B, Control)
Property 3: plan | Example Values: (trial, premium)Member invited
Property 1: invite_method | Example Values: (Email, Url, QR Code)
When defining properties, something to keep in mind is the human desire to track absolutely everything. If you fall into this trap, you risk having so much data that it becomes hard to extract the meaningful pieces of the data that drive impact.
What to include in a tracking plan
It's helpful to note there's no one right way to fill out a tracking plan.
You can define the triggers, events, and properties you want to track, and that could be it. If you have the technical experience, you could also fill in implementation considerations.
The great thing about a tracking plan is it provides a central place for you to have a constructive conversation with your technical team, even if you're not very technical.
So, what should be included in a tracking plan? These could be good default values:
Event Name: The name of the event to trigger
Related business goal: What KPI/Goal is associated with that event
Trigger: When the event should be triggered
Event Definition: A description of the event
Property list: with name, type, and definition
Sample Values: One of the most important fields: it can solve many discussions or misunderstandings
Implemented?: A simple true/false field
Notes
A simple spreadsheet can get you a long way before you need something else, so I would advise starting with that.
If you don’t want to start from scratch, Mixpanel and Segment have great templates you can use.
Conclusion
A good tracking plan is a stepping stone for a successful product analytics strategy.
Linking your events to your business goals will help you focus on the correct data to track and will avoid many headaches during analysis 😅
In the following article of this mini-series, we will see how to get insights from a correctly implemented tracking plan, looking at some examples using Mixpanel.
If you enjoyed this article, please share it on Linkedin or Twitter and let us know your feedback at hello@donux.com.
Welcome to the second episode of our mini-series about Product Analytics.
In our last article, we started defining our business goals; today, we’ll see how to create a tracking plan and prepare for the actual implementation.
As a product analytics manager, you are responsible for ensuring that the correct data is collected and tracked to gain actionable insights into how your product is being used. To do this, you need to create a tracking plan that outlines what data needs to be collected and how it should be tracked.
What is a tracking plan?
A product analytics tracking plan (or simply a tracking plan) is a document that helps you map your business goals to specific events and properties that you want to track. Collecting and analyzing data from these events and properties will help answer questions about your business goals.
Your implementation plan is also a map for your developers when they implement a product analytics platform.
Why create a tracking plan at all?
There are so many things that you could track. If you track everything without knowing upfront the types of questions you want to be able to answer, you're going to end up with a lot of data and no idea of what to do with it.
A tracking plan helps you understand your business's goals, questions and answers and focus on collecting the data that will help you understand your business’s progression.
A living document
A tracking plan starts with the business goals you defined in the previous step (check out our article "Getting started with product analytics: define business goals").
For each goal, note down the key questions you want to understand about your product and the user behavior in your product.
Then, identify the user flows or behavior patterns that will help you answer each question.
Finally, pinpoint the specific events and their related properties that map to those flows.
Like many other product-related assets, the tracking plan is a living document that will evolve over time. It will start as a tracking plan you create upfront, which your developer can implement.
However, as you make changes to your product, the tracking plan will need to be amended and updated with new events and properties that become important.
Some examples of changes to the product can include:
flows being altered within the product,
revisions being made to key behaviors that are being driven through the product,
new features being launched.
How to create a tracking plan
Let's see how we could approach a hypothetical project management app tracking plan.
Imagine that our goal is to have more active users in the app.
Our first objective should be to identify the key activity that will accurately indicate that we are helping our users achieve this goal. In this case, we might assume that if a user invites another user, they get value out of the product. For this reason we could decide to track an event called "Member Invited".
However, this is not enough! We also need to track what the user does before they invite someone (to optimize that funnel) and what the user does afterward (to ensure they continue to get value from the product). Therefore, we should add two other events to our "Member Invited" event: "Account created" and "Workspace configured".
These are the three key events we'll track in our flow.
Tracking events allows you to understand why people are more or less successful at completing each step. For example, if you find out that users who have a hard time configuring their workspaces are also less likely to invite someone, it might be worth thinking about how to optimize the “configure your workspace” experience.
We would have this situation:
Goal: Have more active users
User flow: Account created -> Workspace configured -> Member invited
Events
Account created
Workspace configured
Member invited
Now for each of the events we have listed here, we have multiple properties that we want to track. These properties provide details about the event that might give you insight when doing your analysis later.
This would bring us to this:
Goal: Have more active users
User flow: Account created -> Workspace configured -> Member invited
Events
Account created
Property 1: plan | Example Value: (trial, premium)
Property 2: company_id | Example Value: (12342)Workspace configured
Property 1: company_id | Example Values: (12342)
Property 2: onboarding_variant | Example Values: (Test A, Test B, Control)
Property 3: plan | Example Values: (trial, premium)Member invited
Property 1: invite_method | Example Values: (Email, Url, QR Code)
When defining properties, something to keep in mind is the human desire to track absolutely everything. If you fall into this trap, you risk having so much data that it becomes hard to extract the meaningful pieces of the data that drive impact.
What to include in a tracking plan
It's helpful to note there's no one right way to fill out a tracking plan.
You can define the triggers, events, and properties you want to track, and that could be it. If you have the technical experience, you could also fill in implementation considerations.
The great thing about a tracking plan is it provides a central place for you to have a constructive conversation with your technical team, even if you're not very technical.
So, what should be included in a tracking plan? These could be good default values:
Event Name: The name of the event to trigger
Related business goal: What KPI/Goal is associated with that event
Trigger: When the event should be triggered
Event Definition: A description of the event
Property list: with name, type, and definition
Sample Values: One of the most important fields: it can solve many discussions or misunderstandings
Implemented?: A simple true/false field
Notes
A simple spreadsheet can get you a long way before you need something else, so I would advise starting with that.
If you don’t want to start from scratch, Mixpanel and Segment have great templates you can use.
Conclusion
A good tracking plan is a stepping stone for a successful product analytics strategy.
Linking your events to your business goals will help you focus on the correct data to track and will avoid many headaches during analysis 😅
In the following article of this mini-series, we will see how to get insights from a correctly implemented tracking plan, looking at some examples using Mixpanel.
If you enjoyed this article, please share it on Linkedin or Twitter and let us know your feedback at hello@donux.com.
Welcome to the second episode of our mini-series about Product Analytics.
In our last article, we started defining our business goals; today, we’ll see how to create a tracking plan and prepare for the actual implementation.
As a product analytics manager, you are responsible for ensuring that the correct data is collected and tracked to gain actionable insights into how your product is being used. To do this, you need to create a tracking plan that outlines what data needs to be collected and how it should be tracked.
What is a tracking plan?
A product analytics tracking plan (or simply a tracking plan) is a document that helps you map your business goals to specific events and properties that you want to track. Collecting and analyzing data from these events and properties will help answer questions about your business goals.
Your implementation plan is also a map for your developers when they implement a product analytics platform.
Why create a tracking plan at all?
There are so many things that you could track. If you track everything without knowing upfront the types of questions you want to be able to answer, you're going to end up with a lot of data and no idea of what to do with it.
A tracking plan helps you understand your business's goals, questions and answers and focus on collecting the data that will help you understand your business’s progression.
A living document
A tracking plan starts with the business goals you defined in the previous step (check out our article "Getting started with product analytics: define business goals").
For each goal, note down the key questions you want to understand about your product and the user behavior in your product.
Then, identify the user flows or behavior patterns that will help you answer each question.
Finally, pinpoint the specific events and their related properties that map to those flows.
Like many other product-related assets, the tracking plan is a living document that will evolve over time. It will start as a tracking plan you create upfront, which your developer can implement.
However, as you make changes to your product, the tracking plan will need to be amended and updated with new events and properties that become important.
Some examples of changes to the product can include:
flows being altered within the product,
revisions being made to key behaviors that are being driven through the product,
new features being launched.
How to create a tracking plan
Let's see how we could approach a hypothetical project management app tracking plan.
Imagine that our goal is to have more active users in the app.
Our first objective should be to identify the key activity that will accurately indicate that we are helping our users achieve this goal. In this case, we might assume that if a user invites another user, they get value out of the product. For this reason we could decide to track an event called "Member Invited".
However, this is not enough! We also need to track what the user does before they invite someone (to optimize that funnel) and what the user does afterward (to ensure they continue to get value from the product). Therefore, we should add two other events to our "Member Invited" event: "Account created" and "Workspace configured".
These are the three key events we'll track in our flow.
Tracking events allows you to understand why people are more or less successful at completing each step. For example, if you find out that users who have a hard time configuring their workspaces are also less likely to invite someone, it might be worth thinking about how to optimize the “configure your workspace” experience.
We would have this situation:
Goal: Have more active users
User flow: Account created -> Workspace configured -> Member invited
Events
Account created
Workspace configured
Member invited
Now for each of the events we have listed here, we have multiple properties that we want to track. These properties provide details about the event that might give you insight when doing your analysis later.
This would bring us to this:
Goal: Have more active users
User flow: Account created -> Workspace configured -> Member invited
Events
Account created
Property 1: plan | Example Value: (trial, premium)
Property 2: company_id | Example Value: (12342)Workspace configured
Property 1: company_id | Example Values: (12342)
Property 2: onboarding_variant | Example Values: (Test A, Test B, Control)
Property 3: plan | Example Values: (trial, premium)Member invited
Property 1: invite_method | Example Values: (Email, Url, QR Code)
When defining properties, something to keep in mind is the human desire to track absolutely everything. If you fall into this trap, you risk having so much data that it becomes hard to extract the meaningful pieces of the data that drive impact.
What to include in a tracking plan
It's helpful to note there's no one right way to fill out a tracking plan.
You can define the triggers, events, and properties you want to track, and that could be it. If you have the technical experience, you could also fill in implementation considerations.
The great thing about a tracking plan is it provides a central place for you to have a constructive conversation with your technical team, even if you're not very technical.
So, what should be included in a tracking plan? These could be good default values:
Event Name: The name of the event to trigger
Related business goal: What KPI/Goal is associated with that event
Trigger: When the event should be triggered
Event Definition: A description of the event
Property list: with name, type, and definition
Sample Values: One of the most important fields: it can solve many discussions or misunderstandings
Implemented?: A simple true/false field
Notes
A simple spreadsheet can get you a long way before you need something else, so I would advise starting with that.
If you don’t want to start from scratch, Mixpanel and Segment have great templates you can use.
Conclusion
A good tracking plan is a stepping stone for a successful product analytics strategy.
Linking your events to your business goals will help you focus on the correct data to track and will avoid many headaches during analysis 😅
In the following article of this mini-series, we will see how to get insights from a correctly implemented tracking plan, looking at some examples using Mixpanel.
If you enjoyed this article, please share it on Linkedin or Twitter and let us know your feedback at hello@donux.com.
Subscribe to our product design newsletter
We'll be sending two emails every month with product and design tips for B2B SaaS
By submitting this form, I accept the Privacy Policy
By submitting this form, I accept the Privacy Policy
Product
Industries
Product
Industries