How to create a CDP worksheet from your use cases

Getting the right mix of front-end and back-end functions is key to your CDP evaluation and implementation. Start with your use cases and build a worksheet.

The world of marketing technology is often a confusing mess. The services offered by customer data platforms, data management platforms, marketing automation platforms, and email service providers often overlap, and it can be difficult to decide what you need. 

If you’re considering a CDP, there are a lot to choose from, and they come in several different flavors. The unique quirks of any given CDP are usually determined by its origin story. Most CDPs started as something else and tacked on additional services to become full-fledged CDPs. The one that started as an email service provider (ESP) will be a different animal than the one that started as a recommendation engine. They also differ in whether they focus more on B2B, B2C, retail, publishing, etc. 

One way to cut through the fog is to distinguish these services by their back-end and front-end components. 

Back-end vs. front-end

Back-end components include the technical infrastructure and processes that are used to collect, store, harmonize, and manage customer data. This category typically includes data integration, warehousing, governance, and security features. The back-end component is responsible for ensuring that customer data is accurate, complete, and accessible, with the goal of merging disparate records from multiple sources to create a single customer view. 

The front-end component of a CDP can be divided into marketer-facing and customer-facing features. The marketer-facing side would include data visualization and reporting, while the customer-facing side might include recommendation engines, paywall management, and custom content displays. 

Some CDPs are almost exclusively back-end, with almost no customer-facing front-end features. Other CDPs include lots of front-end “activations.” To make it more complicated, all of these functions are available from stand-alone, dedicated services. 

The trick to evaluating a CDP is to figure out which components are necessary for your use cases, and which need to be part of the CDP itself. 

For example, a CDP might have a built-in ESP. That may or may not be a good thing for you. If one of your use cases requires you to send an email the moment a user takes an action on your website, you’ll either need the CDP to be able to send the email, or you’ll need a real-time connection to an external ESP. 

It’s helpful to think of a CDP the way you might think of a vacation resort. The resort owner wants to be able to say that the resort has some activity, like a water slide, so they build a token water slide on the property. It’s not going to be as good as the dedicated water slide down the road, but it’s also not down the road. It’s right there on the resort. 

In the same way, the ESP that’s built into a CDP is probably not going to have as many features as a dedicated ESP, but that doesn’t matter. What matters is which solution fulfills the requirements of your use cases. 

To make it even more complicated, there are a lot of “CDP-like” services that do some of the work of a CDP. 

To navigate this confusing mess, consider a few use cases and see how the back-end vs. front-end metric can help. 

Recommendation engines for content

Adding customized recommendations to an article on your website can enhance a visitor’s experience with your brand and increase page views. 

The functionality required by that use case depends on what data the recommendation engine will use. 

If you want to recommend articles based (at least in part) on which e-newsletters the customer receives, or which products the customer subscribes to, you’ll need a back-end connection with the ESP and/or the fulfillment system, and you’ll need the ability to merge the user’s online profile with that data. But if you only want to make recommendations based on the user’s web behavior, you don’t need that back-end function, and you might not even need a CDP. Many stand-alone recommendation engines can handle that. 

Questions to ask: 

• Does this use case require back-end data management? 
  
• Is the CDP’s front-end function good enough, or do I need a dedicated service? 
  
• Does the CDP integrate with that dedicated service? 

“Customers who bought this…”

In the retail space, vendors want to provide product recommendations, which can increase the value of each order. 

If the recommendations are based (at least in part) on the customer’s order history, the recommendation engine needs that back-end data. If the recommendations are simply based on averages across all customers, specific information about the customer’s purchase history is irrelevant. 

Managing a paywall

Publishers who don’t wish to rely exclusively on ad revenue to fund the creation of their content may offer access to premium content for a fee. This requires the creation and maintenance of accounts to manage access to this content. 

In many cases, those accounts will need to be coordinated with other accounts, such as a magazine subscription. For example, a magazine subscriber might get through the paywall for free, or at a discounted rate. In that case, the paywall management system will have to integrate with back-end data from the magazine fulfillment system. 

Landing page optimization

A/B or multivariate landing page tests can dramatically increase the success of an online store, online forms, and e-newsletter sign-up pages. Services that facilitate the creation and deployment of such tests usually do not distinguish between customers and non-customers, and that seems to work for most situations. In those cases, you don’t need a CDP. 

However, if you have reason to believe that your customers are significantly different than the average web visitor, you might need your landing page optimization calculation to show different stats for different groups. 

For example, a website with medical content might have a split audience that includes medical professionals and ordinary citizens. You wouldn’t want the results of an A/B test on a landing page for a report written for doctors to include stats on how everyone else responded. In this case, back-end information on the audience might be crucial. 

Surveys

Surveys can help you understand your customers, which can help you provide better service. Many CDPs can manage surveys, but very few CDPs can compete with the functionality of a dedicated survey platform. How does this affect your evaluation of potential CDP vendors? 

Questions to ask: 

• Will my surveys be enhanced by incorporating back-end customer data? (E.g., not asking things you already know, or asking different questions to different audiences.) 
  
• Is it important to be able to extend the survey process over time through progressive profiling? 

Building a worksheet

I hope these examples have prompted you to imagine a worksheet somewhat like this. 

This is an overly simple example, but you can use this general idea to customize a worksheet for your specific requirements. 

The key is to start with use cases and think them through in terms of front-end and back-end functions, also considering 3rd-party alternatives. The more your use cases require back-end functions, the more you’re likely to need a CDP. And once you’ve created this document, it will make the RFP/discovery process much easier. 

The post How to create a CDP worksheet from your use cases appeared first on MarTech.

About the author

Greg Krehbiel

Greg’s decades-long career in B2B and B2C publishing has included lengthy gigs in editorial, marketing, product development, web development, management, and operations. He’s an expert at bridging the intellectual and cultural divide between technical and creative staff. Working as a consultant, Greg solves technology, strategy, operations, and process problems for publishers. His expertise includes Customer Data Platforms, acquisition and retention, ecommerce, RFPs, fulfillment, and project management. Learn more at krehbielgroup.com.

(24)