place should a CDP be in your martech stack //

Any customer information platform (CDP), must fit seamlessly into your martech stack. There are many options, and you don’t have to make the same architectural decisions twice.

Real Story Group has seen three main approaches to storytelling, with variations of each.

• Licensing a CDP in your anchor martech suite.
• Deploying the best-of-breed CDP
• Use components to create the CDP functionality. (I’ve already discussed the third approach in an older article. But I’ll go into more detail here.

These approaches are not mutually exclusive. An enterprise may choose to use a combination approach in some cases. They offer a valuable contrast, so let us dig deeper.

Approach 1: CDP starting from an anchor suite

Many suite vendors, including SAP, Adobe and Oracle, Salesforce, Microsoft, offer broad marketing suites that can be licensed with an optional CDP.

I can understand the temptation on the buyer’s end. Is it not possible to simplify the decision? This approach is also supported by analysts and consultants.

We have found many bad-fitting solutions that were based on casual CDP selections. These are some possible reasons.

• Remember that most major martech vendors have largely gathered their suites through acquisition. The evolution and genesis of their CDP offerings is primarily to integrate all the acquired products.
• These vendors may have a questionable track-record in maintaining positive relationships with your martech team.
• These CDPs tend not to mature.

It’s okay to consider a CDP add-on from a suite vendor. It’s important to choose it based on its merits and not because it is from an incumbent supplier.

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

Step 2: Install a best-of breed CDP

There are many specialized CDPs on the market. CDPs offer a broad range of functionality. This makes the market wide and fragmented. There are many approaches to feature sets, architectures, and pricing.

There’s a good chance that you will find the perfect-fit package solution. This is always a benefit. Remember, however, that even a best-of breed CDP will require someone to do a lot integration and development.

Approach 3: Assemble the components

You can “compose” your CDP with other components, instead of buying a pre-made CDP. Many enterprises have a data warehouse (DWH), and/or a data lake. Instead of copying data from a DWH to a CDP, why don’t you use your DWH instead?

A DWH is not a CDP so you will need other components to create a CDP-like layer. To pull data from your DWH, and push it to activation channels, you will need a reverse ETL tool.

However, this is not enough. Other capabilities would also require components that are not provided by a CDP.

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

You may not require all of these features, so you are able to pick and choose what you need. Keep in mind that you are creating software here. The business stakeholder may find what’s appealing for the developer to be sub-optimal.

Some CDP-by assembly proponents have even claimed that CDPs are dead, and that this is the only approach. I disagree. All three approaches have their place.

Composability as an element of a spectrum

Modern martech stacks can be described as “composable” by their very nature. The granularity and composability of a product increases as you move from “suite bolt ons” to “packaged top-of-the-line” to “componentized” (and possibly beyond to complete DIY).

As the granularity of your data increases, you will see an increase in functionality and capabilities. However, the benefits of having more composability will decrease in terms out-of-the box functionality. But you can still get a better solution if you are more focused.

What are the tradeoffs?

This market is not one-size fits all. There are always tradeoffs.

You can create a custom-built solution to meet your needs, while making it easier to start.

However, your requirements change and new requirements are added to the stack, so you’ll need more components and spend more time and money to create something that is not available in a best-of breed tool. As your requirements and components grow, so will the complexity of the stack.

What should you do?

This figure provides guidance for choosing the best approach for you. This diagram outlines the trade-offs that each approach can make to improve your stack’s complexity, fit for purpose, functionality and ease of implementation.

Each approach has its own pros and cons. The best-of-breed CDP supports a wide range of use cases, and allows you to gradually increase support for other use cases.

You can create something unique to meet your specific requirements using the “componentized” approach. It might be simple to get started (“We can get your data directly from Snowflake and have it sent to your email address in just 5 minutes”) As your requirements get more complex, you will need more pieces to make your stack more complicated.

Again, there are no easy answers.

MarTech.