How Do You Create a Data Tracking Plan?

James Phoenix

Data tracking plans are the blueprint of successful data strategies.

They act as the strategy song sheet – the single source of truth that informs all collaborators of what data is being tracked, how and for what purpose.

Front-loading the planning aspect of a data strategy is typical of customer, marketing and product teams who are looking to leverage customer data to improve business outcomes. The more planning that goes in, the better the results that come out. The data tracking plan is a pivotal part of the planning stage.

Tracking plans form living documents that can be updated with all relevant information relating to your data strategy.

This is a guide to creating a data tracking plan.

Let’s go!

What is Data Tracking?

Data tracking is the overall process of identifying, collecting and organising or categorising data points.

Data is tracked – or followed – as it’s created and/or changes via interaction by individuals or other components within the pipeline. Data tracking applies to both hardware and software and is the act of retrieving information about a state or process.

What is a Data Tracking Plan?

Data tracking identifies data relevant to a plan or strategy.

In a commercial scenario, a data tracking plan might identify what data points a business needs to measure strategies aimed at lowering customer churn, or increasing customer acquisition, etc. Most data points revolve around users or accounts – those who interact with the business or other system in question – and events – which record their interaction with that business or other system.

The goal of a data tracking plan is to create a single ‘source of truth’ for a data tracking project.

Tracking plans should do the following:

Ascertains goals and hypotheses relating to a business problem, idea or other opportunity
Summarise 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 tracking plan stored as a spreadsheet or company wiki

What’s The Reason For A Tracking Plan?

Tracking plans are not static and undergo constant modification and replenishment each time any of the following occurs:

Changing/gathering data on a new event, entity or event property
Modifying the names or other identifiers of an event
Modify names of data types and properties
Start or stop tracking an event or property

Read up about the differences between entity and event data in a business data context here.

Tracking plans should be seen as fundamental – a reference point for the entire tracking process. As such, any data not contained within the tracking plan shouldn’t be tracked.

Tracking plans help organise the process itself, help reduce the chances of:

Data redundancy, where data is gathered multiple times and made redundant
Data inaccuracy, where data is incorrect, missing or improperly formatted
Messy data, a combination of the two

Implementation

Launching a tracking plan involves continuous work – it doesn’t just start and stop. New tasks will need to be iterated out on a regular basis. Tracking plans help maintain a fundamental source of truth as a data strategy develops over time, specifying where data comes from (sources) and where it’s sent to (destinations). It also acts as a worksheet to equip different teams with the guidance they need to use tracked data and build products such as recommendations engines, remarketing, segmented notifications or emails, or targeted ads.

An example is a product team analysing the sales funnel. Tracked events will be used to create and modify sales funnels, but that same data might be used by the email marketing team which uses segmentation based on the same events and users tracked already by the product team.

Democratisation

Data tracking plans assist in data democratisation, the process of making data available to the teams that need them outside of a strict data-oriented profession or job role. Tracking plans allow teams and individuals to assess what data is being tracked and by what tools, allowing them to utilise any relevant platforms and databases for their own means.

Additionally, data tracking plans enable the swift transfer of knowledge between teams and individuals which is of particular importance for new employee onboarding, or when a task needs to change hands in some way.

Building a Tracking Plan

Tracking plans differ on their exact aims, but this basic tracking plan made available as a free Google Sheet by Segment offers an excellent foundation for most fairly routine tracking purposes.

Below is an example tracking plan for a game ‘bejewelled’.

Most tracking plans start with a list of questions that demand answers that data can, in theory, provide. It might often be a case of focussing on one stage of the typical funnel (e.g discovery and awareness through to acquisition, activation, conversion and retention).

Questions should be specific and angled towards one particular stage of a customer’s journey, for example:

Acquisition: What channels acquire the most new users?
Activation: Where do users stop when failing to convert with a product?
Conversions: What product pages succeed in converting the most customers?
Retention: When do customers leave the business?

These basic questions already provide ideas of metrics that can be tracked to locate answers. They’ll also likely lead to more neighbouring questions that can build out a wider understanding of this part of the funnel, e.g:

What is our average customer lifetime value (CLV)?
Do A vs B types of social media posts increase acquisition?
Does A vs B product page increase conversions?

Any discrepancies or unobvious elements in the logic of your tracking plan should be noted. One question should clearly lead to another and should be ultimately fairly easy to break down into the events that need to be tracked.

Key events include everything from taps and swipes to products added to carts, checkout completed, invite sent, post shared, etc, etc. Events provide the answers to your lists of questions. This is how the tracking plan builds itself – one question leads to another which leads to a useful event to track, and so on and so forth.

It’s best to keep things simple wherever possible, which means not adding stacks of events, nor trying to tackle multiple stages of the funnel in one go. For example, if you want to measure a user’s journey from brand discovery to conversion then this will take possibly hundreds or thousands of events to properly describe if your business uses multiple channels. Instead, keep things chronological, narrow and to the point.

For example, if you want to test which Instagram ad yielded the most subscribers to your newsletter then you’ll need to measure the two events of users clicking on those ads and the event of them subscribing to the newsletter, providing you with two comparable datasets broken down with user demographic data for comprehensive A/B comparison. UTM parameters would provide a robust means of tracking that upstream data for downstream analysis and comparison.

Another example of a simple two-event tracking plan is the question “what percentage of recent users went on to create a project with our product?” (which is of course angled at activation and onboarding). To create a project (the activation event), a user will have already performed the signup event, which will need a cut-off to indicate that user is a new user (e.g. they signed up in the last 7 days). There are just two events here; signing up and creating a new project. The timestamp used to identify the user as being a ‘new user’ is a property of the signup event.

Event Properties

Properties provide information and context to events. A signup event will typically have a timestamp and a generated user ID at the very least, but will usually also have properties for all pieces of user data, e.g. first names, last names, email addresses, age, gender, etc.

This really depends on what data is being asked – it might be comprehensive or it might be very minimalist. Other events like ‘project created’ from our above example will have the user ID(s) that created the project, timestamps and project IDs at the very least.

User Properties

User properties store details about users, demographics, traits, etc. This greatly aids in segmentation and can also help you formulate additional questions to understand trends in your users. In the case of a sign-up, the event properties (the action of inserting data like names, addresses, etc) are the same as the user properties.

User properties should also include any customer feedback, surveys, customer service information or other information specifically relevant to that user.

It’s worth noting that user properties might combine with organisation properties (e.g. in B2B products). Users might be part of organisations, which necessitates the need for organisation properties that apply to the entire organisation.

Tracking plans provide data to either CDPs or CDIs like Segment, mParticle, Rudder and Hull, or a product analytics tools, such as Mixpanel, Heap or Amplitude, or perhaps a customer engagement tool, like Intercom, Userflow or Customer.io.

But, the first step is to create a tracking plan with relevant events that help answer questions. Tracking plans should be realistic, attainable and focussed on specific problems as opposed to painting with a broad brush and trying to fix all problems at once.

Data Types

Each event or user property should be tallied up with its expected data type – read our article on those here. This will greatly assist in providing consistency and transparency to the tracking plan, even if writing up what data type is expected for what event feels elementary (e.g. a timestamp is obviously a timestamp, right?)

Read up more about data types and their importance here.

But what about arrays where only a specific list of values can be chosen? The tracking plan should make reference to this list of expected values (e.g. a dropdown selection box that asks “where did you hear about us?” or a list of countries that indicates someone’s location).

Mention the Destinations

All of this data has to go somewhere, whether that’s analytics platforms, product tools, CDPs and segmentation tools, email marketing tools, recommendations engines or just databases. The destinations should be noted on the tracking plan, as should be any due diligence or regulatory compliance attached to the data (e.g. in the case of PII – personally identifiable information).

Client-Side and Server-Side

A signup event is usually a client-side event (i.e. it takes place on the client device) and is logged as soon as someone uses a form to sign-up to something successfully. However, in the above example, the creation of a project might be a server-side event (i.e. it relies on server-side backend processes).

This might not always be the case, but noting which event takes place on which side will help each team discern the source of data on the tracking plan. The third source of events is external systems. One good example here is a third-party customer service app (like Zendesk) – you might want to track when someone logs a support ticket there.

The Disadvantages of a Data Tracking Plan

Data tracking plans are potentially cumbersome and monolithic. Once written, if they need to be updated too often then this takes the gloss of their potential usefulness.

Data Tracking is in Constant Flux: Data is not fixed and data tracking tends to be a moving target that evolves with a business’s needs. This may not be the case if say, a small business is trying to monitor traffic and customer data from just a couple of touchpoints (e.g. social media, websites and apps). Here, it may just be a case of building a tracking plan that enables the businesss to do some comparisons of different marketing and advertising campaigns, or building basic customer segmentation for targetted and personalised marketing. However, if the business pivots its business model or moves from say, selling through social media and direct from a website to selling through eBay or Amazon, then any data tracking plan is liable to becoming redundant.
Foresight and Planning: Secondly, whilst tracking plans are far from ‘set and forget’, they do require long-term thought and foresight, especially when it comes to what tools and technologies are required. For example, if the business/client is using Google Analytics then switches to Mixpanel halfway through then event tracking also change. The tracking plan – and the agreement in place to meet targets and KPIs – may be somewhat disrupted by changes in client or business intent, and the tools they wish to use.

How Long Does It Take To Build a Tracking Plan?

It is pretty much impossible to rush the process of becoming data-driven in a business or business process. Always budget enough time to build a tracking plan – this is a multistage process that begins with a qualitative analysis of the business and its problems, goals and objectives.

It’s only then that data scientists, engineers, analysts and other practitioners can go about identifying events to track (and how these events link to entities).

In most cases, tracking plans can be created in a couple of weeks for smaller teams where there are precise and clear objectives or problems to solve.

More advanced tracking plans that run from one end of the sales funnel to the other will be much tougher to create, taking months.

Summary: How to Create a Tracking Plan

Tracking plans provide a single source of truth that provides details of what data is being tracked, using what tools, and by what teams or individuals. After identifying business problems and deciding that tracking data is the best way to tackle them, create a tracking plan to itemise the steps you need to take to implement a working strategy.

There are many example tracking plans available online and some CDPs, CDIs or other commercial data products include their own data tracking plans that are purpose-built for their platforms.

What is a tracking plan?

A tracking plan in data is a document that details and itemises the data that will be tracked for a particular project or strategy. Most tracking plans involve a combination of event and entity (typically user) data. Data can be tracked from web pages, apps or other software and includes everything from signups and purchases to swipes, clicks and gestures.

Do I need a data tracking plan?

Data tracking plans are standard in everything from marketing and sales funnel analysis to user experience (UX), gaming and software engineering. They detail what events will be tracked and why, what their trigger events are, and what the purpose and destination of that data is, as well as the expected data type.

How do I make a data tracking plan?

Data tracking plans can be created DIY, or there are plenty of templates and examples available such as those offered by Segment.