I got a chance to present to a group of digital analytics enthusiasts last week -- you can view the slides here. You can also view the slides here, as I'll take you through the deck, minus intro/outro slides.
This problem of "defining the customer data platform" is a serious and also ridiculous problem all at once. Consultants, providers, and analysts must attempt to explain what CDPs are. Clients are asking. It is a painful and important job, but in the end business doesn't need to explain software. Business needs to use software. The definition of a CDP from your business should be very different from what these other folks are saying.
Customer data platforms are software that can help your organization manage customer data.We'll get into it in a bit more depth, but part of managing customer data is making it available (while meeting security and privacy standards) for analytics and marketing/communication use cases. Needs in this area of customer data management vary so wildly that there is room for a couple dozen CDPs long-term in the market.
Where things get even more confusing in the definition of a customer data platform is that a CDP goes beyond making data available for analytics and marketing/communication use cases. For example, most CDP definitions would call for minimum requirements of basic segmentation capabilities and delivery of data to systems that need them. This is what enables owners of customer data platforms to choose best of breed technologies in any category -- if that system lacks these basic capabilities, the CDP has your back.
You kind of have to include David Raab's definition of a CDP, so I did. It is so very solid! These three points make a lot of sense.
I went on to include the text from our very own "What is a CDP?" page. I am trying to distinguish between marketing service providers, marketing clouds, and customer data platforms a bit. It's not to say that the marketing clouds and MSPs can't buy or build their own CDP software and sell it... but it's difficult to be vendor neutral and truly enable best of breed technologies in these situations.
Technical partnerships can take an infrastructural-based CDP deep into execution use cases (smart orchestration), and likewise they can take an execution-based CDP deep into data management use cases (contextual unification).
Oh, just a few more points about that definition! "Developed software" means someone has to have purchased and used it successfully, pretty much. From there forward, each of these is included in the list to point out that these things mean very different things for different organizations.
We'll get into the details on the next slide, because there are four core areas that customer data platforms are here to help in: data collection, unification (which is kind of what building profiles is), analytics, and delivery!
Much time could be spent talking about this. Other analysts have similar areas, sometimes three, sometimes five... but all seem to agree that there are some core functional areas, and CDPs are often taking very different approaches or handling very different tasks within these functional areas. Quick examples:
In data collection, some systems can ingest data other systems generate. Others can generate data by way of APIs, or inclusion of SDKs, etc.
Unification might only involve simple stitching (A=B in one system, B=C in another system, so A=B=C and all data is "unified") to build a customer profile, or as mentioned above there could be capabilities for unification to depend on the context that profile will be used in. As the complexity of unification increases, so too does the importance of being able to trace exactly how and why profiles were unified.
Segmentation and reporting are the basic analytics capabilities that all CDPs would have, while certainly not all of them allow external machine learning algorithms to be brought in.
How delivery works is one of the more critical components of your customer data platform. This is where expectations seem to often be most disconnected, as it is one thing to be able to send customer data to other systems, and something else entirely to have orchestration logic or even more complex triggering rules.
In closing, while it is good to have external definitions of what software is, the most important thing is to accelerate without disruption. There's nothing much more disruptive than making the wrong major software decision during any part of digital transformation.