We talked in depth about why you need a tracking plan in our definitive guide to tracking plans; now, we’ll break down the awesome tracking plan template we created for you, so you’re ready to implement better product analytics via your tool of choice (possibly Avo 😉).

But before we dive in, here’s a quick refresher on what a tracking plan is (you may recognize this from our definitive guide to tracking plans):

A tracking plan is a document that defines the key stages of your customer life cycle and codifies a single source of truth for the data that supports it. It helps you standardize your data management and capture better and cleaner data.

As part of your tracking plan, you’ll need to outline the events and properties relevant to your goals, explain where in your codebase tracking code should be placed, and provide context for why you’re tracking what you are.

While each of the elements of your tracking plan will be as unique to your business as your product is to your market, you can save admin time up front by using a tracking plan template. There are dozens floating around the internet, so we went ahead and created our 🎉Ultimate Tracking Plan Template 🎉 that pulls together the 10 elements you absolutely must have. Use this template to spend less time researching how to make your tracking plan and more time using it.

What makes a good tracking plan?

Your tracking plan should include events and properties that help you understand your customers’ behavior and measure progress through your sales funnel and customer journeys so you can see how well your features are meeting customer needs. It shouldn’t aim to measure every drop of data under the sun—just those that are most important to you.

For the full breakdown of how to find the events and properties that mirror your customer journey, check out our full guide on tracking plans, and then meet us back here.

To get a full picture of your customers’ behaviors and experiences, you’ll need a mix of both qualitative metrics (the kind that reflect user sentiment) and quantitative metrics (the kind that reflect user actions).

Your tracking plan will focus on quantitative metrics. That's because it's possible to objectively measure whether an action happened. But it’s equally important that your sales and product teams reach out to customers and users via surveys, social media, and reviews to get qualitative data to complement your tracking plan.

The 10 key elements of your tracking plan

We have a lot of experience helping folks build killer tracking plans (and we’ve seen a lot of great examples of tracking plans from other companies, too). When we sat down and pulled from our experience—and the experiences of others—we noticed there were 10 key elements that every great tracking plan included.

Please go ahead and make a copy of the template here.

1. KPIs

‍

Each event you track should tie directly to a business-end key performance indicator (KPIs) that affects your success, so you can easily reference the tie-in between metrics tracked and their real-world value.

These KPIs will change depending on your company maturity, product, and business strategy, but here are some examples:

• Signup funnel 
• Retention from signup to playing game 
• Monthly new signups 

This first section is what will give any business-end stakeholders the context they need to understand how the tracking plan ties into a wider strategy.

2. Event categories

‍

Your tracking plan should break down events tracked by macro category—typically reflecting the different kinds of KPIs you’ve set—so you can keep track of each segment of customer success.

Like all things on this list, the kinds of events you’ll track will depend on your goals and use case, but here are a few examples:

• Authentication 
• Gameplay
• Tournaments 
• Navigation

Once you’ve set the broad categories of events you care about, you can drill down and decide on the specific events and properties within each category.

3. Event names

‍

Your tracking plan should include one row for each event name (each of which will have rows for child properties). Additionally, each of your events should be named in a consistent way that’s in line with your agreed-on naming schema. This structure makes it easy for anyone to quickly scan and understand what events you’re tracking.

Your event names will depend on the kinds of events you’re tracking and on your naming schema. Within the categories we outlined above, some possible event names could include the following:

• Signup Started 
• Signup Completed 
• Login Completed 
• Game Started 
• Game Completed 

Note how each of these event names shares the same tense (past tense) and capitalization. This isn’t just to make your template look pretty; it makes everything easier to understand.

4. Event description

‍

Your tracking plan should include a clear description for each event, including the event source (where the action is taking place) and any additional context of when and why the event happens. That makes it easy for anyone looking at your template to quickly understand what the event is tracking.

Your event descriptions should be no longer than one or two sentences and should clearly and concisely explain what it is you’re measuring (and when). Let’s assume that we’re measuring the event “Game Completed.” Our description for this event might be:

Event sent when a user has successfully completed a game. 

Creating consistent descriptions for each of your events will make it easy for anyone using your tracking plan to gain the context they need to interpret your data.

5. Properties

‍

For each event, you should include a full breakdown of its attached properties, with one row per property—again, all named consistently—so you can easily see which properties are being tracked for a given customer action.

Bonus: You should also define your property groups (these can be spaced across event groups) so you can easily see what kind of user behaviors you’re tracking.

It can be easy to let naming conventions for properties slide, but ensuring that each property follows your schema will prevent data collection and compilation errors down the road. Let’s say we’re measuring gameplay events, particularly the “Game Completed” event we identified above. We might track the following properties:

• Game Mode 
• Game Count 

Each of these properties will tell us whether or not a specific user action was completed (e.g., “Game Mode” tells us the mode of the game the user played and “Game Count” tells us how many games the user has completed).  

6. Property description

‍

Your tracking plan should include a clear description for each property so that any user can understand what the property is tracking and where the data is coming from.

Just like your event descriptions, your property descriptions should fill a column to the right of your property names and clearly and concisely describe what each property measures.

For example, if we’re tracking how many games players complete during their session, we may track a property called “Game Count”. Our description of this property might look something like this:

The number of games a player has completed when this event is sent. Including the game that was just completed on Game Completed. 

This extra context will help anyone looking at your tracking plan make sense of all your properties.

7. Property value types

‍

Each property within your tracking plan will collect a different data type. These types should be explicitly laid out so developers implement across codepaths and platforms consistently. This also helps your data analysts know what to expect from the tracking analytics code output. 

This is one of the few sections of your tracking plan that will not greatly vary. Instead, the data in this column should include these common data types:

• int
• floating-point number
• boolean
• string
• datetime
• a list of any of the data types above 

When you formally identify these data types for each of your events and properties, you help your developers avoid coding errors that will impact data compilation down the line.

8. Platforms

‍

For each property, you should note what platform the data is coming from so you can keep track of which applications contribute what information to your dataset.

This will depend on the development platforms you use and how your codebase is structured. But here’s a general outline of some of the platforms you may need to think about:

• For web: JavaScript, TypeScript or Reason
• For mobile (generally): React Native or Expo or Flutter for iOS and Android apps
• For mobile (Android): Java or Kotlin 
• For mobile (iOS):Swift or Objective C 
• For backend: one or more backend sources (depending on number of programming languages and micro services) 
• For game engines: Unity

Including this breakdown of platforms that contribute data to your app will ensure that developers know where to implement tracking analytics across the board, and you won’t forget about any key components of your product.

9. Status

‍

This is a really important one: Your tracking plan must indicate the status of each step of tracking analytics implementation. This ensures that your team--and your tracking plan stakeholders--have a clear understanding of what work has been completed, what needs review, and what is in testing. 

For example, let’s say you’re tracking events and properties related to your login authentication method. You’ll need to note when that analytics code is ready for review and testing so your developers know that it’s not ready to ship, and don’t prematurely launch what could be a buggy bit of code. 

10. Code snippet

‍

Finally, your tracking plan should include your tracking code for each event and property that needs to be tracked so that your developers can easily place it into the correct spot without naming-convention or syntax errors.

If you’re doing this manually with a spreadsheet alone—instead of using a tool, like Avo, that can house your implementation code and send it directly to developers—this section can get a little lengthy.

By explicitly giving the code for each property, you reduce the likelihood of implementation errors and make the lives of your developers easier in the process! 🎉

Download Our Ultimate Tracking Plan Template

There’s a lot of thought that goes into creating a great tracking plan. You need to dive deep into your users’ behaviours and attitudes to measure the metrics that reflect your progress toward KPIs. Even with this awesome tracking plan, doing this manually is a bear.

‍

Download the Tracking Plan here

Once you’ve created your tracking plan using this template, head on over to our site to see a demo of how you can use Avo to convert your plan into an easy-to-manage and easy-to-share single source of data truth (Bonus: we can also import your tracking plan directly when you use the DLC above).