The Real Story on MarTech: Beware ‘Roof Rack’ CDPs
Why there's real value in independent CDPs.
A couple week’s ago in RSG’s inaugural MarTech column, I made the case for refactoring your MarTech stack to focus on lower level “Foundational Services.” Today let’s dig deeper into what that means for your manifold customer data platform technology choices.
CDPs have become popular for good reason: they try to address chronic difficulties marketers have endured around obtaining reliable access to a centralized store of information about customers and prospects.
The CDP technology marketplace has expanded substantially. At Real Story Group, we evaluate thirty players, with more each quarter. This marketplace fragmentation stems partly from initially low barriers to entry, partly from large martech vendors arriving late to the party, and partly from a rising tide of enterprise demand lifing a lot of boats.
That demand has also lured vendors of adjacent technologies into arguing that their data management subsystems are also CDPs. How’s a buyer to suss out what’s real, and more importantly, what’s ideal? I believe there’s a car-versus-roof-rack issue here.
What’s a CDP?
The Customer Data Platform Institute, an industry trade association, offers a useful functional definition.
“A Customer Data Platform is packaged software that creates a persistent, unified customer database that is accessible to other systems.”
This definition helpfully excludes the kinds of inadequate systems you had to endure before the advent of packaged CDPs, such as fragile consultingware, or developer-oriented integration layers, or marketer-unfriendly data lakes. At the same time, this definition allows for a wide scope of potential CDP suppliers. How much does that matter?
Going back to the original reference model that stresses a foundational services layer, one area matters a lot: how your CDP does or does not get coupled to a different technology service in a way that reduces its effectiveness in the long run.
Value of CDP independence
Purchasing discrete technology individually, versus as part of a larger, more complex commitment, is not a new dilemma in the martech world. The correct answer to this conundrum is always, it depends. In some cases, it may become tactically convenient to couple CDP services with other technology investments in order to speed an initial implementation or simply shorten your decision-making.
Nevertheless, I’ll argue that a core value proposition for CDPs comes from decoupling data services from customer engagement and management systems. Customer channels come and go. But first party data is gold, and needs to get stored and managed accordingly. Larger enterprises in particular will want to avoid getting bound to a bundled stack of services that mitigates against the independent value of that customer data.
Also, you risk buying CDP technology from a vendor for whom data management is a second-order concern, rather than primary focus. Your data broker (see next section, below) wants to sell you data; any CDP they bundle will focus first and foremost on ingesting and managing that acquired data, even as your data activation needs to diversify going forward.
Look, it’s a CDP!
Here’s a short tour of other vendor segments incorporating customer data platform services into their incumbent environments, and why you should remain skeptical of each.
Data Brokers and Aggregators
Although their world is changing, historically data brokers and aggregators have hosted shared, third-party (i.e., anonymized) data among customers, mostly to support advertising or direct-mail marketing. These suppliers want to have a single place to attach their data to, and when it doesn’t exist, they might just offer you one. We see this increasingly in the B2B space. Some are building first-party (PII) data service extensions to their platforms. This is likely not a core competency and you’ll want to make sure they have suitable controls in place. More generally, it rarely makes sense to acquire an enduring (hopefully!) technology platform from a potentially itinerant service provider.
This is an interesting alternative because historically, CRM and salesforce automation platforms often served as a default customer data store, especially in B2B enterprises. There are at least three big problems with this:
- They’re usually pretty bad at data management;
- They tend to just have customer and lead data and nothing on prequalified prospects; and
- They don’t scale well for B2C volumes and extended data models.
Journey Orchestration Engines
At RSG we’re seeing JOE vendors slowly offer CDP services, though typically as an optional add-on. You can understand why: in order to direct traffic among diverse engagement environments, you need to have an authoritative store of information about the customer embarking on the journey. These add-ons can become problematic, however, particularly since your CDP will need to serve many systems, and not just your JOE.
This is an intriguing alternative because historically, many enterprises maintained their “digital marketing databases” in their marketing automation platform (MAP) or email service provider (ESP), since that’s where they ran outbound campaigns.
The problem, of course, is that this approach tended to lock that data into a particular engagement channel (messaging), and like CRMs, MAPs and ESPs are not very good at holistic data management and activation. Many early CDP buyers cited emigrating from this arrangement as a primary motivation for adoption. So, you should definitely build a bridge back to “the old country.” Just don’t move back there.
Some big-time web content and experience management (WCM) vendors and other wannabe digital experience management vendors have created persistent customer data stores, partly to simplify their personalization efforts, and partly to charge you for yet another module. Don’t do this. It’s a bad idea. See MAP/ESPs above.
It’s worth noting that recently, major WCM vendors have changed their tactics, if not their strategy. Sitecore, Episerver/Optimizely, Acquia, and Bloomreach have all recently bought smallish CDPs. In each case this represents a technology upgrade, but still doesn’t remove you from their tight-fitting box.
Major martech vendors — e.g., Adobe, Microsoft, Oracle, Salesforce, SAP, et. al. — represent a special case. After eschewing CDPs as faddish during the early years, they are now, haltingly, trying to catch up. These vendors have huge vested interests in their legacy flagship platforms and the implied (vertically coupled) architectures. RSG research suggests that these vendor offerings remain somewhat immature and parochial.
In summary…car or roof rack?
Note that these CDP-like services from vendors in adjacent markets can and often do meet the formal CDP Institute definition above. But in many cases they will present a sub-optimal choice for you. To summarize: don’t buy the car because of the roof rack.
Don’t (always) blame vendors
Let’s acknowledge that sometimes the problem is us… Vendors respond to customer requests and the reality is many different stakeholders across your enterprise may need a CDP. Some of the vendors your colleagues partner with will try to scratch that itch. This is a time for leadership, stepping up to the governance plate and seeking an enterprise-wide CDP solution.
Of course, you should also avoid the reverse problem: asking your customer data platform to do more than it should. CDP vendors themselves are expanding, and the potential use case set is already quite wide, from aggregating and managing data to supporting engagement services to actually activating them. If the purpose of getting a CDP is to “liberate” your customer data from restricted silos, then by the same logic, don’t overweight your customer data platform with too many extraneous services.
Real Story on MarTech is presented through a partnership with MarTech and Real Story Group, a vendor-agnostic research and advisory organization that helps organizations make purchasing decisions on marketing technology applications and digital workplace tools.
Opinions expressed in this article are those of the guest author and not necessarily MarTech. Staff authors are listed here.