Part Eight: Buying a CDP Today

This post is part of the CDP 2.0: Why Zero-Waste Is Now series. For the best experience, we recommend starting with the Introduction and reading each chapter in sequence.

The good news for marketers is CDP commoditization means there are a lot of good options.  The bad news is commoditization has resulted in positioning chaos amongst CDP vendors. E2E (packaged) CDPs, composable CDPs, infrastructure CDPs, application CDPs, all flavors of integrated CDPs  (CEP, CRM, analytics vendors), clean room CDPs, just to name a few. In this regard, it has never been harder to understand which option is the most appropriate for a customer’s specific needs.

While every CDP type has its virtues and shortcomings, our view is that the customer’s context matters most. With this in mind, we take a look at the major CDP types and discuss when each option may be appropriate.

As discussed earlier, built-in CDPs are CDP capabilities which are offered as part of another marketing tech platform, most commonly customer engagement platforms (CEP), CRMs, or analytics providers.

Built-in CDPs will be attractive for marketers with limited CDP use cases—i.e., they are only sending data to a handful of well-known platforms, do not require coordination between multiple channels, have limited number of audiences, a single marketing team, do not have complex identity challenges, etc. The one notable exception to this will be teams who expect to deploy multiple martech tools in the near future, and want a CDP to enable easier deployment of these.

The benefits for built-in CDPs are pretty straightforward. Buyers will have one less vendor to manage. For marketers who are using one CEP or CRM for their journey activations, an integrated CDP will fit easily into their current workflows.

For CDP buyers with more complex use cases, built-in CDPs will pose significant challenges. Primarily, if the customer decides to use a different CRM/CEP/analytics platform, they will be impaired by their CDP use (and lack of a pure play CDP!). While this is not often the case for small marketing teams, larger organizations with brand or regional considerations will benefit from a pure play CDP, which will enable high quality integrations to multiple platforms, which may be competitors to each other. Built-in CDPs will find navigating this situation difficult.

Some specific capabilities where a built-in CDP not have feature parity with pure play CDPs:

• Advanced identity resolution
• Zero-copy capabilities
• Low latency coordination across multiple systems
• Ability to handle large event volumes and anonymous data
• Governance and consent management
• High-quality integration with other marketing technology platforms (which are often competitors)

Generally, integrated CDPs are attractive to small-to-medium-sized marketing teams, who do not have sophisticated identity or real time needs.

For many years, the calculus of whether to build or buy a CDP came down to the issues of not build vs. buy, but rather build vs. maintain. This was largely due to the instability of many public marketing APIs, which could change fairly dramatically with little notice. Fortunately, those days are largely in the past, with most major APIs being well-documented and maintained.

The calculus has changed in the last few years, not only due to API stability, but a whole host of tools which enable CDP functionality. The big question to consider is, are the CDP needs fairly basic and moderate/low-scale, or will they need to tackle "the big CDP problems?" If the latter is the case, it is not advisable to DIY, as this gets into specialized CDP architecture and use case development, which can greatly tax IT groups. Aside from supporting today’s use cases, you will be committing to a roadmap for your marketing teams.

However, not all marketers need advanced CDP capabilities. If identity needs are straightforward, audiences do not need high refresh rates, and platform integrations do not need "the latest and greatest" functionality, building CDP capabilities in-house can be viable. For their part, CDWs offer a collection of CDP capabilities that can be fashioned into a “fully functional" CDP. Reference architectures have been readily available for DIY efforts for several quarters. It should be noted that customers directly building their own fully functional CDP on these services do not appear to have widespread traction. Systems integrators are offering CDP capability extensions to their CDW practices, which is not precisely DIY, but is the likely path for using CDW embedded CDP services. Whether this effort gains traction depends on whether a practical service model for maintaining and upgrading such a platform emerges.

Another DIY approach is using composable CDPs to add reverse ETL (rETL) capabilities, then basic CDP functionality. With attractive price points and relatively easy deployment for rETL, these are good options to explore DIY. The main downside to this approach is the "surprise cost" profile if low latency performance is required. Any DIY effort should run sufficient load tests to understand how these costs can scale CDW compute. Additionally, as relative newcomers to the CDP space, they lack marketer fit-and-finish of established CDPs, requiring IT teams to commit to supporting new use cases. If there are multiple marketing teams using the CDP, this can become overwhelming.

Warehouse-native CDPs have a couple of contexts where they are strong fits. As mentioned in a previous section, DIY CDP efforts can greatly benefit from warehouse-native CDPs. They are excellent as reverse ETL tools. They also typically have lower price points for simple use cases, as they do not bear the burden of processing costs.  

Data engineering teams also have strong preferences for warehouse-native CDPs from the standpoint of supporting their CDW efforts, especially in the governance and quality aspects. If an environment has strong quality and governance characteristics, warehouse-native CDPs will inherit these characteristics, as their architecture is a CDW overlay.  

Another attractive feature of warehouse-native CDPs is the ease of which new columns in the CDW can be ingested into the CDP. Established CDPs also have the ability to quickly inject new data, but the CDW use cases today are not as clean as warehouse-native ones. We expect this gap to close in near future, as it is clearly a needed use case for marketers.

There are a number of contexts where warehouse-native CDPs can present challenges. The largest one is their "hidden costs" quality, especially if customers need low latency audiences or data forwarding. These types of CDP compute tasks can get very expensive, very quickly, even in optimized CDW environments. This differs from established CDPs, which have purpose-built architectures and have transparency around real-time feature costs.

Another consideration is how ready the CDW data is for CDP applications, specifically sophisticated ID handling. If it is not, it is very likely that considerable engineering efforts will be required before warehouse-native CDPs can be implemented.

On the data quality and governance front, if an environment is having challenges in these areas, warehouse-native CDPs are sometimes positioned as "part of the cure."  Warehouse-native CDPs usually cannot improve these issues, their "inheritance" quality goes both ways. As we discussed in the Data Quality section, they have some attractive attributes in these areas, but whether they are a better solution for improving quality and governance over established CDPs is highly context-dependent. Generally, companies which have a high level of data maturity, quality, and expertise in place are better candidates for composable CDPs.

Finally, the flexibility of warehouse-native CDPs does come at a cost. Essentially, data engineering will need to be prepared to support all future marketing use cases. These efforts may be manageable for a small number of marketing personnel and/or brands, but will become a substantial burden in more complex environments. The undesirable outcome if this happens is both marketing and data engineering teams will be slowed down.  

The ideal contexts for warehouse-native CDPs are:

• Environments with small or medium marketing teams.
• Do not require real-time audiences or data synchronization.
• DYI CDPs efforts in "clean" environments with sufficient data engineering staff.
• Environments without sophisticated identity requirements.
• Use cases which are met sufficiently by reverse ETL tools.
• Organizations with unlimited budget and/or excess engineering capacity.

The primary difference between established CDPs and alternatives is the marketer-first approach. While data engineering considerations are certainly important, the value of CDPs is primarily driving business results from leveraging customer data to solve marketing problems. Materially, this manifests itself in three important ways.  

First, established CDPs have customer success teams, who are highly knowledgeable in marketing challenges, and often specialize in verticals. They can offer advice and consultation on the various marketing tactics and strategies.  

Secondly, established CDPs will offer high-quality integrations for key platforms, which exceed minimal-viable-integration levels often found in integrated and composable CDPs. For power users of these integration partners, this is a very important issue, and can make or break the CDP as a practical solution.

Most importantly, established CDPs have marketing friendly fit and finish. In product terms, many of the features are designed using well-understood user preferences of marketers. This lowers the learning curve for new users, improving their ability to self-service. This becomes essential in environments with multiple marketing teams.

There is a sentiment that composable CDPs will "close the gap" with established CDPs in this area. This assumes that established CDPs, with their large customer bases, will not continue to innovate as quickly as composable CDPs, despite greater visibility into the latest marketing use cases. (Interestingly, this gap-closing sentiment does not seem to get extended to established CDPs in regards to zero-copy, who will certainly close the gap in the coming quarters.)

One of the major misconceptions of established CDPs is a quality of being "rigid." They offer a number of customization options, especially the ones with sophisticated identity solutions. There is a level of prescriptive frameworks developed with customers input over many years. These are designed to address the majority of marketer use cases out of the box. This enables ongoing customization requirements to be less than other approaches. Properly regarded, there is a balancing act between maintainability and customization—pinning established CDPs to one end of the scale is to ignore important trade-offs.

From a cost perspective, established CDPs are more transparent than other approaches, especially composable ones. While there will always be some uncertainty around CDP costs, given the nature of the customer events and data, established CDPs do not have a "hidden cost" element of composable approaches, which shift compute costs to the customers’ CDW. While this is not materially at small numbers of audiences or at high-latency synchronization (>24 hours), they exhibit exponential cost profiles as use cases approach hourly latency requirements.  

Looking forward, leading established CDPs will leverage generative AI to automate many of the marketing tasks. In this regard, they have a significant advantage over alternatives who are more IT-focused. Vertical expertise will be extremely important in the product development area, as access to specialized use cases will be a determinant on which vendors can differentiate in a meaningful way.

The main drawback of established CDPs is they can be overkill for marketers who have limited use cases. Integrated CDPs, reverse ETL tools, or even DIY solutions are often appropriate for these buyers. Another area where alternatives are attractive are data infrastructures with existing high quality and governance characteristics, and do not have large marketing teams.

The ideal buyer of an established CDP:

• Has multiple marketing teams, brands, and/or regions.
• Can use the support of experienced customer service teams.
• Has real-time requirements for audiences and event synchronization.
• Needs specific high-quality integrations.
• Needs cost predictability.
• Will benefit from ML/AI automation of common workflows in their verticals.

mParticle is a marketer-focused CDP, which is focused on two areas of innovation: to enable marketers with generative and analytical AI capabilities, and to empower zero-waste performance, including compute cost optimization.  

As discussed earlier, we are tackling the "big problems" of the CDP space. These efforts will be underpinned by our existing real-time identity and optimized data processing capabilities.  

By definition, mParticle is fully composable in both our deployment and our pricing model. In effect, we strive to offer the best of the two major CDP modalities for one purpose: to solve our customer marketers problems with data.