Last month, the Customer Data Platform Institute launched its RealCDP initiative, intended to help marketers understand which vendors in a landscape of over 100 so-called CDPs are actual CDPs, capable of fully satisfying the broad range of critical CDP use cases.
In order to be a “RealCDP,” the Institute states that a vendor must:
- Ingest data from any source
- Capture full detail of ingested data
- Store ingested data indefinitely (subject to privacy constraints)
- Create unified profiles of identified individuals
- Share data with any system that needs it
While this list of features is still generously inclusive of many CDP vendors (and of course AgilOne has RealCDP certification as well), I’d like to take a moment to drill a little deeper into requirement #3: “store ingested data.” While this may seem like an obvious feature for a CDP, understanding the exact way a CDP vendor stores data reveals a lot about how well a vendor can meet specific CDP use cases. Analytical use cases, identity stitching use cases, and use cases that require a lot of processing power are a few that come to mind…
A key difference between enterprise-grade CDPs and others is where the customer data resides.
Enterprise CDPs provide their own data warehouse, which is a central repository of data for the CDP after identity resolution, predictive intelligence, unique configurations for a specific business take place on that data.
CDPs that shuffle data around (e.g., tag management systems) based on data access patterns present fundamental problems and huge limitations for businesses that are serious about understanding their customers and activating customer data for orchestrated engagement. With no persistence of cross-silo data, there can be no master customer record -- and without that, many “customer-first” initiatives fall flat on their face.
Enabling powerful identity resolution
Without a centralized data store, identity resolution is stifled. If identifiers are pulled across each application, but not reconciled into a persistent stored record, there can be no elements of probabilistic matching or other intelligence that stitches first and third party data into complete, single profiles. At best, identity resolution would be relegated to simple device stitching -- not enterprise-grade true identity resolution.
By contrast, AgilOne and other mature CDPs were designed under the premise that no customer insight or activation can take place until the marketer has a true understanding of their clean, deduped, stitched customer records (including identities and events) into a “golden profile,” which serves as the basis of all customer marketing and engagement. Furthermore, identity resolution works best when it’s configured to meet the exact needs of the organization -- and such configurability is only possible with an enterprise CDP.
There is also the issue of efficiency (or lack thereof). A non-centralized data model, requires scoring each customer’s record, their browsing history, their purchasing history, and their campaign engagement — all of which reside in separate non-centralized databases — using deterministic and probabilistic matching algorithms against that population every single time the scoring query is submitted. Inefficient, right? Wouldn’t you want to do the record matching one time instead of every single time?
Processing large volumes of data
One of the reasons companies choose a CDP is because they need to unify, apply intelligence to, and activate MASSIVE amounts of customer data. If the CDP is architected to rely on the processing power of all the edge systems that store the customer data, the CDP can therefore only run as fast as the slowest edge system. Also, without a centralized data store of cleansed, deduped records, the quantity of records for most enterprise brands will overwhelm whatever processing power the system has.
Also, because the data resides in the edge systems, marketers and other teams across the organization that want to access the data would have to learn the multiple languages of the different edge systems (e.g. Java, SQL, etc.). This limits who within an organization gets to access and use customer data.
And finally, if a CDP is simply a UI on top of the different edge systems, analysts and data scientists will be forced to use pre-configured queries and won’t be able to adjust their queries as needed.
None of these issues exist with a true enterprise CDP like AgilOne.
Gaining important customer insights
Customer data is only useful if you can understand it. Without a centralized data store of cleansed, deduped, stitched data, it is impossible to gain any insights about your customers, much less use insights to personalize customer engagement. This is true for understanding the size and segments of your customers, but it’s also true if you want to apply predictive intelligence to your customer database, such as identifying customers who are likely to buy, likely to churn, likely to become high value, etc.
Only a CDP, with big data technology that stores information in a centralized data model, can give you a true picture of your customers and provide usable insights that all customer-facing marketing teams can use (for example, as AgilOne provides with Metrics Launchpad.)
Customer data for the whole organization
At AgilOne, several clients are using our CDP to power customer experience use cases driven by non-marketing teams; for example, retail store associates using a clienteling app leverage AgilOne, and call center agents fielding inbound calls and filing helpdesk tickets. This is accomplished through AgilOne’s UI, which provides an interface these teams can log into and use, or through our API, which feeds customer data to systems such as SalesForce Service Cloud or Tulip Clienteling. (You can read more about AgilOne’s 360 Profile for Customer Service here.)
A CDP is not just a system for the marketer. A clean, enriched database of customers is useful for every team that touches the customer.