There's nothing questionable about these claims. Customer success platforms were among the earliest classes of systems identified as CDPs. Like predictive modeling systems, they originally built a unified database to support their primary application and later recognized that the database had even more value if it was shared with other systems. So a CDP positioning makes sense.
But the Gainsight announcement did prompt an industry colleague to ask me whether classifying products like Gainsight as CDPs would lead to each department building its own CDP, creating “CDP silos” and ultimately requiring a “CDP of CDPs” to unify them all. That contains enough irony to meet your minimum daily requirement for a week. But it’s a fair question that’s often posed by CDP buyers who don't want another silo in their server farm.
My first answer is that not all systems claiming to have a CDP are true CDPs, particularly when it comes to sharing their data with any external system. We’ve been trying clarify that with the RealCDP project, which includes data sharing as one of the five qualification requirements. But many vendors like Gainsight and Totango pass that test. So it doesn’t really address the question.
My second answer is to respond with another question: If a system meets the definition of a CDP, should we NOT call it one? That seems silly. Of course, it begs the question of the CDP definition itself: should we define a CDP as a system that only builds the unified database? This would exclude products that also provide integrated applications such as customer success management, predictive modeling, campaign management, personalization, and more. The narrow definition would certainly reduce confusion. But it doesn’t address the real-word situation, which is that many buyers want a CDP that includes some or even all of those applications. My response has been to suggest the “CDP Inside” concept, which says CDP is a function, not a software category. This function could be provided by a single-purpose system or by a system that offers other functions as well. The concept hasn’t been as widely adopted as I'd like but I think the world is moving in that direction regardless.
My third answer builds on the second. Companies can buy multiple products with a CDP capability and still not deploy all of them. This comes down to management: a company with several CDP-capable products can make one its primary CDP and push profiles from that system to the rest. That would be the best choice in most cases, I think. But a company might also build several complete CDPs by feeding the same data into each of them. Or it might build siloed CDPs that only connect to their associated applications. Those sound like bad ideas. But it’s not the CDP's fault if someone deploys it ineffectively.
Let’s game this out.
- Application vendors are incented to add CDP capabilities to their systems because some clients want them. Foolish clients may build several separate CDPs, especially in organizations where different groups prefer to function independently. So, yes, there’s some potential harm in making that easy by putting a possible CDP inside each system.
- Smart clients will avoid this mistake by choosing one system as their primary CDP. Each vendor will hope to play that role, since it adds value to their product and makes clients less likely to switch to another system.
- Over time, the smart clients will learn what they need in a CDP and push vendors to compete to build the best product. As this happens, vendors with limited resources will drop out of the competition to focus on their core applications. They'll still provide some data unification features but won't promote them as a CDP.
- Other vendors will double down on their CDP investment so they can win the competition. As these vendors develop best-in-class products, they’re likely to offer their CDPs as separate modules.
- The most demanding buyers will want the best possible CDP and will buy best-in-class products whether they come from specialist CDP vendors or application developers. As a result, best-in-class CDPs will be increasingly distinguished from lightweight CDPs embedded in application systems.
A reasonable analogy might be reporting systems. In the early days of the packaged software industry, application vendors competed to offer the best custom report builders within their products. Later, general-purpose reporting tools like Tableau came to dominate the market. Most application vendors then stopped presenting their report builder as a differentiator. They still deliver specialized reports as part of their systems but expect users to integrate with third party reporting tools for other needs.
I think the CDP industry will follow a similar trajectory. Many applications need unified customer profiles. Some will rely entirely on an external CDP to create those profiles and share them. Most will offer a lightweight CDP so customers without a separate CDP can still use their application. A few will build best-in-class CDPs that can be sold on their own. These best-in-class CDP modules will often be spun off as separate products.
Some of this is already happening.* CDP vendors themselves are increasingly distinguishing between CDPs that focus on building and sharing the unified database and CDPs that also deliver analytical, personalization, and other application capabilities. Some in the latter group position their CDP features as best-in-class but most will admit (with varying degrees of reluctance) that they are often deployed in combination with a separate CDP that specializes in data unification. So, just as companies often have a shared standard reporting tool that complements the reports built into applications, we can expect to see one shared CDP that complements specialist CDPs within applications.
It will take some time to sort this out, as vendors decide what kind of CDP to offer and buyers decide what they need. But I think the future of the industry is coming into focus.
__________________________________________________
*A little-cited corollary to the famous aphorism that predictions about the future are hard is that predicting the past is easy.
No comments:
Post a Comment