The idea of a “single view of the customer” has been a marketing dream for a long time. Information about customers has a tendency to collect in disparate systems that don’t communicate. As a result, marketing, sales and customer service have to search multiple systems to find out what’s going on.
The Customer Data Platform (CDP) is one way people to solve this problem.
There are various definitions of CDPs, and the CDP Institute has some good information on that. To make it simple, you sometimes see a diagram like this to explain what a CDP does.
The idea is that you merge all your data sources into a single customer view in the CDP, then use rules to turn that data into action in your various activation channels. By enriching customer data with / from multiple sources, you can create rules to target and personalize information to make it more effective and useful for your customers.
That’s a helpful model to get the basic idea what a CDP does, but it rather quickly shows its weaknesses.
For example, say you have a subscription e-newsletter. You regularly monitor open rates, and notice a recent downtick. You’re worried that customers are less engaged. You decide to feed click and open data from your e-newsletter analytics into the CDP and then make a group in the CDP out of the less-engaged users to see if you can find any patterns. Sure enough, you notice the group that is less engaged with your e-newsletter is more active on your website in the evening, and you always send your e-newsletter in the morning. Now you have a hypothesis to test. You create a new segment for that group in your ESP and send their e-newsletters in the evening.
This example illustrates the main problem with the simplified diagram above, which is that the arrows go in one direction — from the data layer to the decision layer to the activation layer. In reality, few systems are simply data or activation. Each of those objects in the activation layer is itself a source of data for the CDP, and each of the data sources may have their own activations. Furthermore, once the CDP has enhanced and cleaned up data, it can (sometimes) be written back to the objects in the data layer. For example, a new entry in the CRM might go into the CDP, where the address is corrected and written back to the CRM.
Your website is another illustration of the two-way communication needed with a CDP. Your website feeds data into the CDP, but also relies on rules in the CDP for how it displays content to your visitors.
A better diagram would look like this. The data flows in both directions over each of the connections.
That’s a small correction, but it’s an important conceptual one. The more you think about this process with your systems, the more anomalies and complications you’ll find. There may be marketing automation rules in the ESP — or, in other words, something that should logically take place in the decision layer, but is taking place in a system the diagram puts in the activation layer.
Some of your sales people probably stand on the outside of this process. A CDP might be busy collecting data from SalesForce, and, in turn, enriching that data with what it collects from other sources, but when a new opportunity shows up, things will move straight to an activation channel (pick up the phone!) without touching the CDP.
Other processes may have been designed to connect straight from a data source — such as your subscriber information — to an activation channel — such as your ESP. It’s not always worth it to re-engineer a functioning system just to satisfy a neat and tidy system diagram. And the more you think about this, the more examples you’ll uncover. Simplicity is nice — until it costs too much to get there.
If you pursue this line of thinking you’ll have lines going all over the place on this diagram. I won’t bother drawing it because it will just be a tangled spaghetti mess.
The point here is not to pick at nits, or to criticize the simplistic view of CDP function. The idea is to illustrate the difference between strategic thinking and operational thinking. You’re going to need to do both (but not on the same diagram!). You need to think of each process in simple terms — perhaps only as a conceptual framework — and then work through the details and try to line up all the spaghetti in the right places.
Don’t let your conceptual, strategic framework get spoiled by all the exceptions, and don’t let operational realities get steamrolled by a strategic vision.
This is one of those cases where “don’t let the back end run the front end” applies.
Rather, focus on high-impact use cases. Use the strategic framework as a guide, but don’t fret if operational realities don’t fit your tidy little strategy.
Questions? Comments? Post them below, or contact me. I’m happy to help you wade through these decisions and find the fit that’s right for your organization.
