6 tips for building a Customer Data Platform tracking plan

Building a tracking plan can be daunting when doing it for the very first time. And even if you have experience with product analytics tracking plans, you’ll feel very quickly that tackling a CDP tracking plan is yet another challenge. In order to set you up for success we’ll share 6 tips that will help you rock your first Customer Data Platform (CDP) tracking plan.

Note that the objective is to provide you with handy tips as a primary objective, not a full accompanying guide. There’s no particular order in which these are listed.

Developing a tracking plan for a Customer Data Platform is different from developing one from an analytics tool. Even though experience in tracking for event-based analytics platforms will definitely speed up your CDP planning process, there are some major differences. The objective of tracking for an analytics tool usually lies in understanding how the user moves across the app or website, which buttons are(n’t) clicked and where the users drop off. This typically means developing a tracking plan within the scope of a single environment (app or web) and for a specific end-consumer (the web analyst). 

Building a tracking plan in the context of a CDP is more complex as we need to consider how users move across touchpoints throughout their lifecycle. 

• CDP’s are multi-platform (web, app, custom implementations and assets, etc) as the objective is to facilitate a 360-degree customer view.
• CDP’s function as data pipelines ingesting data from different platforms, transforming it to validate quality and resolve identity, and sending it through to other platforms such as CRM systems, web analytics tools, ticketing services, marketing services, etc. 
• CDP’s allow different stakeholders to consume data in their proper platforms all while using a single tracking plan. This means that the requirements of stakeholders across marketing, product, customer support, and analytics need to be translated into the source tracking plan so that all can consume data in their platforms. 

Developing a CDP tracking plan therefore has an increased scope (and complexity) compared to a single-source single-consumer platform tracking plan.

When developing a tracking plan for a CDP it is important to take into account which tools you’ll be sending data to. Even though the objective of a CDP is to allow for certain flexibility by allowing to test tools quickly that otherwise would need code-based implementations, it’s important to be aware of data formats that are not accepted in your downstream toolkit. Where it might seem logical to introduce arrays or key-value pairs in property fields it might simply be that a particular downstream tool is not able to cope with or visualise them. Even though we believe this rather highlights a downside of the downstream tool in use, it’s an important element to take into account especially when working with custom developed solutions or during migration projects. This isn’t only important for the tool you’ll be using, but also for the analysis you’ll be making.

A “naming method” is a way to determine how events (or actions) will be structured.

Two examples are the “object-action” and the “action-object” naming methods.

Let’s illustrate this using an example.

Imagine we are designing a tracking plan for an ecommerce store application and we would like to track when a user selects the payment method button. The event name would look differently depending on the method selected.

• object-action = payment method selected
• action-object = select payment method

Using a “naming method” ensures consistency, simplicity and efficiency when developing the tracking plan by serving as a self-explanatory point of reference. In general, we could argue that both models yield the same result and there is neither a good nor bad choice. From our experience, we tend to prefer the object-action method as this ranks, in many tools, the object in an alphabetical order which improves find-ability.

Case types essentially determine how things are written down. Literally. They determine which words should be capitalised, if spaces should be omitted or not. And if not, what should be replacing them. 

In order to illustrate what case types mean exactly, we’ll be using our previous example. Let’s develop our object-action based event “payment method selected” using different case types.

• snake case = payment_method_selected
• camel case = paymentMethodSelected
• pascal case = PaymentMethodSelected
• kebab case = payment-method-selected

There are a variety of case types available for you to choose from. Our personal favourite remains snake case as its simplicity reduces the risk of error while maximising readability.

Just like choosing a method (point 3) selecting a case type will result in improved consistency, simplicity and efficiency when developing your tracking plan. It’s important to establish case consistency for data collected into your CDP because it will impact the quality of data that ends up in downstream tools across your stack.

There will probably be a point at which you’ll be developing a tracking plan and realise you have tracked a specific event but in multiple locations. Popular examples are for instance adding things to a wishlist in the context of an ecommerce platform. This can be done at the product overview level after filtering or at the product detail level, for example. The reflex will oftentimes be to start giving each event a slightly different name. For instance:

• wishlist_product_added_overview
• wishlist_product_added_product_details

Depending on how many of these similar events need to be added this creates some problems:

• Counterintuitive event names (Frankenstein constructions)
• Breaking your naming method
• Opening the door for incomplete analyses.
  Here’s an example - in order to answer the question “how many times were products added to the wishlist in the last 30 days” in your downstream product analytics tool you would need to sum all the counts of the individual events in order to be able to answer the question. The previously mentioned problems (counterintuitive events names and breaking the naming method) will make it a challenge for the analyst performing the analysis to successfully identify and retrieve all of the individual events required to answer what should be a simple question.

But what is the alternative?

The solution is to use properties. A location property to be specific. The result for the above mentioned example would look like this:

• Wishlist_product_added_overview = Wishlist_product_added where property “location” is set to “overview”
• Wishlist_product_added_product_details = Wishlist_product_added where property “location” is set to “product_details”

This allows the analyst trying to solve the question to simply select the event. In case subsets need to be created the analyst can simply subset using the properties of the event, rather than by finding and combining different events. Obviously the parameter name “location” is a placeholder and can be interchanged with whatever you see fit. 

Developing a tracking plan is like creating a painting. You’ll rework some of the parts you thought were finished to make it more consistent with what you have created in the meantime.

Creating a tracking plan for a CDP can be daunting. Imagine how the teams implementing the plan will feel. Adding loads of tracking without proper intermediary testing also creates a challenge to identify where specific bugs or data quality issues come from. Therefore it is important to understand that implementation can happen gradually. You could start with the most crucial parts of the customer journey in the most crucial platforms. In two-sided platforms you could decide to first focus on one side of the platform and then on the next. Most tracking plan templates provide a status column allowing the different teams to indicate what has been finished from a design pov, from a testing pov and from an implementation pov.

Building your CDP tracking plan is much easier when your CDP provides pre-built planning features for your team to work with. mParticle’s Data Master provides a forum for multiple stakeholders to build a Catalog of events being tracked along with their purpose, create a Plan that defines the extent and shape of the data that is collected, and review a Live Stream of data points being collected into the platform.