What is a Customer Data Platform (CDP) in plain English?

Vendor-neutral answers to the top 10 most commonly asked questions about CDPs

Birdseye view of people walking on sidewalk with 1s and 0s.

The demand for Customer Data Platforms (CDPs) has been rising steadily for the past several years. Yet, despite the growth of the CDP market, most people remain perplexed about what a CDP actually is. There are many reasons for this: CDPs are relatively new players in the MarTech world, the space is evolving rapidly, CDPs provide similar functionality to other enterprise technologies, and there are so many vendors that have adopted the CDP label. I pity the poor fool trying to learn about CDPs through the marketing materials from the vendors themselves. They all start to blur together and sound the same, even though they are all very different under the hood.

In this article, we’ll cut through the noise and answer some of the most commonly asked questions about CDPs. As a MarTech Practice Area Lead at Slalom, I’ve had the opportunity to get my hands dirty with several different CDP platforms, from strategy to evaluation to implementation, for companies across a broad range of industries. To help clear up the confusion, I’ve compiled a list of the 10 questions about CDPs that I get the most from clients, with answers to each.

Top 10 CDP Questions:

1. What’s the definition of a Customer Data Platform?

In the Slalom whitepaper on Customer Data Platforms, my colleagues and I offered the following definition of a CDP: “A Customer Data Platform is simply a marketing-focused technology that unifies customer data from multiple sources and makes it available to marketers for customer segmentation, analytics and activation across marketing channels.” In a nutshell, a CDP unites all the customer data within an organization (e.g. loyalty, transactions, website interactions, eCommerce, third-party data, etc.), and makes it available to marketers to do personalized marketing across channels (email, social media, website, SMS, mobile, etc.).

2. Is a CDP the silver bullet we’ve been promised?

Despite all the marketing hype, the purchase of a single CDP product is unlikely to solve all the data needs for a marketing organization. CDP vendors cover an impossibly broad range of functionality, including data ingestion, identity resolution (i.e. match-and-merge), tag management, website personalization, analytics, big data management, segmentation, activation, orchestration, and machine learning. No single CDP provides all of these capabilities. As a result, most companies use a hybrid buy/build approach, and fill in the gaps with custom development. Others purchase multiple products in the CDP space. Yet others simply make do with the missing capabilities. When evaluating vendors, it helps to get crisp on business priorities, and be prepared to get less than 100% of what you want from a single product.

3. Should I build or buy?

I get the buy-versus-build question a lot. Often, it’s from business intelligence/data engineering teams who see CDPs as a specialized version of a data pipeline, rather than a MarTech platform. Although the answer to this question ultimately depends on the capabilities, constraints and culture of the company, I usually recommend a hybrid approach that leverages an off-the-shelf CDP for the core, and custom data engineering around the edges. When teams are considering building a CDP in-house, they usually underestimate the complexity of identity resolution (i.e. the process of finding matching customer records across different data sources) and don’t consider the cost/complexity of building a marketer-friendly user interface. They also tend to underestimate the level of effort required to build and manage dozens of marketing channel integrations. I’m a software developer by trade, so my native instinct is to build, but CDP products are feature-rich out-of-the-box, and building a comparable product is a costly proposition. In-house engineering teams can add more value by developing functionality core to the business, rather than building general purpose MarTech plumbing.

4. How is a CDP different from a CRM/EDW/MDM/Data Lake?

A CDP differs from traditional enterprise data technologies in several ways:

  • CDPs are purpose-built to manage customer data for marketing use cases. In comparison, data lakes, enterprise data warehouses (EDWs) and master data management (MDM) solutions are general-purpose data toolkits designed to manage all enterprise data, including financial, HR and operational data.
  • CDPs are built for activation (i.e. using data to fuel marketing experiences), while traditional enterprise data technologies are designed for analysis (i.e. dashboards and reports).
  • CDPs are an integration technology, whose consumers are other marketing tools. CRMs for sales and service (e.g. Salesforce Sales/Service Cloud), in contrast, are used directly by employees.
  • CDPs are designed from the ground up to work across channels, whereas marketing-oriented CRMs (e.g. Salesforce Marketing Cloud) are built for direct response channels, like direct mail, email and more recently, SMS.
  • CDPs are built for higher volumes of data than traditional CRMs. For example, you will want to include all your website clickstream data in your CDP. However, you do NOT want to include clickstream data in your CRM, EDW or MDM.
  • CDPs are designed to move at the pace of marketing. They are schema-light to speed up the onboarding of new data sources and activations. In contrast, EDWs and MDM solutions are schema-heavy, requiring a lot of ETL (Extract, Transform, Load) and governance, which means they adapt to change slowly.

5. How does a CDP fit with my existing enterprise data technologies?

This is a difficult question to answer without assessing a company’s current data architecture. However, there are a few patterns (and antipatterns) that are common.

  • CDP + data lake/data warehouse: A CDP is usually paired with a data lake. Customer data is ingested and unified in the CDP, where it’s then segmented and sent to different marketing channels for activation. A data lake is often one of the “channels” that a CDP sends data to. From the data lake, customer data gets loaded into a data warehouse or used directly in dashboards. Data lakes pair well with CDPs because CDPs send them clean, rich, unified customer data. A related antipattern is to use a data lake as the only CDP channel, requiring all marketing activation integrations to be developed from scratch from the data lake by data engineers. This creates a bottleneck by removing the pre-built integrations and marketing self-service capabilities of a CDP, and shifting the work to highly specialized (and often overworked) engineers.
  • CDP + MDM: For organizations with a Master Data Management solution in-place, MDM can be a source of customer data into the CDP. Other sources of customer data that fall outside MDM (e.g. clickstream data or third-party data), can be additional sources into the CDP. The CDP can then do further match-and-merge (a process called identity resolution) and handle marketing activation for downstream marketing channels.
  • CDP + CRM: A CRM can be a rich source of customer data into a CDP. It can also be a downstream consumer of CDP data. For example, a CDP might ingest customer data from a CRM (as a source) and also augment/enrich customer records in a sales- or service-oriented CRM (as a destination). For marketing-oriented CRMs, a CDP can provide clean, segmented data to trigger direct response journeys.

6. Do CDPs handle activation and marketing orchestration?

“Orchestration” is an ill-defined and confusing concept in MarTech. In my experience, the term means different things to different people. So, when the word “orchestration” comes up in a conversation, I define it explicitly to avoid miscommunication. In simple terms, orchestration is the capability to create multi-stage, multi-touch marketing campaigns (a.k.a. journeys). A simple example of an orchestration is a drip campaign, where a customer completes an activity (e.g. a sign-up or purchase), and they receive a series of follow-up emails. More complicated orchestrations might try to move prospective customers through the sales pipeline for a B2B purchase, using a combination of emails, special offers and paid online advertising. Orchestrations can be linear (as in the case of a drip campaign) or contain multiple paths (e.g. take action A if the customer engages within 3 days and take action B if they don’t). Orchestration can occur within a single channel (e.g. email) or across channels.

The term “activation” is similar but different. I use activation as a general term for taking action on CDP data. An activation could be a complex orchestration, a one-time marketing communication or the process of pushing CDP data into a data lake.

With these terms clarified, let’s now answer the question. By definition, all CDPs perform activation (if they don’t, they’re not a CDP), while only some perform orchestration. The reason for this is that orchestration and journey-building are complex and require a tight coupling between the data and the marketing channels. Classically, CDPs are channel-agnostic and thus designed to send data to other channels, but not necessarily orchestrate it. For example, a CDP might send a customer segment to a marketing-oriented CRM like Salesforce Marketing Cloud (SFMC) and SFMC’s journey builder might be used to handle the orchestration. However, some CDPs are orchestration-oriented, and have the ability to do cross-channel journeys. Orchestration-oriented CDPs are often less robust in terms of data engineering features (e.g. identity resolution and storing a full history of customer interactions), but they make setting up complex, cross-channel activations easier. And while it’s possible to setup multi-step journeys with a non-orchestration-oriented CDPs (by defining a series of segments), it’s more difficult.

7. Are CDPs for retail only?

The first wave of CDP buyers were retail companies and the examples used to explain CDPs are often retail oriented. Thus, it’s easy to think CDPs are a retail-specific technology. However, I’ve worked on CDP projects for clients in the financial services, healthcare and technology industries as well. CDPs solve problems that are common across a wide range of businesses.

8. Can CDPs used by B2B companies?

Overall, B2C companies are several years ahead of B2B companies when it comes to data-driven marketing, and CDP vendors have tailored their product offerings accordingly. However, CDPs have huge potential for B2B companies as well—after all, buyers for B2B products are people too. The main difference is that B2B companies need to identify the organizations that their customers work for, in addition to the customers themselves. Most CDPs on the market today don’t do this well. Another difference is that the use of purchased, third-party data is much more common in B2B marketing. Although CDPs can ingest third-party data, their sweet spot is owned, first-part data. Despite these differences, B2B companies are already starting to invest in CDPs. For B2B buyers, it’s critical to do extra due diligence to determine if a potential CDP product will address their specific use cases.

9. Which team typically buys and manages a CDP?

The ownership of buying, implementing and managing a CDP differs across companies. For many, CDP is owned by the enterprise analytics/business intelligence team, as this department is most closely involved with the collection and use of data. In other companies, the MarTech team owns CDP. MarTech sits between IT and marketing, and is responsible for managing the marketing tech stack. For them, CDP is a shiny new technology that holds the promise of unifying a disparate set of MarTech tools. In yet other companies, marketing itself owns CDP. Ironically, this is the least common situation in my experience. Marketing is the end beneficiary of a CDP, so they seem like the natural owner. But marketing teams often lack the technical expertise to evaluate or recommend a CDP, so they tend to defer to other technical teams for this job.

10. Full stack marketing cloud? Or vendor-agnostic CDP?

In large part, the CDP space was created by start-ups and independent MarTech vendors to help companies without a full-stack marketing cloud unify customer data across their multi-vendor marketing stacks. The full stack vendors like Adobe and Salesforce didn’t have a centralized hub for customer data either, but they had enough integrations across products to fake it. Then the demand for CDPs skyrocketed and the full stack vendors realized they were late to the party. Determined not to be left out, they quickly pivoted and started rolling out their own CDP offerings. So, is a full-stack marketing cloud the right solution?

The answer depends entirely on the organization. If you’re already all-in on a full-stack marketing cloud, and can wait until the vendor’s CDP product matures, it probably makes sense to consider their CDP. But if you need to rollout a CDP more quickly, be cautious. Make sure to perform a detailed technical assessment to determine if the current-state feature set will suit your needs. And remain skeptical about the timeline for future releases—don’t take what the salesperson says at face value. Trust, but verify.

On the other hand, if you’ve adopted a multi-vendor MarTech approach, then it probably makes sense to leverage an independent CDP platform. These products have a more mature feature set and are designed from the ground-up to work with multiple vendors. Regardless of your situation, plan to spend some quality time evaluating different options. Slalom’s whitepaper on CDPs offers some good advice on how to approach this process.

Conclusion

Clearly, there are many aspects to consider when evaluating a CDP. With so many options available, understanding the landscape and making the right decision can feel a bit overwhelming. Fortunately, as the CDP market matures, common patterns and best practices are starting to emerge. The answers to the questions above are an attempt to shed some light on this rapidly evolving technology from a much-needed vendor neutral standpoint.

Related Articles: