[Podcast] How To Build A Tracking Strategy For Your Customer Data

Share on:

Share on:

Why and how you should build a customer data tracking plan and what happens if you don’t

In this week’s episode, join hosts Claudiu Murariu, CEO and Co-Founder of InnerTrends, and Arpit Choudhury, Founder of Data-led Academy, as they discuss the steps you should take to build a customer data tracking plan, how to determine what data should be tracked, the risks of not creating a tracking plan, and existing tools to help you build your data tracking plan.

Be in the know; the tracking plan will impact your analytics implementation and your ability to get meaningful insights out of it.

Want to listen to the whole episode? Check it out here:

Subscribe on your favorite streaming platform for more episodes:

Listen on Apple Podcasts Listen on Spotify Listen on Google Podcasts Listen on Stitcher

What is customer data?

[A]: It’s best to think of customer data as a combination of different types of data, because customer data by itself may not mean anything, or it might mean a lot.

Let’s break it down:

There’s Entity Data, which includes data that tells us who the user is, or the traits of a user. The user is an entity, and the data tells us about the user. For example: demographic data, PII (Personally Identifiable Information), or any other information you have about the user.
You have Interaction Data (Product Usage Data or Event Data), which tells you how he or she interacts with the product. Every interaction within the product could be referred to as an event that takes place.
And then there is Third Party Data (also referred to as Object Data) gathered from external data sources, such as support systems, advertising platforms, payment processors, data enrichment services, etc. It includes all data about users which is not being generated as a result of a user interacting with your product.

So a combination of these three types of data is referred to as customer data.

[C]: Typically, when we look at customer data, we look at logs. Every entry in the customer data is a log. And for every single log, we look at three things. We call them who, what, and how.

Who is who did what (Entity Data), what is what that log represents (Interaction Data), and how is the context, properties, or traits of the user.

Whenever we look at customer data, we need to pinpoint that data to an individual or to an account. We need to know what it represents: is it an event? Or is it just an update of properties? And then we need to know the context: what happened? And in what context did it happen? We need the context of the event, and the context of the user.

At InnerTrends, we split data into three categories. We look at:

Core Value Data, the data that links to the value, or the events and properties that link to the value of what your product is doing.
UX Data, which links to how people interact with the interface.
And Third Party Data, including data from email providers and support payment providers, etc.

But it’s also the context of the user. Not everything the user does happens inside of your product. Some of the actions they take occur outside of the product, and you want as much data from various applications.

So you can look at customer data from a technical perspective, just like you [Arpit] did, or from a perspective of source, like [InnerTrends] does. But you will always get to the same result.

How do you decide what customer data should be tracked?

[C]: This is a big one, and I think it’s the step that most companies don’t like.

I see a lot of companies that become mature enough to say, “We track data, but it’s all over the place. We need a tracking plan, we need a document, we need a central place where we know what data is being tracked.”

But they skip over deciding what customer data should be tracked, which I think is crucial.

To do this, we [InnerTrends] use what we call the Business Concepts Definitions. We say to every company, “Sit down with your team around a table and define ‘what is your business?’”

You have a couple of concepts to define. You need to define the Pirate Metrics: Acquisition, Activation, Revenue, Retention and Referral.

Ask yourselves, “What is acquisition? What are we acquiring? What is activation for us? How do we define activation? Do we have a framework for that? Is everyone on our team aligned on what activation is? What is revenue?” and so on.

The definitions of all of the pirate metrics are core value metrics, and you should get those as server-side data most of the time.

[A]: One of the best ways to decide what data to track is to ask the right questions. Start listing the questions that you have about your users that you want quick and easy answers to.

Activation is one of the most important concepts to think about. What is your activation event? At what point would you consider your user to be activated? There might even be a difference between what you refer to as an activated user versus an active user; an active user could and should be someone who is actively using your product on a regular basis. While an activated user could be someone who actually just performed the activation event.

So it’s really important to think about the questions that you have about your users at all of these different stages. Once you collect and start answering those questions, you’ll better understand what you want to track.

[C]:

Before you go and define anything else, sit around a table with your team and try to answer the following question: “What does our product do at its core?”
Because that becomes your activation definition when it happens for the first time. That becomes your engagement definition when it happens on a regular basis.
Your North Star Metric should be linked to this answer; how often that needs to happen before a user is considered as having arrived at the “WOW” moment. The answer to this question will influence the definitions.

But the definitions don’t stop here. One question and definition that few companies focus on, and has a huge impact on the tracking plan is, “What is an account structure?”

Most companies that are in the B2B space manage accounts, not users. So what is an account? What’s the relationship? Can multiple users be a part of the same account? Are they unique to an account? Are they owners, or are they different roles? That will have a huge impact on your tracking plan.

[A]: And when you have users who can actually be a part of multiple accounts, that’s when things get really complicated, and tracking becomes really hard. And if you don’t have this figured out right at the start, it could possibly cost you your entire business.

[C]: That’s spot on. It doesn’t necessarily have to become hard if you do it from the beginning. If you go around the table and draw it out, it becomes clear and easy to do. But if you don’t do it right from the beginning, fixing it later can be a nightmare. So don’t try to fix it, try to get it right from the beginning.

What is a data tracking plan? And how do you build it?

[A]: A tracking plan is nothing but a simple Google Excel Sheet. That sheet is where you define all of these important events that lead to activation, for example.

To expand: a user signing up, a user verifying an email, a user inviting their teammates and creating a project or campaign, and then eventually sending that campaign.

So we start defining those events in a simple excel sheet. Now, for each event you want to have more context, right? You have an event called “Project Created” or “Campaign Created,” but that’s not enough. You want to know who created that campaign, what type of campaign it is, where that campaign was created, etc. That’s when you think about the properties associated with each event, and you need to list those properties down in your sheet.

Once you have the events and properties, you actually have a bulk of the work done.

If you want to make things easier in the long run, you could think about the data-type of each property. So you can define what you expect the data-type of each property to be; is it a string? Is it a number? Is it a timestamp? It could be a boolean value of whether the user added another teammate or not, so it could be just a true or false answer.

It might feel like you’re spending a lot of time on this, but it will pay off and make a huge difference in the end.

Other important core concepts to include in your tracking plan are:

Mentioning where the event is being tracked, whether you’re tracking an event client-side or server-side. If you want to make it even easier, take a screenshot and put it in your sheet.
Account structure (users versus accounts). A SaaS product is tracking a lot of data at the account level, so you at least want to know which account the user belongs to.
User properties: traits about the user, traits about the account, including items like what is the subscription tier of the account, how many users are in the account, etc.

When you put all of this together in an excel sheet, that becomes your tracking plan. There are some great templates out there. [Data-led Academy] also has a very neat template to create a tracking plan.

So just start with the template, start writing things down, and don’t try to make it too complicated. Start with a few core events. You will have a really great tracking plan if you follow these steps.

[C]: If you start with the definitions from earlier, making sure that everything you defined is covered by the tracking plan, and add as much context and as many details as possible, what will end up happening is that you will actually win a lot of time in communication with the dev team, who will do the implementation.

A good tracking plan will guarantee that you will have that data implemented without communicating with the dev team even once. Once received, that’s all of the communication they need of what and how it needs to be tracked, and they’ll make it happen for you. So yes, it might take time to build this. It will take time to maintain it. But it will cost a fraction of the time that you would otherwise spend to get some data tracked from the dev team.

What are the risks of not creating a tracking plan at all?

[C]: There is no accountability, no transparency. And the worst risk is that if the person that did the tracking leaves the company, then the company stops using the data. Because they have no idea what is being tracked, or how it is being tracked.

[A]: A lot of companies end up focusing on tools and technologies and they will spend thousands of dollars on product analytics tools and customer data platforms, etc. and once they buy that, then they just hand it over to the dev team and say: “Okay, now please implement this, our job is done; we’ve decided which tool to buy.”

This is a huge recipe for disaster, because it will lead to inconsistent data, and you will not know what data is captured, you will not trust the data, and even if it is accurate, you wouldn’t know that it’s accurate.

When it comes to scaling and adding new features, or new events, it gets even worse, and the time consumed to figure it out gets hugely inflated.

So not having the centerpiece – i.e. the tracking plan – affects the product and the engineering teams. Moreover, it affects the data team if you have one, and it certainly affects the marketing and growth teams.

Tools mentioned during this episode:

Specific tools for managing and collaborating on your tracking plan:

Have any additional questions about customer data tracking, or other topics you would like to hear covered on The Data-Led Professional Podcast? Comment below! We can’t wait to hear from you.

Subscribe for more episodes on your favorite streaming platform or subscribe for InnerTrends updates here:

Listen on Apple Podcasts Listen on Spotify Listen on Google Podcasts Listen on Stitcher