What I Learned at the Customer Data Platform Workshop

I ran a four hour workshop on Customer Data Platforms this week at the MarTech Conference in San Jose.* The attendees were a mix of marketers and technologists from brands, agencies, and vendor companies. We had surveyed them in advance and found, not surprisingly, goals ranging from understanding CDP market trends to optimizing data loads for technical performance. The agenda was correspondingly varied and I like to think that everyone learned something useful.  Based on attendee comments and my own observations, here’s what I myself learned.

- CDP is a vague category. This was voiced with some frustration at the end of the workshop, when several people said they had hoped to come away with a clear picture of what is and isn’t a CDP, but found instead that CDP systems differ widely. In the context of the workshop, I actually considered this to be a positive result: one of the main points I tried to get across was that CDPs have very different features and picking the right one requires you to first understand your own needs and then look carefully at which systems have the features needed to meet them.  Complaining about it is like going to a workshop on car buying and discovering that automobiles differ widely: if you didn't understand that before, you couldn’t possibly have made a sound choice. The variety may seem overwhelming but once you recognize it exists, you’re ready to take the next step of figuring out how to find the capabilities that match your needs.

- People want CDP-specific use cases. I knew in advance that people want to understand CDP use cases. This has become a very common question in the past year and the CDP Institute Library includes many papers on the topic. My personal problem has been that CDPs are like bacon: they make everything better. This made it seem silly to list use cases, because the list would include pretty much any marketing project that involves data. What I learned from the workshop is people are really looking for use cases that only become possible with a CDP. That’s a much different and more specific question: What can I do with a CDP that can’t do without one?

We discussed the answers as a group at the end of the workshop and the main conclusion was CDP makes possible many cross-channel activities that are otherwise impossible because cross-channel data isn't unified.  This isn’t exactly news – unified customer data is the whole point of a CDP – but it’s still good to focus specifically on the use cases that unification makes possible.

On reflection, I’d add the CDP also exposes data that’s otherwise trapped in source systems or not collected at all. This could be information from a single channel, so it’s distinct from the cross-channel use case. Our workshop group didn’t mention this one, so I’ll have to stress it more in the future.

The group also didn’t list the operational efficiencies of a CDP as unique benefits. That’s interesting because so much of our discussion stressed the lower cost, faster deployment, and lower risk of CDP compared with other solutions. Apparently that’s either not credible or not important. I’ll speculate that the technicians didn’t believe it and the marketing people didn’t really care. But of course that’s utterly unsupported stereotyping. (Speaking of stereotyping, I’m pretty sure the technical people sat in the back rows and the marketers talked a lot more during the small group discussions.  Next time I'll make them wear labels so I know for sure.)

- Marketers don’t care about technical details. Ok, that's really unfair stereotyping so let's change it to “some marketers”.  But it’s definitely fact-based: one of marketers complained as we started to drill into the technical parts and several others agreed. I pushed back a bit, arguing that you can’t make a sound system selection without looking at technical differences. I think I was polite about it, but have strong feelings on the subject: lack of research into specific product capabilities is by far the biggest reason people end up unhappy with a software purchase. (Yes, I have research to back that up.)

I suppose the counter-argument is what really matters are the functional differences and not the technical methods used to accomplish them. My counter-counter-argument would be the technical methods matter because they determine how efficiently a system executes those functions and how easily it can extend them. Architecture is destiny, as it were.  In my mind, the argument ends there and I win but maybe there’s more to be said for the other position. (If case you’re wondering, I did speed through the technical parts after that objection, and talked more about use cases instead. Squeaky wheels get the grease. And there was a later part of the agenda that circled back to technical questions anyway.)

So, that’s what I learned during the workshop. As you might imagine, preparing it forced me to think through several topics that I’ve been addressing casually. I’m most pleased with having clarified the relationships among strategy, marketing programs, use cases, resources, and requirements. The image below summarizes these: as you see, strategy drives marketing programs which drive resource needs**, while marketing programs drive use cases which drive system requirements. Those are two sets of objects that I usually discuss separately, so I’m happy to finally connect them. Plus, I think it’s a cute picture. Enjoy.

_______________________________________________________________________________________
* I'll likely be repeating it elsewhere over the next few months.  Let me know if you're interested in attending.

** The flow can also run the other way: available resources determine what marketing programs you can run which determine what strategy makes the most sense.