Prepare for CDP implementation using a template for use cases

When considering a customer data platform, many people ask questions like:

• How do I pick the right one?
• Do I need a data lake along with a CDP?
• How much of my current tech stack can a CDP replace?

Those are all good questions, but there is no generic answer that will work for every company. It depends on your business model, your current tech stack, and what you want to do with your customer data. In other words, it depends on the use cases.

“But wait,” you say. “What exactly is a customer data platform?” 

The CDP Institute defines a CDP as “packaged software that creates a persistent, unified customer database that is accessible to other systems.” In a perfect world, it creates a single customer view from all your customer data, no matter where that comes from – your email service provider, your store, your fulfillment system, customer web behavior, etc. It stores this information in a format that enables you to act upon that enriched, comprehensive, single view of the customer.

That’s the goal, anyway. In reality, you’re never going to merge all your data. It’s a question of degrees. And that’s okay.

Dig deeper: What is a CDP?

Why do you need a CDP?

A CDP can help you do some very useful stuff.

• Find out which of your paying subscribers that frequent your website haven’t yet signed up for your email newsletter, allowing you to target them on your website to invite them to sign up.
• Personalize messages based on interests, order history, or other characteristics.
• Present better and more targeted cross- and upsell offers.
• Create new options for advertisers by creating new segments of users based on common interests.

But before you pull out the checkbook, there’s some work to be done, and this applies whether you already have a CDP or are considering one.

Looking for a CDP? Download our buyer’s guide today and learn everything you need to know.

Why you need to write CDP use cases

You need to define how you hope this technology is going to help you and your customers. That is, you need to write up your use cases, with as much specificity as possible.

By starting with use cases, you avoid the “bright shiny object” problem and focus on genuine business requirements. Through this process, you’ll discover what functions you need a CDP to perform, and therefore whether you really need one, and you’ll be able to get a better handle on whether it’s worth the investment.

If you already have a CDP, creating a disciplined structure for use case documentation and review will smooth your operations considerably.

There are many ways to write up use cases, but I’ve summarized my recommended structure below to help you get the process started. I say “to get started” because this document is only the beginning. You’ll write up your use cases in the format I outline below as a preliminary matter, to decide if they’re worth pursuing, or to decide if the CDP can meet your requirements. If you decide to go ahead with them, you’ll have to create a much more detailed document when it comes to implementation.

Generic use case template

You should create a form using the elements I list here and ask everyone in your organization to use this form when they propose a new use case. Thinking through each of these elements will help you define exactly what you want to do and how.

Summarize it with a story. Use a very structured format, like this: As a [role], I want to [action] so [result]. For example, “As an email marketing manager, I want to display a sign-up widget for our retirement e-newsletter to everyone who has recently viewed retirement content on the website so I can increase the reach of our retirement e-newsletter.”

Make the business case. Explain why this use case is necessary now, and how it will:

• increase your revenue,
• improve customer service,
• help you discover new (possibly ancillary) product ideas,
• create better reports, etc.

Refine the summary with specific details

The devil really is in the details when it comes to CDP use cases. If you ask the salesman, “Can your CDP do ____?” the answer will almost surely be yes. It’s only when you dig into the details that you find the limitations and potential problems. 

For the example in the story above, additional details might include the following.

• What constitutes “retirement content,” and how will the CDP recognize it? (E.g., is it tagged?)
• Can the CDP react immediately to a tag on the first-page view?
• What are the specs on the widget?
  • How and where should it be displayed?
  • What words and images should be used?
  • How big is it?
• Do you want to A/B test different versions of the widget?
• What is the path for the data to get from the widget into the CDP and into your ESP? Which system is the “source of truth”?
• How will you measure results?
• How long should the campaign run?

The more details you provide, the better.

Identify relevant customer data and its source

For some use cases, all you’ll need is data from within the CDP. You might create segments of users based on favorite topics, when they visit the site, or how often. Other use cases will require data from your other systems. Explain that as carefully as you can.

• If you want to target on-screen messages to people who have marked your e-newsletter as spam (some people do that by mistake), you’ll need data from your ESP.
• If you want to target customers with high lifetime value, you may need data from your fulfillment system.
• If you want to evaluate the behavior of prospects who have recently downloaded a whitepaper, you might need an import from Salesforce.

In any case, think about the systems that house the data you need to make this use case successful, and then look carefully at how that data is stored. Will it need to be cleaned up, or transformed in some way? Can you get it in real-time, or does it have to be batched? Does the system from which you want the data have an API, or will you need to build a connection?

Dig deeper: M&T Bank’s use cases for their CDP implementation

Can you re-purpose existing segments?

If you already have a CDP, you may have already defined the right segment of users. If so, list it here.

But be cautious! It’s crucial that you carefully document how a segment is created and what it’s designed for. It’s very easy for a segment name to be misleading. For instance, does the category “all subscribers” include both paid and free e-newsletter signups? Does it include people who have attended webinars? Does the segment “active subscribers” include people in grace, undeliverable orders, or unpaid orders?

Those are simple examples of how messy it can get. Things quickly become far more complicated than that, so make sure segment definitions are well documented.

Success criteria for the CDP

How will you know that this use case did what you wanted it to do? How will you track the actions you are seeking? What reports are required? What metrics constitute a success?

If possible, you also want to specify revenue goals – especially if you’re in the consideration phase and want to determine the potential return on investment of a CDP.

You’ll need more later

That outline is for the consideration phase. That is, do you want to pursue this use case or not, and can the CDP deliver on what you need?

Once it comes to implementation, you’ll need a more extensive template that includes other details, like specific language for an offer, design specifications, internal approvals that are required, and possible follow-on uses.

By taking a disciplined approach to use cases, you will have a much easier time evaluating CDPs, or getting the most out of the one you already have.