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.

Building Trust Requires Innovation

Trust has been chasing me like a hungry mosquito. It seems that everyone has suddenly decided that creating trust is the key to success, whether it’s in the context of data sharing, artificial intelligence, or customer retention. Of course, I reached that conclusion quite some time ago (see this blog from late 2015) so I’m pleased to have the company.   But I’m also trying to figure out where we all need to go next.

I picked up a book on trust the other day (haven’t gotten past the introduction, so can’t say yet whether I’d recommend it) that seems to argue the problem of trust is different today because trust was traditionally based on central authority but authority itself has largely collapsed. The author sees a new, distributed trust model built on transparent, peer-based reputation (think Uber and Airbnb)* that lets people confidently interact with strangers. The chapter headings suggest she ends up proposing blockchain as the ultimate solution. This seems like more weight than any technology can bear and may just be evidence of silver bullet syndrome.   But it does hint at why blockchain has such great appeal: it’s precisely in tune with the anti-authority tenor of our times.

From a marketer’s perspective, what’s important here is not that blockchain might provide trust but that conventional authority certainly cannot. This means that most trust-building methods marketers naturally rely on, which are based in traditional authority, probably won’t work. Things like celebrity endorsements, solemn personal promises from the CEO, and references to company size or history carry little weight in a hyper-skeptical environment. Even consumer reviews and peer recommendations are suspect in a world where people don’t trust that they’re genuine. What’s needed are methods that let people see things for themselves: a sort of radical transparency that doesn’t require relying on anyone else’s word, including (or perhaps especially) the word of “people just like me”.

One familiar example is comparison shopping engines that don’t recommend a particular product but  make it easy for users to compare alternatives and pick the option they like best. A less obvious instance would be a navigation app that shows traffic conditions and estimated times for alternate routes: it might present what it considers the best choice but also makes it easy for the user to see what’s happening and, implicitly, why the system’s recommendation makes sense. Other examples include package tracking apps that remove uncertainty (and thus reduce anxiety) by showing the movement of a shipment towards the customer, customer service apps that track the location of a repair person as he approaches for a service call, or phone queue systems that estimate waiting time and state how many customers are ahead of the caller.  A determined skeptic could argue that such solutions can't be trusted because the systems themselves could be dishonest.  But any falsehoods would quickly become apparent when a package or repair person didn’t arrive as expected, so they are ultimately self-validating.

Of course, many activities are not so easily verified. Claims related to data sharing are high on that list: it’s pretty much impossible for a customer to know how their data has been used or whether it has been shared without their permission. This is the European Union’s approach to privacy in the General Data Protection Regulation (GDPR) makes so much sense: the rules include a requirement to track each use of personal data, documentation of authority for that use, and a right of individuals to see the history of use. That’s very different attitude from the U.S. approach, which has much looser consent requirements and no individual rights to review companies' actual behaviors.  In other words, the EU approach creates a forced transparency that builds trust, especially false information would be a legally-punishable offense.

There’s a slender chance that the GDPR approach will be adopted in the U.S. in the wake of Facebook’s Cambridge Analytica scandal, although the odds are greatly against it. More likely, companies that are not Facebook will unite to oppose any legislation, even if Facebook itself sits on the sidelines. (That’s exactly what’s happening right now in California.)  The more intriguing possibility is that Facebook alone will adopt GDPR policies in the U.S. – as it has not very convincingly promised – and that this will pressure other companies to do the same.  Color me skeptical on that scenario: Facebook will probably renege once public attention turns elsewhere and few consumers will stop using services they enjoy due to privacy considerations.  In fact, if you look closely at studies of consumer attitudes, what you ultimately see is that consumers don’t really put a very high value on their personal data or privacy in general.

What does scare them is identity theft, so it’s just possible that regulations addressing that issue might provide privacy protections as a bonus. That’s especially true if consumers decide they don’t trust the government to enforce data protection standards but, following the distributed authority model, instead demand transparency so they can verify compliance to “self-enforce” the rules for themselves.  Yet this too is a long shot: few current political leaders or privacy activists are likely to adopt so subtle a strategy.

In short, the government won't solve the trust problem for marketers, so they'll need to find their own solutions.  This means they have to devise trust building measures, convince their companies to adopt them, and then educate customers about how they work.  This is an especially hard challenge because the traditional, authority-based methods of gaining trust are no longer effective. Finding effective new methods is an opportunity for innovation and competitive advantage, which are fun, and for long hours and failed experiments, which are less fun but part of the package. Either way, you really have no choice: as that mosquito keeps telling me, trust is essential for success in today’s environment.

________________________________________________________________________
* both firms with corporate trust issues of their own, ironically.