- A CDP vendor is being bought by an established enterprise data management firm. This is a normal event in the development of a software category: products are developed as single-purpose "point solutions" and then, after the category is validated and requirements are standardized, the capability is assimilated into larger suites by acquisition (usually) or internal development. The most surprising thing about the CDP industry so far has been that this hasn’t happened very often. There have been some deals but the two biggest each came with an asterisk: Salesforce bought Datorama but positions it primary for campaign measurement and Arm Ltd., which purchased Treasure Data, is not a typical enterprise software vendor. By contrast, Informatica is very much a leader in enterprise data management, with a major presence in integration, Master Data Management (MDM), governance, and security. The purchase confirms what we already knew: business managers recognize they need unified customer data and enterprise software vendors will offer them solutions.
- It illustrates the difference between MDM and CDP. This is one of those questions we still get fairly often. Informatica lays out the contrast quite nicely: they characterize MDM as limited to highly governed, structured data that delivers the “best version of the truth” about master objects (customers, products, supplier, etc.), while AllSight stores transaction and interactions in addition to the master objects, supports unstructured as well as structured inputs, and allows multiple data views and matching options. AllSight is an exceptionally powerful CDP, with features including machine learning-based identity matching, natural language-based information extraction from unstructured data, a graph data store for complex relationships among objects, ability to create derived variables, and high scalability. These are not found in all CDPs, which is probably one reason Informatica selected AllSight in particular. But all CDPs share the core CDP capability of storing all types of customer information without losing any of the details, which is beyond the scope of MDM.
- It confirms the importance of a persistent data store. This, like storing all information, is part of the core CDP definition. Some enterprise software vendors still argue it’s enough to connect personal identifiers in different source systems and then to pull data from those systems as needed. That is how Informatica has been doing things, apparently. But they’ve now described a progression from “distributed” customer views (disconnected systems) to “federated” views (data remains in transactional systems) to “consolidated” views (data is stored centrally and synchronized with source systems). Reasons they cite for doing this include scalability and real time performance; I’ll add greater consistency, easier control, visibility, and ensured access to historical data.
- It shows use of CDP beyond marketing. Informatica sells primarily to IT staff, which in turn supports all corporate departments, not just marketing. In their briefing on the topic, Informatica made clear that a major reason for buying AllSight is to access the funds controlled by marketers and analytics teams. But they also argued that AllSight will give them more to sell to IT staff, which will use it to better manage large volumes of unstructured data, prepare analytical data sets, add insights based on artificial intelligence and machine learning, and support specific applications such as risk and compliance. Growth to support new use cases and departments is another natural business development for any category.
- It gives a literal example of “CDP Inside”. This is my shorthand for recognizing that CDP functions are increasingly available within larger systems, in addition to being stand-alone products. This is arguably the most important trend in today’s CDP industry. Let's explore it in more depth.
The bigger issue is that even the broadest definition excludes other products that include CDP capabilities. Informatica is good example: AllSight didn’t stop being a CDP just because Informatica bought it, but it’s hard to argue that Informatica should now call itself a CDP system as a result. The same question will appear when Salesforce, Oracle, and Adobe finally deliver proper CDP capabilities – which will doubtless happen, sooner or later. Rather than calling every system with CDP capabilities a CDP, I think it's more useful to define core CDP capabilities and then to judge every system’s CDP features against that list. This is another normal market development: companies choose all the time between buying “best of breed” point solutions and buying larger suites that include similar functions. Companies with the most demanding requirements and most sophisticated users often find themselves purchasing “best of breed” products while those with simpler needs often find the product embedded in a suite is good enough.
CDPs are slightly different from other suite components because many suites are connected internally but isolated from external systems. CDPs are by definition required to connect with external systems. This means a suite with CDP functions wouldn’t qualify as having a “CDP inside” if those functions couldn’t also connect with external data sources, analytical, decision, and delivery systems. But there’s no technical reason that suite vendors can’t provide systems capable of such connections and their importance is probably well enough understood that most suites will provide them. Conversely, suite vendors are under increasing pressure to open their systems to integration with external products. This may make it easier for “best of breed” CDPs to survive than it has been for other “best of breed” products in the past.
Of course, even accepting the notion of “CDP inside” doesn’t resolve the debate over what scope of functions should be included on the CDP requirements list. I lean to a narrower definition, limited largely to building the unified, sharable database, based on the fact that analytics, decisions, and distribution systems can be purchased separately. To me, this indicates that each of those is a separate software category. In concrete terms, it means that buyers face a separate “suite vs best of breed” decision for each of those components. The counter argument is that some analytics, decision, and distribution capabilities are substantially more effective when they are directly integrated with the unified customer database, so they should be considered part of the core CDP requirements. I suppose the easiest solution is to include the broader requirements on any list and let each buyer decide for herself which ones matter.
The more inclusive approach is in fact what we’re currently taking at the CDP Institute, where I’ve been distinguishing between data, analytical, and personalization CDPs. This seems to reduce confusion, so I’m reluctant to abandon it. But I've drawn the line at systems with delivery capabilities, such as sending email or managing a Web site. My theory is that those are demanding operational features which are, or at least should be, the focus of the developers' attention. So calling such systems a CDP is misleading, even though they might have a perfectly adequate "CDP inside".
Our current projects at the Institute include improved evaluation criteria for the data, analytical, and personalization functions. These will make it easier for buyers to determine which CDP vendors fall into which category or, more precisely, how well each vendor meets the requirements for each category. The good news is that the same evaluation criteria can be applied to the CDP components inside of broader products. So the work will help marketers to make sound choices across all their options regardless of how we define a CDP. And making good choices, not defining software categories, is ultimately what matters.