Amazing things can be built in the age of APIs and cloud connectors.
This content, including the above statements, was originally posted on cdpresource.com on June 14, 2018 with the tags: CDP buyers, CDP evaluation, CDP implementation, CDP use cases, and first-party data. Thanks to the Internet Archive at archive.org for retaining it. My current comments below the post, which remains in its original form.
You don't build a customer data platform.
You can build towards accomplishing some short-term goals that can also be accomplished with a CDP, but you can't build the core capabilities that drive the allure of the customer data platform. The accessibility of a real-time unified profile for push-button systems integrations and seemingly limitless capabilities in data collection would cost countless years of time to develop internally.
But things can be built, and I am a proponent of building things. At least two types of things can be built here:
1. The use cases themselves
Many use cases that would be deployed with a CDP can be deployed in some other way, without benefit of a full profile and other components the customer data platform provides.
2. Internal capacity for customer data use cases
This is where time is better spent. Building out use cases shouldn't really happen until the internal capacity to deal with them is being managed. Early on, teams should be thinking about and planning for customer data and other first-party data use cases. Take the systems out of the equation for a while.
Where does an organization start?
There are organizational ownership decisions to be made. Milestones and ownership need to be defined. From there, one way to get started in building the capacity for customer data use cases is to build out a list of potential, practical use cases for customer and first-party data. Initial use cases for a customer data platform tend to be those that make use of customer data in new areas of value. Consider these, and list use cases from channel to channel with an estimate of effort and value. Include details around why the effort and value scores were chosen.
As an example or potential starting point, here is an example set of use cases for an imaginary retail brand with special interest publishing sites, minus the scoring details for the sake of brevity. To keep things very simple I included only three channels and used scores from 1-3. For value, 1 = high. For effort, 1 = easy. These can be combined and sorted to find potential good starting points, though supporting steps for long-term use cases must also be considered as part of earlier implementation phases.
Example website use cases for customer data:
Example email use cases for customer data:
Example PPC/ad tech use cases for customer data:
Extract internal requirements
In reality, a 1-5 scale and the details are necessary for prioritization, but even with a list like this, effort unrelated to a customer data platform can be extracted. Each one of these use cases will come along with internal requirements and steps that need to be taken in order to approach them, steps that can be worked out internally with or without a CDP. If a decision has not yet been made on a CDP, a list like this will go a long way in conversations with vendors to ensure coverage. This may also be where use cases will be discovered that are worth deploying before a decision is made on a customer data platform (the "oh, we had this?" moment).
It's all about the profile
Most customer data platforms feature a website personalization interface, and the driving reason to use that interface is the unified customer profile and real-time decisioning. Visitor identification is a requirement in order to support cross-device and known customer data scenarios. Customer data platforms are not the only way to identify visitors, whether from logging in or clicking through from emails, push notifications, SMS messages, etc. What CDPs offer that other solutions tend not to is an ability to personalize and build out profiles based on multiple identifiers (a process some call "stitching").
While cookie-based personalization tools can allow you to try and stay relevant across pages and sessions, they are no replacement for a full-as-it-can-be profile combined with the centralized decisioning and orchestration that a customer data platform would provide to hands-on marketers.
Yes, build it!
Building the capacity for the customer data platform is just as important as having the customer data platform. Building lines of communication and plans for customer and other first-party data is what enables successful deployments. And, if a customer data platform isn't yet in the budget, you may just be able to select a use case or two to attempt before landing one.
And now, for something completely different (back to the current).
Ok. Over-exuberance on the software part of things still in June of 2018. By the end of the year, I was fully done with the belief that any one platform would, could, or should solve this problem. That is what I am getting at with a series of posts on Medium looking at the re-defining of "customer data platform" from the organizational side. With this definition, the "capacity" discussed above is actually labeled:
The organizational CDP. People, process, and technology.
The idea I was getting at is that first-party data can be collected, or you can initiate a first-party data program in order to collect first-party data by design. Sounds similar, but the first ends up being a lot more willy-nilly than one might think, and you get a lot more value out of the latter.
