As the need for tracking plans continues to grow, so does the need for best practices. We recently interviewed teams who work with tracking plans, to discuss the life of a tracking plan in their organization.

A strong tracking plan will be used to guide event-based analytics projects, and should be the starting point for any additions or changes to event tracking. Let's look at lifecycle of an analytics project where a tracking plan is successfully used.

Establishing a Tracking Plan

If you don't already have one, your first step is to set up a tracking plan for your project. If you're new to tracking plans, head over to What is a Tracking Plan?

Whether you use a spreadsheet or a product like Trackplan is up to you. At a high level, your tracking plan is going to help you list all the events you plan to track, and everything you want to know about them. As your project grows, the number of events you track will likely grow too.

New Requirements

Different teams have different requirements for event-based data, and with the growing number of SaaS tools that rely on this data, we move from the wolrd of nice-to-have to required.

For example, your design team might want to track Call to Actions, your product team may want to track feature usage for product analysis, and your marketing team may want to track user behaviour to automate marketing communication. Not having a single source of truth is the first downfall here, but it doesn't have to be that way!

With a tracking plan, the first step is collecting these requirements and understanding exactly why these events are required. This will help build a business case for this event addition/change. We strongly advise against the "lets just track everything" approach.

Let's say our product team have requested that we track when a user completes the checkout process, so they can build a funnel to understand their conversion rate. We will introduce a new event to track this.


Now that we understand the requirements, we can add an event to our tracking plan and begin planning exactly what this will look like. Things we need to consider are: naming convention, properties (things that provide additional context to the event) and the sources where we will track this event.

Trackplan event

At Trackplan, we recommend using the Object-Action naming convention, which has been standardized by popular analytics companies like Segment. This will provide consistency for our event names, and make our project easier to manage.

For our checkout example, we would add an event called "Checkout Completed", following this naming convetion.


With planning complete, it is now time to hand over the event spec to the person or team responsible for implementing the tracking code. If you have an iOS, Android and Web project, then this could easily be three different people/teams.

This is where the single source of truth your tracking plan brings is absolutely crucuial. Countless time can be lost when communication and requirements are not clear enough for the teams implementing the tracking code.

By sharing the tracking plan with your respective teams, you give them a clear blueprint for what is required. The naming conventions, the data types, the number of properties, etc...


Once development begins, you should mark your events so you know what events are being implemented. For example, you may be planning new events while others are already being added by your team, and this will help you manage the lifecycle of your events.

Example event tracking code

Your tracking code will differ depending on the tracking tool you use, and the source you are tracking in. Your development team will be familiar with the particular SDK or library, and using your tracking plan will be able to implement exactly what is required.


Testing is the crucial step where you reference your tracking plan, and compare this with the events you now see being tracked by your tool of choice. Ideally this will be done in a staging environment, so as not to muddy your production data.

Here you will want to confirm if the event name is correct, all properties are present, and that their data types are correct. e.g. ensure that a number value is not being tracked as a string.

Events in Trackplan

Final Thoughts

By implementing a successful tracking plan, you introduce a single source of truth, provide clarity on requirements, business objectives and can help you manage your growing analytics projects.

If new event tracking additions or changes begin with your tracking plan, you are setting yourself up for success, and saving yourself headaches with bad data.