In recent years, marketing departments have taken increasing responsibility for their own technology. In most ways, it’s a win-win situation: marketers get the systems they want, and IT departments get to focus on other projects.

The downside has been proliferation of disconnected marketing systems. That really becomes a problem when marketers want to deliver a unified customer experience, which requires the systems be connected. At the minimum, they need to feed data into a shared database, link information about each person into a single customer view, and make the unified data available to other marketing systems for analysis and interactions. Building and running that sort of unified system is well beyond the technical capabilities of most marketing departments. So marketers have needed to ask IT for help or use external vendors. Both options are likely to be costly and time-consuming.

But another choice has now emerged. Systems called “customer data platforms” (CDPs) have been developed specifically to solve the customer data unification challenge. Technically, most CDPs use the same data stores as a data lake or data warehouse: SQL, Hadoop, MongoDB, etc. They also draw from the same pool of identity matching techniques and on standard methods to acquire and distribute their data: APIs, database queries, and batch file extracts.

What’s new about CDPs isn’t the technology, but the fact that vendors have assembled the technology into packaged software. Of course, software packages are not a new idea – IT professionals have been making build vs buy decisions for as long as they’ve had computers. But packages to assemble, manage, and expose a single customer view are new.

Before CDPs were introduced, companies had to custom-build a single customer view by stringing together commercial products and hand-coding any missing links. Like any custom development project, this usually took longer and cost more than expected, delivered less than sponsors hoped, and needed updates the day it was delivered. The CDP offers a productized alternative.

How big is the need? Surveys consistently show the vast majority of marketers feel they need a single customer view (and the capabilities it enables) while a tiny minority actually have one. Here, for example, are figures from Econsultancy.

And how does a CDP fill the need? As we just discussed, it’s packaged software doing what packaged software always does: make it easier to deliver standard solutions to common problems. Specifically, a CDP is a marketer-managed system that creates a persistent, unified customer database and makes it accessible to other systems. The key elements of that definition are:

Marketer-managed: CDPs are departmental solutions, typically bought and managed by marketing operations teams (usually with a little technical help from their friends at the vendor). It’s true that the resulting customer database could be used throughout an enterprise. It’s also true that some CDPs are bought by IT departments and used as enterprise systems. There’s nothing about CDP technology to prevent this, and CDP vendors certainly welcome such clients. But the departmental focus narrows the set of stakeholders involved in CDP deployment, enabling CDP systems to get delivered without the scope creep that often strangles enterprise warehouse or data lake projects.

System: the CDP is a packaged software, not a collection of components that must be assembled like some especially frustrating IKEA cabinet. CDPs are designed around core objects including customers and interactions. Users can customize these objects and add others, but knowing the basic data structure in advance lets CDP developers build standard functions and process flows using that structure. Prebuilt connectors for common data sources and client systems further speed deployment. And although CDPs vary, many can be configured extensively without custom development.

Persistent: the CDP isn’t simply an access tool that reads data directly from source systems and unifies it on the fly; nor is it an integration hub that moves data between systems to enable integrated processes. Those approaches can’t easily support key marketing requirements such as tracking customer identifiers over time, monitoring behavior patterns, calculating trends, or aggregating lifetime results. Source systems often don’t keep all the data needed for those tasks, and, even if they did, it’s often not possible to query the source systems, unify the data, and do whatever calculations are needed in time to support real-time time marketing activities such as personalized a Web site message.

Unified: the CDP must identify data from different sources that relates to the each individual. The challenge is that different systems often use different customer identifiers: an email address here, an account number there, phone number somewhere else. Unification processes may include deterministic linking (where two identifiers are directly connected, such as an email address and telephone number on the same account profile) and probabilistic linking (where similar data or behaviors suggest that two identifiers probably belong to the same individual). Some CDP vendors have built their own unification processes; others use third party systems; many use a combination of both. Identity resolution is probably the most technically challenging of all CDP functions; as such, it’s where CDPs offer the most productivity gain over custom development.

Database: the CDP stores raw data, such as individual transactions or Web behaviors, so the details are available if needed. This requires more complicated data storage than simply attaching attributes to a profile. In practice, most CDPs will also process this data to create scores, tags, aggregates, indexes, and other features that make it easier to meet predefined requirements. Doing this efficiently and quickly – and easily adjusting to changes – is another set of technically demanding tasks that CDPs do so IT departments don’t have to. To be clear, CDPs don’t need to ingest all the data they use. It’s sometimes better to access data from source systems only when needed. This commonly applies to information that changes rapidly or is needed rarely, such as account balances, locations, and weather conditions.

Accessible to other systems: CDP data isn’t reserved for use by the CDP itself, the way data is often locked in packaged software. There’s usually an API, although sometimes access is through queries or file extracts. Many CDPs provide real time access for support customer interactions, although it isn’t an absolute requirement. Many CDPs create extract files, subsidiary databases, or summary tables that let external systems use their data without accessing the underlying raw data directly,

It’s important to note that many CDPs include application features such as predictive analytics or message selection. Marketers often purchase the CDP primarily to use these applications, since they give an identifiable financial benefit that helps to justify the purchase. CDPs also vary widely in other ways, such as pricing, internal technology, deployment model, and vertical industry specialization.

The range of products that qualify as CDPs can be perplexing to potential buyers, but it ultimately improves their odds of finding a system that fits their needs. Keep in mind the core benefit of the CDP – it avoids custom development of a unified customer database – and you’ll remember why it’s worth the trouble.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access