We use cookies. You have options. Cookies help us keep the site running smoothly and inform some of our advertising, but if you’d like to make adjustments, you can visit our Cookie Notice page for more information.
We’d like to use cookies on your device. Cookies help us keep the site running smoothly and inform some of our advertising, but how we use them is entirely up to you. Accept our recommended settings or customise them to your wishes.
×

Should I build a CDP, or buy?

An initial key question for many enterprise-level brands is whether to build a CDP from scratch, or whether to buy off the shelf to start with.

Building a CDP yourself allows the creation of a bespoke platform, but this can be lengthy and expensive. Built CDPs can also be difficult to maintain and govern, especially if your business doesn’t have its own inhouse dev team, leading to a potential lack of enhancements over time. Of course, buying can be restrictive and less flexible, but this route allows you to access an out-of-the-box solution that can be up and running and delivering value fast.

To establish which route you should take, you’ll need to ensure you have a full picture of what your CDP will have/should have by grilling your experts internally and externally. You may wish to employ consultants to come in and assess your needs – both current and future. Consultants can also help you to understand the various offerings from vendors, which can be complex and highly varied.

Navigating vendor complexity to buy

Different pre-built vendors offer different things, e.g. core capabilities, activations etc. However, most CDP vendors have a primary focus that can be bucketed into four different flavours:

  • Data CDP (if you can’t identify who should get personalised messages): Gather customer data from source systems, link data to customer identities, and store the results in a persistent database available to external systems. This is the minimum set of functions required to meet the definition of a CDP.
  • Campaign CDP (if you can’t generate personalised messages): Data assembly, analytics, and customer treatments. Treatments are personalized messages, outbound marketing campaigns, real time interactions, or product or content recommendations for individual users.
  • Delivery CDP (if you can’t deliver personalised messages): Data assembly, analytics, customer treatments, and message delivery. Delivery is typically through email, Web site, CRM, or several of these.
  • Analytics CDP (if you can’t predict personalised messages): Provide data assembly plus analytical applications. The applications always include customer segmentation and sometimes extend to machine learning, predictive modelling, revenue attribution, and journey mapping.

There are also CDP vendors who cater specifically for different verticals, e.g. financial services or healthcare.

There are currently over 150 companies claiming to have CDP capabilities, and many are already over-claiming their strengths. Merkle ranks CDPs across five distinct pillars: Activation, Integration, Orchestration, Insights & Data Management. Some platforms claiming to be a CDP can only function across two or three of these areas.

Many vendors position themselves as the panacea to marketers’ problems; fixing syndication match rate issues, offering machine learning and automation - and all in a GDPR/CCPA friendly way! Whilst this is true in some instances, in other cases it includes some substantial overclaim.

Is a build less risky?

Does that mean that building a CDP instead is a less risky option? It’s certainly true that a built CDP should meet all your organisational needs, at least where data integration is concerned (built CDPs tend to solely focus on the data linkage side, rather than the campaign, delivery or analytics elements described above). Many organisations then buy tools to allow their marketers to work with their built data CDP, coupling on campaign, delivery and analytics capabilities out of a box. Before pursuing this route, it’s worth evaluating whether this still represents a more cost-effective option than buying a pre-built package.

Building a CDP can also be used successfully as an interim proof of concept measure – linking up data (work that would often need to be done anyway before deploying a bought CDP) to demonstrate the effectiveness of a proto-CDP, before potentially going on to buy an out-of-the-box solution once a business case has been established.

The drawbacks of the build approach

There are definite points against building a CDP as a permanent solution, however. Inhouse builds can fight for resource availability and clash with other projects, causing delays. You are also likely to find that the final solution closely replicates something out there in the market that can be purchased, so varied is the current vendor offering.

Built CDPs can struggle to keep pace with innovation, such as a new social media channel being launched; whereas a CDP from a vendor should work to connect new channels much faster as they’ll be doing so for all their clients and can afford to rapidly work out integrations.

How can you decide? We’d suggest as a starter that you consider what channels are involved in your customer experience. Next you should assess what measurement needs you have. Finally, you’ll need to think about what existing tech you are using, and look at how it will connect (for example think about your tools for decisioning, adtech, martech, sales & service and so on).  It’s a complex world though, so don’t be afraid to reach out to experts in order to make overall progress faster and ensure the speed to value for your solution is high.

Join the Discussion