Where should a CDP fit in your martech stack?

Any customer data platform (CDP) must nestle nicely into your martech stack, including your customer data ecosystem. Like many architectural choices, you face few absolute rights and wrongs here, but you have options worth considering. 

At Real Story Group, we’ve seen three broad approaches, including variants of each:

• Licensing a CDP from your anchor martech suite.
• Deploying a best-of-breed CDP.
• Using components to build requisite CDP functionality. (I explored the third approach in an earlier article, but I’ll expand further here.) 

Of course, these are not mutually exclusive. In some cases, an enterprise will want to take a hybrid approach. Nevertheless, they provide a useful contrast, so let’s dig deeper.

Approach 1: CDP from an anchor suite

Many suite vendors — SAP, Adobe, Oracle, Salesforce and Microsoft — sell broad marketing suites supported (to varying degrees) by an optional CDP they fervently wish you to license. 

On the buyer’s side, I understand the temptation. Why not try to simplify the choice? Some consultants and analysts push this approach, too.

Our research suggests otherwise, and we have seen many poor-fitting solutions based on a casual CDP selection. Here are a few possible reasons.

• Recall that major martech vendors have mostly cobbled together their suites via acquisition. Thus, the genesis and evolution of their CDP offerings are foremost to integrate all those acquired products. 
• These vendors have in some cases a questionable track record of sustaining a positive relationship with your martech team.
• These CDPs tend to remain comparatively immature.

There’s no harm in considering a suite vendor’s CDP add-on. But make sure you select it on its merit and not because it comes from an incumbent supplier. 

Dig deeper: Customer data platform (CDP) buyer’s guide

Approach 2: Deploy a best-of-breed CDP

There are dozens of specialized CDPs in the marketplace. CDPs can provide a wide range of functionality, and consequently, the market is wide, fragmented, and characterized by many different approaches to feature sets and architectures. 

So there’s a good chance you can find the right-fit packaged solution, which is always a boon. Do remember, though, that even with a best-of-breed CDP, someone will likely have to perform a lot of development and integration work. 

Approach 3: Assemble components

Instead of using a packaged CDP, you “compose” your CDP using other components. Most enterprises already have some sort of data warehouse (DWH) and/or data lake. So instead of copying that data over from a DWH into a CDP, why not use your DWH as your CDP?

Of course, a DWH is not a CDP, so this approach requires other components to build a CDP-like layer. At the very minimum, you’d need a reverse-ETL tool to pull data out of your DWH and then push it to activation channels.

But that’s not sufficient. You’d also need components for other capabilities that a CDP provides: 

• Data ingestion.
• Identity resolution.
• Data quality management.
• Marketer-friendly segmentation.
• Triggers.
• Activation
• And, potentially, orchestration. 

Now, you may not need all these, so you can pick and choose to build exactly what you need. Remember that, to some degree, you are building software here. What’s interesting for the developer may prove sub-optimal for the business stakeholder.

Some proponents of this CDP-by-assembly have gone to the extent of claiming that CDPs are dead and that this approach is all you need. I disagree. There is a time and place for all three approaches.

Composability as a spectrum

By nature, modern martech stacks are “composable.” I believe that the three approaches above really represent a spectrum of composability. As you move from “suite bolt-ons” to “packaged best-of-breed” to “componentized” (and maybe even beyond to complete DIY), the granularity of composability increases.

Initially, as the granularity increases, you get more in terms of functionality and capabilities. But a further increase in composability only brings diminishing returns in terms of out-of-the-box functionality, albeit with a more purpose-built solution.

What are the trade-offs?

There is no “one size fits all” in this marketplace, and there are always trade-offs. 

Componentization allows you to build a more purpose-built solution that may better fit your current needs while potentially quicker to get started.

That said, as your needs evolve or new requirements are added, you will likely need additional components and invest more time and resources to build something that is probably available as out-of-the-box in a best-of-breed tool. Consequently, as your requirements and components expand, the complexity of the stack will also increase. 

How should you decide?

The figure below provides a framework for deciding which approach is more suitable for you. It describes various trade-offs and how each of these approaches can impact your stack complexity, fit to purpose, range of functionality, total cost of ownership and ease of implementation. 

You can see each of the approaches has its pros and cons. A best-of-breed CDP provides support for a broad range of use cases and allows you to scale up to add support for additional use cases gradually. 

The “componentized” approach allows you to build something specific to your current requirement. It may be easy to start with (“We can get your data from Snowflake and send it to your email platform in 5 minutes”). But as your requirements become more sophisticated, you need more piece parts, making your stack even more complex.

So again, there are no pat answers here.