Why you need a tracking plan.

This is part 2 in a series about how to implement a Customer Data Platform (CDP) in your business. To find out what a Customer Data Platform is click here.

You and your team have decided that it’s time to implement a CDP. You know roughly what you will want to get out of it: A better understanding of your users, insights into transactional data, maybe there is a UX or content angle you are interested in. Either way, you are wondering how to get everyone in the team aligned as to what needs to be done to implement a CDP successfully. For this you will need a tracking plan.

In a tracking plan you specify the below four things. In this article we will only discuss the first two points. A more detailed article about the other two points will follow in the future.

• What events you want to track

• What attributes the events each should have

• How and when you want them to trigger

• How the attributes map to potential analytics objects you might want to track

If you are coming from the engineering side, you will find that the tracking plan has the same purpose as a configuration management plan. The document is supposed to reflect the current state of your data model. In other words, if you pull your CDP's data model into a relational database the schema would map to your tracking plan with close to a 1:1 relation.

In digital marketing, there is no direct analog to the tracking plan. The closest thing (to a tracking plan) in digital marketing is a content plan. Here you also specify attributes that will then be rolled afterward (as close as possible to the specified version). An important difference of course is that it makes sense to revisit older parts of a tracking plan (to update property names or values or change how an event is triggered). Normally this is not the case for a content plan.

Maintaining a tracking plan can be a cumbersome effort. However, after a bit of a learning phase, it can be done very efficiently, if you know what you are doing. Time that developers, UXers and other team members might initially be reluctant to invest. So, in order to not strain your team with (yet another) new cumbersome workflow, it is important to develop a lean and efficient way to create and maintain your tracking plan. There are several ways to get there, below I will layout one of them. Of course, your team might well find that a different way works best for them. In the end it comes down to what business objectives you are aiming to achieve.

In order to arrive at an actionable tracking plan, that allows you to give value back to the organisation, one useful starting point is to ask "What would an ideal dashboard for my department look like?" or more generally "What questions do my business and I need answered?"

Draw it on a whiteboard, make it in PowerPoint or in a visualisation tool. You can turn this exercise into a workshop, get colleagues from adjacent departments involved (or more broadly those that might end up consuming data and insights from you in the future). There will be colleagues for whom it is easier to state questions that they would like to get answered. This works just as well.

Once you have collected some dashboard ideas you sit down with a data lead and work out commonalities between the dashboards. Group them, prioritise what features are more and less important. At this point it is key to have someone that has a keen understanding of data visualisation and data models.

Say you have gathered the mock-up dashboards and found that the most requested features and questions are:

• How are my campaigns performing?

• What videos are users watching?

• Where are users going after they reach the site?

• Which of my leads should I prioritise over others?

You will have to ask yourself, where in the visit of the user, is the signal being sent (or the event triggered) that would help me to answer this question.

Let's take the second question and go to the next step. Say we are satisfied when a user has watched 4/5s of a video, so we decide that's a key interaction (or success), we will want to track. We also want to know the ratio between video starts and finishes or successes (from above), to get a sense of with videos get stopped more. You will also have to consider that to your videos might have an outro that users are going to skip reliably after they have seen it once or twice.

From here we can deduct that we will want to track some sort of Video Watched event, that fires whenever the user starts watching a video and when they have watched 80 percent (4/5) of a video.

So we note down:

Video Watched

It probably makes sense to fire an event at the very end and maybe also in the middle. Instead of tracking Video Started, Video Watched Half and Video Watched Entirely events, we want to track a single event, that with the help of properties, gives us the same level of insights as the 3 separate events above would give us. We will talk more about the advantage of using few properties rich events over many similar events in a future blog post. For now, it's important to understand that Video Watched {percentage:0} is the same as tracking a Video Started event. So, we get:

percentage: 0 // 50 // 80 // 100

We want to tell more about the individual videos, so many attributes that we can send on from the video hosting system, will also be useful. Some common ones could be:

videoId: videoType: 'Testimonial', Product Demo', 'Guide', 'Testimonial'

With these we can group all videos by videoType once with 0% and once with 80% divide the latter with the former and we have a watch ratio by video type.

With that metric (and a nice visualisation of it) we have made a good first stab at answering the initial question.

We do the above process for each of the questions and features and in the end, we will have events and attributes that make up our first tracking plan. Now you just need to implement it, sit back, wait a couple of weeks to collect data (you can work on the data visualisations in the meantime) and there you have it. A simple workflow to get from business question to insight. I wrote 'fist stab' or ‘first try’, because (like so much in this space) a tracking plan and insight creation is an iterative process. You start tracking something, make a couple of graphs, understand your customer a bit better and then you have even more questions. So, you go back to the drawing board, discover that your new questions require a new set of attributes, so you specify and implement them. And so, the cycle begins anew.

As an optional step we can map all our attributes to analytics objects. These could be video, product, page, link, button. This ensures that we keep an overview over our attributes and don't end up, with several attribute names for the same attribute in different events.

In order to arrive at an actionable tracking plan for your organization we start out by envisioning the dashboard we want to create once the data is collected. Then we go through the elements of the dashboard one by one and determine the events and properties necessary to make each graph or table.

If you have any further questions about how to create a tracking plan, feel free to reach through the form below.