Chances are you’ve at least heard about Customer Data Platforms (CDPs). You may even know they combine customer data from different systems to build a complete customer view. But do you know whether CDP claims are realistic? Do you understand the differences between CDPs and other customer data solutions? Most important, can you judge whether a CDP is right for your organization?
Let’s find some answers.
What’s a CDP?
Definitions first. The CDP Institute defines a CDP as a “marketer-controlled system that builds a unified, persistent customer database that’s accessible by other systems”. The key elements of that definition are:
- Marketer-controlled. The CDP is packaged software that can be bought and managed by marketers, not a custom development project for the IT department. IT probably will (and should) still be involved with a CDP, but packaged software is almost always cheaper to buy, quicker to deploy, and easier to maintain than a custom system.
- Unified. The CDP finds and connects all data related to the same customer. This takes special processing when the different source systems use different customer identifiers internally (which is nearly always the case).
- Persistent. The CDP stores its own copy of data. This is needed to track behavior and identify trends over time. Persistence is missing in many kinds of systems, including integration platforms, tag managers, and data hubs. These move data from one place to another without storing it themselves.
- Customer. The CDP stores personal identifiers, such as names, locations, and email addresses. This requires special controls for privacy, safety and legal reasons. Other systems the hold marketing data – most notably Data Management Platforms (DMPs) used to select advertising audiences — often avoid storing personal identifiers.
- Database. This is a broad term, but in this context let’s say it refers to the CDP keeping all the details of the original input data. This contrasts with other systems – again including DMPs – that only store selected attributes and summary information such as segment tags.
- Accessible by other systems. Data in the CDP is exposed to other systems for analysis, personalization, and messaging. This contrasts with many products that build a customer database for their own use but give other systems limited or no access to it. CRM systems and marketing clouds often have this constraint.
What’s different from other customer data systems?
As you’ve just seen, that simple CDP definition is packed with differentiators that separate CDPs from similar-seeming products.
- Data Management Platforms don’t store the fine level of data detail, don’t store personal identifiers, and don’t unify disparate identities.
- CRM systems limit the volume and detail of imported data, lack sophisticated identity matching, and constrain external access to their internal data stores.
- Enterprise marketing clouds and suites have been assembled by acquiring best-of-breed products that each has a customer database of its own. Rebuilding them to share a unified, persistent customer database would effectively destroy what their acquirers paid many millions of dollars to purchase. At best, some create a shared ID that can be stored in the component databases. But using that ID to assemble a complete view of each customer is a painful, costly process.
- Integration platforms and hubs don’t build a persistent database and also lack sophisticated identity matching.
- Data warehouses and data lakes are custom-built IT projects that generally take longer and cost more to deploy than CDPs and are often hard to extend as new data sources and types appear.
Is it real?
Just about now, you might be hearing a little voice that says, “This is too good to be true. How can CDPs solve all these problems where other systems have failed?”
It’s a fair question. The short answers are:
- CDPs are purpose-built to assemble and share customer data. Systems like DMP, CRM, and integration platforms were designed with other goals. They’re actually great at what they were built for. But using them as a shared customer database is like using a screwdriver when you need a wrench. You might succeed but you’ll work harder than necessary.
- CDPs benefit from current technology. Most CDPs work on modern “big data” technologies such as Hadoop and Hbase. These are vastly more flexible, scalable, and easier to manage than the relational databases and file systems used by older products. This technology lets well-designed CDPs deliver performance that other systems cannot.
Is it for me?
Few companies have deployed a complete, unified and accessible customer database. But even if you have a customer data problem, that doesn’t mean a CDP is necessarily the right solution. A CDP makes the most sense in situations where:
- You need unified customer data. Arguably, that’s everywhere. But you do need to have a business case that management will accept. For all their advantages, CDPs require a significant investment of time and money.
- You can pay for it. With some exceptions, most CDPs will cost more than $100,000 per year. Your company needs to be big enough to afford that sort of expense.
- Existing systems can feed it data. Physically extracting the data may be an issue with some older systems. But it’s almost always possible to at least generate a daily or weekly extract file. The more likely problem is the data itself is low quality or not gathered at all.
- Existing systems can use the result. Ideally, you’d use the central customer database to devise and execute highly targeted, personalized marketing programs. That requires customer-facing systems such as Web sites, email engines, and mobile apps that can deliver such programs. But, in fact, the most common use of CDP is simply for analysis of customer behaviors. So inadequate execution systems are not necessarily an insurmountable obstacle.
- Your organization will support it. You need senior management to agree to fund it, separate departments to cooperate in giving access to their systems and in using the CDP data, and staff with the skills to take advantage of the opportunities. These are all solvable problems but they need to be addressed before the CDP project begins.
- Realistic expectations. CDPs are not snake oil, but nor are they a silver bullet that fixes all problems at once. Systems must be connected, processes must be created or changed, staff must be trained, marketing programs must be developed, and results must be measured and refined over time. Your CDP project will be executed in phases as new sources are added and new applications are deployed. This takes time and patience.
What next?
If a CDP sounds useful, your next step is to dig deeper. Broadly speaking, you’ll want to identify how you want to use customer data, find the gaps in your current systems and processes that prevent you from doing it, and then look for a CDP or other solution that fills those gaps. This should all be part of a larger project to deploy marketing technology that works well together and supports your larger marketing and business strategies. For all its power, a CDP is still just a tool that only works well if it’s deployed wisely.