Understanding customer behavior over time and across channels is the holy grail of modern business, and there’s no shortage of commercial solutions aimed at meeting this need. Yet some companies take a crack at building CDPs themselves. Before rolling your own customer data platform, it’s important to understand all of the CDP’s moving parts.
The challenges of crafting your own CDP
Many customer data platform initiatives start off as homegrown proof of concept or “POC” projects. When such projects are driven by IT or engineering departments, there’s a major emphasis on the “data platform” component. Therefore, I often observe fledgling CDP projects kick off as data models.
These data model POCs may live in a transactional database or perhaps a data warehouse. There’s usually a star schema of sorts, whereby each unique customer is linked to many different attributes. Attributes may include personal information, past purchases, and web browsing history. I’ll concede there is some value to such a data model. However, we quickly hit limitations with a data model-based CDP due to several factors. First, the model has no intelligence. Let’s say you work at a B2B software company, and Cisco is one of your customers. What happens when this CDP data model shows three different customer records for Cisco? For example:
- Cisco (sourced from the sales CRM)
- Cisco Systems (sourced from the support system)
- OpenDNS (a subsidiary of Cisco, currently a lead in the marketing system)
Without some degree of data intelligence, this scenario may present Cisco as three discrete companies. This leads us to our second challenge: the CDP data model approach is a purely analytical construct. While “interesting” to review within a tool like Tableau, the insights and key facts from this model need to propagate back into systems of record. As an example, let’s take the case of a sales account executive who wants to track product usage to ensure adoption and prevent churn. These sales reps likely live in Salesforce, so how do the CDP facts and insights make their way from the data warehouse to operational systems like Salesforce? Without custom data integrations, this CDP remains as isolated as a distant island.
The anatomy of a CDP
A real world CDP is far more complex than a logical data model. In order to appreciate the value of a CDP’s capability, it helps to understand the full spectrum of CDP functionality. Some key components of a CDP include:
- Data collection – the ability to collect user data from a variety of sources
- Data storage and manipulation – the organization, cleansing, and transformation of data
- Business logic rules, of which there are many:
- Data onboarding and activation – the logical coalescing of similar data from different systems.
- Insights – user engagement patterns, trends, and opportunities for optimization
- Identity resolution – retroactive conversion of previously unknown, anonymous user IDs to known users
- Cross device identity management – Most users span the customer journey over two or more devices. Connecting the dots, either probabilistically or deterministically, is key to analyzing user behavior across devices.
- Operational data integration – The backpropagation of CDP insights to operational systems; also known as reverse ETL.
From massive amounts of code that power business logic to fundamental data plumbing, the value chain of a CDP consists of many complex components. Before jumping headfirst into a custom CDP adventure, consider the work required to enable such functionality.
Lead with specific CDP use cases
It’s okay for a CDP to be use-case-based. In other words, a fine cutting tool to solve a finite set of problems versus a Swiss Army Knife which doesn’t do any one thing particularly well.
Some common use cases for a CDP include:
- Analyzing product usage to detect and prevent churn
- Cross selling and upselling to existing customers
- Personalizing user content across channels
- Building lookalike account-based marketing (ABM) models for lead generation campaigns
There are plenty of others to call out. However, they key point is to have specific use cases for specific enterprise users.
But a CDP should be an enterprise capability!
If an initially departmental-focused CDP can evolve and be reused across the enterprise, that’s wonderful. Yet one should think of a CDP deployment as a highway scoped project with potential to evolve into the Autobahn. Not the other way around.
There’s a reason why solutions like Segment and Gainsight are so popular. They solve immediate pain points for specific business users. For IT leaders and enterprise architects, the strategy should be one of land and expand: build the CDP roadmap so that immediate problems in sales or marketing are solved, then eventually scale to accommodate customer support, the chief revenue officer, and others.
Summary points
A CDP is more than a mere data model; It’s a capability. It obviously requires software, mostly likely of the commercial variety. As noted above, the vast array of CDP features would likely take years for an in-house software team to build.
A capability also requires people and processes. As for the duplicate Cisco account scenario described above: how accounts are merged (and potentially written back to source systems) is a pattern we’ve seen in the master data management space for years. As we all know, this is more of a business problem than a technology feature. Believe it or not, some companies commence their CDP journey by first defining what a customer is! So, be prepared to identify who makes these decisions. In other words, you’ll need an operational business team to manage your CDP; not just a cluster of IT folks.
Finally, build-versus-buy isn’t really a binary decision. In most situations, a commercial solution should form the core foundation of a CDP. Yet this doesn’t preclude customers from bolting on custom logic via homegrown satellite solutions. Examples include advanced AI modeling or data enrichment solutions.
