The Real Story on MarTech: Should you build or buy a customer data platform?

“Build versus buy” in the context of technology marketplaces is a long-running debate. At Real Story Group, we see this debate getting revisited for marketing tech stacks, particularly for customer data platforms (CDPs).

Is there a single right approach? I don’t think so, but the details matter here.  So let’s dig in.

Build vs. buy

Traditionally, two main approaches for obtaining enterprise functionality have been:

1. Buying an off-the-shelf package and then customizing it for specific needs.
2. Building a platform in-house, specifically for your requirements, sometimes via packaged piece parts.

Both approaches have valid rationales, and over the past two decades as an industry analyst, I’ve seen this choice emerge in pretty much all technology marketplaces. However, the boundaries between build and buy in CDPs can become fuzzier.

Part of the challenge is that packaged CDPs can vary substantially in scope. Some have great vertical depth, reaching back into the enterprise to perform upstream data processing or extending forward to the engagement tier to provide real-time interaction. Some packaged CDPs offer lateral services around orchestration, campaign management and even outbound messaging.

So before deciding on the right approach, it is important to answer what a CDP will do specifically for your enterprise.

What does a CDP do (for you)?

The model shows different stages in a data life cycle, regardless of specific technology platform. Your customer data probably goes through all these stages:

1. You need to obtain data from various online and offline data sources before you can do anything with it. Therefore, you need some mechanism to ingest data, clean it, perform some transformations and aggregation, and ensure quality.
2. Once the data is collected or ingested from different sources, you need to tie it to user profiles. That includes activities such as identity resolution and profile unification. You also enrich your profiles with additional data while ensuring data governance and compliance.

In a larger organization, these two initial phases typically transpire within part of a broader enterprise data “fabric” or “mesh.” The typical enterprise already possesses data management tooling to handle these services – like data lakes, warehouses, ETL tools, quality and governance, etc. – and applies them to customer data. However, as we’ll see below, many packaged CDP tools also provide some of these services. In any case, enterprise IT and Data teams become important stakeholders in these first two stages.

• The next stage is where you use all this cleaned-up, aggregated, unified profile data for your business objectives. For example, now that you have profiles or 360-degree views of your users or customers, you can segment them based on different attributes. You can slice and dice the profiles, create cohorts, group similar data, create audiences and so forth – and then, critically, activate that data through various channels.
• This stage is the last mile where you engage with your customers via ecommerce, email, web, mobile, chat or other channels, using personalized content and product recommendations.

You see considerably higher marketing and customer experience teams’ involvement in these latter two stages.

In theory, all these services can be potentially addressed by a CDP. You will often find CDP vendors boasting they can perform all these stages equally well.

In practice, though, we see several variations of this model. See, for example, the different scopes for Company A, B and C in the diagram. Rarely do large, complex enterprises deploy a single platform for all these stages. There are at least two reasons for that:

1. As you can see, the overall potential functionality is quite broad, and large enterprises already have existing initiatives outside of CDP for several of the stages (or functionalities within those stages) identified above. These functionalities often include data pipeline management, machine learning ops, and identity resolution, to name just a few.
2. Despite what vendors claim, the truth is they are never equally good at all these stages. They can usually do only one or two of these stages well.

Therefore, where a CDP fits in your martech stack could differ from where it fits for another company. This then affects any build versus buy decision since the question initially becomes: build or buy precisely what? Even if you license an off-the-shelf CDP for some functionality within the model above, you will likely build extensions for missing capabilities.

So the first lesson: you will likely do some build and some buy, regardless of the overall strategy. The question then becomes: in what proportions?

Assembling from piece parts

One approach potentially open to you is assembling components to build CDP capabilities instead of developing from scratch or buying a more wide-ranging, general-purpose CDP off-the-shelf.

This approach has some appeal because you may already possess some powerful data management capabilities as part of your broader customer data fabric.

You can also license specific products for these different functionalities. Several vendors offer components for such functionality. For example:

• Data ingestion: There are specialized data ingestion vendors and modules from CDP vendors themselves. Vendors such as Stitch (acquired by Talend), Snowplow, Fivetran, Matillion and others provide modules for data ingestion, data pipeline management, transformations and other relevant functionality.
• ETL and ELT: Many vendors target Extract-Transform-Load (ETL), Extract-Load-Transform (ELT) and Reverse-ETL/ELT for different types of transformations that you can do with your raw data. Examples of vendors in this category are Hevo Data, Hightouch, DBT and Census.
• Data warehouses and Data Lakes: Several data warehouses and data lakes, including Snowflake, Google and others, include data management and processing functionality. Many packaged CDP architectures already assume that source data will come from this environment.
• “Virtual” CDPs: Some vendors, such as Aqfer, Rudderstack, and some other players, offer some services for cobbling together a CDP with a decoupled data layer.
• Identity Resolution: Several vendors target identity resolution. Many CDPs have now given up their own identity resolution efforts, and are instead of partnering with vendors such as Neustar, Infutor,  LiveRamp, and others.
• Engagement: The marketplace for engagement-oriented products remains quite vibrant. You can find many point solutions that target journey orchestration, campaign management, personalization, recommendations and other engagement use cases. Several packaged CDPs are also strong in this area.

This isn’t an exhaustive list of services, and you can find many other specialized vendors (e.g., those providing governance solutions). The key point is that it is possible to assemble these services to have a composable data ecosystem instead of doing everything using a single CDP.

Dig deeper: Deep changes in the CDP space

What you might miss

By now, you’ve probably figured out that a couple of key CDP services are missing from that list above: business-friendly segmentation and activation. These are more challenging capabilities to purchase off the shelf, and at RSG, when we’ve seen home-grown CDPs, typically, the enterprise will build these business-user interfaces from scratch. When we hear enterprise developers arguing, “let’s just employ our data warehouse as the data layer instead of a CDP,” this is typically where they are headed.

I would caution you about this approach, though, because custom segmentation and activation tooling could prove fragile, and advanced UX design is a big part of what you pay for in a CDP (though to be sure: not all CDPs are equally good at this).

What you should do

Recognize that your CDP effort will undoubtedly include some measures of both build and buy. It’s just a question of proportion and location. Even if you license a packaged CDP – and there are good reasons to do so – you will need ample development work to stitch it into the rest of your customer data fabric, let alone your front-line engagement systems.

The jury remains out on a single best approach for this, but design patterns are emerging. Consult this briefing for more details.

In the meantime, as you look to build your customer data management muscles over the next year, keep your data scientists close but your developers even closer.