Here's the thing about: How to Create a Tracking Plan
A tracking plan is one of the blueprints in your data strategy that will help reduce the chances of data redundancy, inaccuracy, and disorganization.
By the end of this article, you will learn:
WHY you need a tracking plan
HOW to decide what to put in your tracking plan
WHAT a tracking plan looks like
The thing is:
You need a Data Tracking Plan
Right off the bat, I know that most of you here are likely to be a marketer who stumbled upon another one of my rants about the iMpOrTaNcE of Data. 🥴
But, hear me out: You do need to spend a bit of time understanding WHY you should familiarize yourself with a tracking plan, especially as a marketer.
Imagine a scenario where you have a brilliant idea to help drive the adoption of a new feature your company is launching. You have partnered up with your onboarding PM (the folks responsible for creating a journey that will walk users through the onboarding process during registration).
Your PM shows you the onboarding flow and the very first question asked of a new registrant is, “Which feature are you most excited about?”
“Creating a template with a drag & drop builder”
“Creating a collection of templates & categorizing them”
“Sending bulk template tests to your seedlist”
The app’s newest feature is the bulk template Q/A feature. So you suggest “let’s send an in-app message to users who selected ‘Sending bulk template tests to your seedlist’, to begin guiding them through the steps to sending their first test as soon as they’ve completed registration.
How will you trigger this campaign? My first thought immediately goes to: Is there a tracking plan for this initiative? If so, I can form a strategy around already tracked activities.
Tracking plans serves the following purposes:
Ascertains goals and hypotheses related to a business problem, idea, or other opportunities
Summarizes the users, events, and properties that will be tracked
Explains why these events matter to the hypotheses and why they’re useful to track
Details the tools and engineering required to support the tracking plan
Informs all relevant stakeholders via a single source of truth
A tracking plan is not a static document. You will update your plan each time you change the entity or event data, revise the name of an event, change the properties or data types, and when you stop tracking the event entirely.
A tracking plan will typically be utilized by three main stakeholders, which are your Marketers, Product Managers, and Data Engineers. However, they are not the only ones involved in making decisions around the data tracking plan.
As you get ready to go live with a product or feature, you will want to have a plan for how you will gather the user data once it’s available. This tracking documentation should tell the reader 3 things:
What is this data called?
Where is this data located?
Why did we collect this data?
With centralized tracking plans in place for each feature and product, your marketers will gain a deeper understanding of your customers, which will help them craft an improved marketing strategy via enhanced personalized customer communication and journey. Your product managers will also gain a much more accurate customer database that will allow them to optimize the product according to the customer data they learned.
Before you create a tracking plan, the first thing you need to do is decide what it is that you want to track.
The other thing is:
You need to know The Questions you want answered
There are generally 5-7 stages in your customer lifecycle. Depending on the business or service, you can make your stages even more granular. For this example, let’s say that my business, an email marketing template subscription website, has 5 stages, and they are:
Awareness
Acquisition
Conversion
Retention
Loyalty
My role in recent years has been in growth, monetization, and demand generation, so naturally, my focus lies within the acquisition and conversion stages of the customer lifecycle.
For this example, I want to know the answers to a few questions:
How many sessions does a user have during their trial period of 30 days?
Does the user interact with the “create a new template” feature within the first session?
Does a paid subscriber use a particular feature more than those on the free plan?
To create a tracking plan that will help me answer these questions, I need to visualize all the steps a customer will take from app installation, activities within the first 30 days and identify the conversion point when they become a paid subscriber. Here are some examples of each step:
App installed:
The user installs the app on their device.
Intro landing screen:
The user opens the app up for the first time and lands on the intro screen.
Signup selected:
The user selects a signup method, using social media or email authentication.
Details confirmed:
The user reviews their name and email address, then selects submit.
Account created:
The user selects “Create an account.”
Create a new email template:
The user selects “Create a new email template.”
Save a new template:
The user select “Save template.”
Edit user profile:
The user selects “Edit account details.”
Create a template category folder:
The user select “Create a new category.”
Subscribe to a paid plan:
The user selects “Upgrade to Pro”
Payment information collected:
The user selects “Save payment information.”
Now we have a pretty good idea of what questions we need answers to and what kind of actions we need to track to help us answer those questions.
Next, we will create our first tracking plan.
The last thing I will mention today:
You need to know the essential components of a Tracking Plan
If you’ve never created a tracking plan before, the default advice is to start with a spreadsheet so let’s do that. A basic tracking plan usually has columns for these values:
Event name: Any meaningful action a user takes within your product.
Event definition: Description of the Event being performed (for any given end user to understand)
Event property types: Attributes associated with the event, relevant either to the context of the event itself or the user triggering it
Event property vs User property
User properties are the attributes of individual users. Attributes such as Email address, Platform, Device type, Country, City, OS, Language, IP address, etc.
Event properties are attributes of the particular event. These properties contain values that are contextual to the event that was triggered. For example, the event “Account Created” could have an event could have event properties of “email_address, authentication_type, organization_id.”
Event properties: Descriptive key-value pairs associated with the Event, either describing the Event itself or the user performing that Event
Event property data type: String, Boolean, Date, List, Numeric, Incremental.
Sample values: A sample value of the event when triggered.
Platform: How is this event triggered? Client-side or Server-side?
In a table you can create in Google sheet, your tracking plan could look something like this:
With this tracking plan, your marketers, product managers and data engineers can refer to a single source of truth for all events associated with your feature or workflow.
You can further organize your table into “Categories” as well. For example, you can section your tables into Payment related events, Account related events, Subscription related events and so on.
What we’ve covered today is a free, low barrier to entry version of a tracking plan. As you evolve your analytics stack you should consider more robust solutions such as a Confluence template that gives ready-to-use structure or investing in a tool like Avo, which is purpose built for tracking planning.
I know this is a lot to digest and you likely won’t have to ever make one from scratch but I hope that you now have a better idea of what a tracking plan looks like and what kind of information will be useful to you.
Next week I’ll step away from data chat for a bit and talk about the tea in the world of Marketing Operations.
Until then, tell me what is a 🚩for you in the marketing operations process?
Jello