4 Critical Considerations When Talking CDPs

Nicholas Einstein: Hello. My name is Nicholas Einstein, and welcome to Four Critical Considerations when Talking CDPs. I'm joined today by the man who coined the term CDP himself, David Raab. David, thanks for joining us today.

David Raab: Thanks for having me, Nick

Nicholas Einstein: David is founder and CEO of the Customer Data Platform Institute, which is a vendor- neutral organization with over 10,000 members. CDPI helps organizations to make the best use of their customer data. You coined the term CDP nearly a decade ago. It was a blog post that was dated April 25th, 2013, in fact, and a lot has changed in the space since then. First- party data has literally exploded. Marketers have more first- party customer data than ever before. It's spread across more systems than ever before. And expectations to deliver highly personalized experiences are higher than they ever have been before. So maybe to kick us off, give us a little brief snapshot into the CDP market today versus eight years ago. What has changed?

David Raab: I think one thing that's changed is just the sheer number of vendors. I think our first report, which might have been 2016 when we founded the Institute, had 19 vendors in it. The latest report had 151, if memory serves, and we literally keep finding new ones about once a week, it feels like. The number of vendors, and then, of course, the variety of vendors has grown as well. So when we first started out, CDPs were pretty clearly systems that really just built customer profiles, and that's still my thumbnail definition of CDP. If you want three words to write down and remember, CDPs build profiles. That's really all they do. But what we found since then is that a lot of systems build profiles. And if they tick all the boxes that we have about what makes a CDP a proper CDP, you still have, as I said, about 150 systems. So you can have a email management system that has a proper CDP inside, or even an e- commerce system or a predictive modeling system. So there's all these huge variety of systems. And the reason that they're all CDPs is partly because they tick the boxes. They meet the requirements, but also because the vendors have decided to label them as CDPs. We'll rarely classify a system as a CDP if the vendor itself doesn't accept and actually promote that classification. So it's become a very popular category. A lot of people, obviously, are looking to buy CDPs, which is why vendors adopt the label. So both the supply side and demand side has grown very, very substantially.

Nicholas Einstein: And you bring up a good point there. There is a lot of variance in CDPs and what is a CDP and what isn't. So you talk about CDPs building profiles. What is the real definition? What does the CDPI define a CDP as, and what are the differences maybe between a CDP and a data warehouse or a data lake?

David Raab: Okay. So the formal CDP Institute definition is customer data platform is packaged software that builds a persistent, unified customer database that's accessible to other systems. If you want to break that down a bit, which gets to your question about how it differs, packaged software means it's something you buy. It's not a data warehouse or a data lake that you would typically build as a custom project. Unified, persistent customer database obviously has multiple components to it, but it means that it takes in data from all sources. That's sort of what unified suggests. So it doesn't just work with some subset of data. A CRM system, for example, will work usually just with the data that the CRM users have entered into their own system. They don't usually import data from other sources. Marketing automation, pretty much the same way, except maybe it will be integrated with a CRM. Persistent means it stores the data more or less permanently, the more or less being sometimes you're not allowed to store it for a particular period of time for regulatory reasons, or simply for business reasons there's no point to storing the data. So it clearly stores it as long as you want, as opposed, say, to a DMP, a data management platform, which traditionally at least work with cookies. And cookies you throw away after 60 or 90 days because they're simply not useful anymore, or they've been discarded by the system itself. So that's another differentiation. Or integration platforms, things like MuleSoft or Zapier or Boomi, any of those products that just move data from one place to another, but don't themselves store it permanently. And if you're not going to store it permanently, then things like identity resolution become really difficult because there's old data that you have to factor into your identity resolution that might be thrown away. And shareable with other systems, accessible to other systems is easy enough to understand. But again, there are a lot of products, again, things like CRM platforms or marketing suites, that really are not very good at sharing with external systems. They build a database, and it may be a very fine, complete, unified, persistent database, but they really just use it for themselves. They're not designed to share it out with other systems, and that takes some special technology or at least design to do that. So the CDP has this unique combination of features. No one feature is absolutely unique only to the CDP. It's the combination that makes it unique, and the combination is there because that's what it's designed to do. It was designed to build those persistent, shareable profiles, where all the other systems we were just talking about, even though they store customer data and even though they're perfectly excellent at what they do, they were designed for some other purpose. And they were, therefore, optimized for that purpose, which makes them not really as good at doing what a CDP does.

Nicholas Einstein: There is a lot of variance into kind of how CDPs were designed, right? Like, some were purpose- built CDPs ground up, some built for marketers, some built for more kind of enterprise operations, IT folks. In terms of getting the most out of your CDP, how should organizations be thinking about kind of training and making best use of the CDP?

David Raab: Well, training is a good thing. We're highly in favor of training, and many organizations skimp on training. What happens is the project runs a little over schedule. So they budgeted a month or two for training. Then, of course, when they ran over a month or two, they said,"Oh, we'll just do the training after the fact." This is not a good idea. We do not recommend this, okay? But backing up just a bit about finding the right CDP, as we say, they have all these different scopes. Some just build the profiles. Some do profiles, plus they have predictive analytics, which is a whole class of CDP vendor, because a lot of those companies started out as predictive analytics systems, and they said,"We need this unified data." They built the unified database, and by gum, they're a CDP now. Then it turned out the unified database was actually more appealing than the predictive modeling tool. And other ones have campaign management and even, as I say, delivery or e- commerce or whatever. So the scope varies greatly, even though they all have that shared ability to build profiles, because that's, again, what makes you a CDP. Now, as to which one you need, there are two sort of big clusters, if you will. There are the systems that really focus just on the profile building. And those vendors tend to sell up into the enterprise, where the enterprise wants a unified customer profile that can be shared not just by marketing, but also by sales and service and support and operations and all the other groups. So those tend to be enterprise resources. So the companies who want that, if they're not going to build it themselves... A lot of big enterprises like to build things. But if they are going to buy one, they will buy one that's really focused on the profile building, because the other functionalities are going to be handled by departmental systems. The other big cluster of CDPs are systems that are more targeted to marketing departments. And those are the ones that have built- in campaign management and built- in predictive modeling and analytics and maybe even, as I say, message delivery, like email or web ads or whatever, because a marketing department wants one system to do as many things as possible, especially if it's not really committed to its existing email system or predictive modeling system or whatever. So the vendors kind of tend to fall in those two big buckets. The ones that are sold to marketing departments are a little more sold to mid- tier companies than big enterprises, although plenty of big enterprises buy them. So within the many fine gradiations of the market, and one of the things that we like to do around here is split the market into cute little segments. But if you're not totally obsessed with CDPs, maybe you just want to think of them as two sort of broad segments of the ones that really focus on data and are more enterprise level and the ones that are really more for the marketing department and have a lot of marketing functions in addition. Which of those you need, of course, depends on which kind of company you are, which kind of buyer you are.

Nicholas Einstein: And likely the requirements for kind of training the staff and getting people up to speed varies too based on the tech-

David Raab: Right. And clearly, if you're going to have an integrated campaign manager, well, maybe you want to train your marketers to use it. That's generally considered a good idea. If it's just a CDP that's going to be doing the data management bit of it, then that's more IT training, and that's who you have to train and what you have to train them in, which doesn't mean, of course, as with any data system, that the people who are going to use the results, who are going to use the data don't need to be trained on what's actually in there. That's, of course, a huge problem that people look at a piece of data and they're," Oh, this says it's the email address. Well, then, I guess I can use it for always to be the email address." Well, maybe that's really just a particular email address. Or there's some other bit of data that looks like it might be one thing, but actually isn't necessarily what you think it is. So it's important to train the users on what's really in there and what it's suitable for and what it's not suitable for. Predictive modeling scores are a good example of something that might be labeled one thing, but often can be misused accidentally if you don't really understand what you're looking at.

Nicholas Einstein: These are pretty dynamic times when it comes to privacy and how brands and marketers are managing their customer data. International regulations, GDPR, state regulations in the US rolling out as we speak. I'm in Colorado. I think Colorado just rolled one out. There are some pretty strict requirements on how brands can handle and use their first- party data. We also have Apple and Google stepping in on the privacy front making big changes. So I know you guys at the CDPI are laser- focused on privacy. We just went through the CDPI, RealCDPI certification again this year, and you had a lot of new questions about privacy. What role does the CDP play when it comes to security and privacy, and what should our audience here be thinking about when it comes to their CDP and the usage of their customer data today?

David Raab: Right. So privacy is hugely important. Certainly, the European vendors just think of GDPR as the CDP Full Employment Act because pretty much every company in Europe has to... Well, they all have to comply with GDPR, and many of them look to the CDP as the tool to do that. The reason that happens is what you have to do to deploy a CDP in many ways overlaps with what you have to do to comply with privacy regulations. So you have to find where all your customer data sits. Well, you have to do that to deploy a CDP, and you have to do that to comply with privacy regulations. You have to be able to pull that data together and give someone a look at it. Well, that's what marketers do with the CDP profile. And that's what you have to do if you have a subject access request from a person, we really should call them people and not subjects, who makes the request and says," Show me all your data," which is a right under GDPR and CCPA, for example. You have to be able to keep track of all the processing that you've done. Very easy if you're doing all your processing by pulling data out of the CDP. It sits there as a choke point to make sure that data is only pulled out for appropriate reasons. You have to track consents. Well, guess what? You need a place to store that consent. CDP is a perfect place to store that consent, as I say, then to put governance on top of the data to make sure that use of the data is only something that is, in fact, consented to or otherwise justified, because consent's only one of the legal justifications for using data. So a lot of the work you have to do to comply with privacy is the work that you have to do to deploy a CDP. So it just makes total sense for the CDP to be the system that you do that in, because before that, companies typically didn't have it all in one place. So they were going to have to deploy effectively a CDP, anyhow, just to comply with the privacy regs.

Nicholas Einstein: Let's hit one more question here before we get to the live Q& A, and this one's a biggie. Build or buy? In my experience, a lot of enterprise marketing departments, marketing operations folks, IT folks believe they do have the skills and tech infrastructure to satisfy key use cases by building in house, as opposed to looking for a CDP vendor. And maybe, I don't know if that's changed over time, but what do you see in the marketplace as it pertains to kind of build or buy? And what advice would you have for brands and marketers who are considering building at the moment?

David Raab: Well, I'm tempted to answer," Build or buy?" by saying yes, because the reality is it's really not an either/ or choice. Nobody goes out and builds their own computer chips. You're going to buy your computer chips. You're going to buy your computers. You're probably going to buy your computing services. You're probably going to buy an operating system and a database system. So you're going to buy a lot of stuff even if you quote- unquote" build" your CDP. Similarly, even if you bought a packaged CDP and everything that goes on top of it or underneath it in terms of what else we got built, you're still going to have your IT people connect the data in. There's still IT work to deploy that packaged CDP, which is effectively building, right? So it's more of a balance. Now, you can go out, if you're an IT department, and you can buy a pipelining tool, an identity resolution tool, and obviously database management tools and segmentation tools. You can buy all those things, and you can wire them together, and you can construct something that functionally is the equivalent of a CDP. Now, is that the best use of your resources? Do developers have other things in their funnel that they need to get done that aren't getting done because you're off building this CDP? Now, if you needed to build a CDP that had some capability that the purchased CDPs didn't have, for whatever reason, so it's really going to be unique to you and you couldn't buy it, okay, sure, at least think about building. You still have to see," Do I have the resources? Do I have the capabilities? Is it the best use of my resources?" There's a whole checklist of things that you want to go through before you commit to this project versus that project. But in reality, a lot of corporate IT departments don't have those resources if they're not in an industry that's traditionally done a lot of work with customer data. Customer data is tricky. It's a skill. It's an art. If you don't have that experience, then starting with the CDP is really not the place you want to learn that. So it's not black or white, but it's simply a question of what's the optimal use of my limited resources. If I can buy something that gets the job done for me, really it's silly to build it. If I can't buy it and I have to build it, then I have to look at whether I really have the skills to build it because, of course, if I don't have the skills to build it and I can't buy it, well, I guess I ain't going to have a CDP. But there's no point to biting off more than you can chew. A lot of IT departments look at it, and they say,"Oh, it's a database. We know how to build databases." But yeah, yes, it's a database, and brain surgery is just like cutting open a chicken, but it's really not. You kind of got to know what you're doing or you're going to have, well, not a very nice piece of brain surgery.

Nicholas Einstein: I hear you loud and clear on that. Great stuff. David, with that, let's get into some live questions.

Speaker 3: Welcome, David. Thanks. Thanks for joining today. It is great to see you live here, and I'm coming to you with my flock of chickens out front. It's interesting that we just ended with brain surgery and chickens. But some really great insights in that first segment. Looking forward to digging in deeper with you now. Please do... Thanks for everyone for joining us live today. Please do hit us with questions in that chat window. We will get to them now. We have plenty of time. Or we'll get to them after the fact with you directly as well. One that just came in, David, around the definition of a CDP. And we did get into the weeds there in that first segment, and we alluded to the fact that Cheetah just went through that RealCDPI certification again, as we do annually. But the question comes in: What are the boxes that need to be checked to meet the Institute's requirement specifically? There are a lot of boxes. There are a lot of questions, but-

David Raab: There are a lot of questions. There are actually six or seven boxes, depending on how you count them. There used to be five because that's how many fingers I have, and then they forced me to add two more.

Speaker 3: Okay.

David Raab: It's much more complicated. I may have to reduce it back to five. But you have to be able to take data from all sources, structured, unstructured, semi- structured data, okay? Because a lot of systems only can take structured data. You have to retain all the detail of the data that comes in that gets ingested and not throw anything away. So for example, DMPs, which we talked about earlier, with summarized data. They won't keep all the details, like all the purchase transaction details, for example. You can't throw anything away. You have to store the data persistently. Once again, as I've already explained, it means as long as you want to keep it. So you may not want to keep it forever, but it should be your choice, not the system forcing you to throw it away. You need to create unified customer profiles. So take the data and pull it together in a customer view, where you can easily access all the data related to an individual, as opposed to a product view or a retail- store view or a geographic view. There's lots of views of data. But the CDP goes to that customer data. It doesn't necessarily mean you have to have integrated identity resolution because you can get good third- party identity resolution tools, but you do have to have somehow an ability to do identity resolution, whether it's built in or not. You have to be able to share the data, which is pretty much what it sounds like. That's an easy one to understand. Usually, there's an API to access the data. It might be queries, depending on how it's done. Somehow the data has to be easily shared with other systems, again because there are systems that assemble data, but don't share it very well. Those are the original five. We added two that specifically relate to real- time. One is real- time event identification. So you have a stream of data coming in to say it's your website interactions. And if you want to pull out somebody who's had a dropped shopping cart, a typical example, that's an event you want to react to in real time. Don't necessarily load that data into the core database, the underlying database, but you want to be able to scan it as it happens, so if you need to send out a message immediately, you can do that. The second real- time thing is real- time access to an individual profile. So if someone comes to the website, you want to be able to look up who they are and pull back their profile in real time. So you already had an access requirement in our original five, but that wasn't necessarily real- time access, and that might be for a bulk of data, not for individual data. So those are the seven, if you count the two real- time, the separate check boxes that you go through, saying this is a real CDP. And the reason we came up with those particular items was that those are the things that you need to be able to do to achieve the use cases, the applications that most people expect to be able to achieve with the CDP. It wasn't just entirely random. It was when people buy a CDP, they think this is what they're going to be able to do with it. These are the things the CDP has to be able to do to actually do those things, because otherwise you buy something that's labeled a CDP, and, well, it doesn't have any real- time access." Well, damn it. That's what I thought a CDP was for." So we're trying to clarify and standardize what things that are called CDPs really do to make the buying process a little easier.

Speaker 3: Yep. Got it. Got it. Makes very good sense. There are a couple more questions coming in. Allie, this will be recorded and available at a later date, for sure. Yeah, absolutely. And another question coming in. Maybe, David, we can get a little deeper into the difference between CDP and CRM. Do companies need both? A question from Marwan here?

David Raab: Yes, most companies will need both. They're very different systems. This gets back to the whole notion of what's a CDP for. CDPs build profiles. Just remember that: CDPs build profiles. CRM systems are not about building profiles. CRM systems are about having an agent on the phone being able to call up a single customer's record, see what it did with that customer, and take notes to update that on what they did today with the customer. Very, very different use cases. One is a one- on- one interaction usually with a human being, maybe a chat bot, but usually a human being and a live customer on the other end. The other is dealing with bulk data about all of your customers, doing analysis, pulling out segments, finding groups, doing all kinds of things at the bulk level. So you design systems differently for those two applications. A CRM system, traditionally, a standard relational database, really good at pulling out a small amount of data on an unrelated topic with a key, like the customer ID. CDP, bulk data, bulk data analysis, a totally different requirement, a totally different design.

Speaker 3: Right. Yep, yep. Indeed, indeed. And we are, at Cheetah, talking a lot about relationship marketing and B2C CRM, which is what we see as having that kind of CDP built in with an engagement- focused CDP. But David, several more questions here. Great stuff. In terms of... Obviously, we hit on it in the top segment. The CDP market is hot right now. There's a lot of talk about it. There are more vendors in the CDPI than ever before and more brands adopting CDPs, right, just spending more money on CDPs now. Where do you see brands and enterprises now kind of getting the most value now? Is there kind of low- hanging fruit where people are kind of looking to that profile to drive their business results?

David Raab: There's actually two ways to answer that. One is what do they do first? What's sort of the sequence of deployment? Most people will start out with the lowest- hanging fruit, which is analysis. Here's this data that's never been assembled before, but now is assembled. So I can do analysis I never could do. I can look at customer journey over time across channel, which I couldn't do before because the data was all fragmented. So the first thing that people do when they get a CDP is they do that analysis of the data. Then the next thing they tend to do is usually predictive modeling, because now I have the data and I can build a model. But neither analysis nor modeling makes you any money. You have to actually interact with customers. So after that, you get into the things that actually have to do with, say, campaign selection, or I'm sending out campaigns, or in real- time interactions where I'm going back and forth with the customer live. So those are the places you make money. So it's interesting when you talk to marketers. They focus on those later- stage use cases, the things that make them money, because that's what they want to do. But then if you look at what they actually do, they kind of tend to do, at the earlier stages first, the analysis and the modeling first. So that's the usual thing. Now again, in terms of where you make money, the low- hanging fruit in terms of applications, things like product recommendations are probably the lowest of hanging fruit, at least in retail, because the CDP is really good at that. And if you look at how a CDP is used and where, retail and media were the two industries, both of which were selling a lot of things quickly. In media, you're selecting which movie to buy or which book or something like that, that kind of media. So a lot of little interactions with a very, very short sales cycle, moments, both in online retail and in media. So that's where having better data lets you build more accurate models and lets you make money really quickly. That's probably the lowest of hanging fruit.

Speaker 3: Yep. No, it makes very good sense. Do you have any thoughts here on when a brand needs to kind of begin considering a CDP? Are there certain thresholds that someone needs to hit? And I echo your previous sentiment about the low- hanging fruit. We see a lot of people getting a lot of value by having that data available right at the moments when they need to be executing messages, highly personalized messages and things. But in terms of kind of... Is there a time when an enterprise or a brand needs to begin to consider a CDP? Are there people that are too small for a CDP?

David Raab: Well, we kind of joke the way to sell a CDP is to ask somebody if they have data."Yeah, we have data."" Is your data perfect?""No, it's not perfect."" Well, then, you need a CDP. Everybody needs a CDP." Certainly, that's the official CDP Institute position perhaps, or maybe it should be. The reality is some companies are too small. If you don't have more than one data source, if you're using one of these all- in- one systems, and I'm talking something like HubSpot or Keap or GreenRope, something like that, Zoho, where all your data is literally in one system, or it's all on Shopify, well then, you don't have to create combined data from multiple systems, and you don't have to share data from one system to another, which really are the core CDP use cases. But most companies, apart from very small ones, do have more than one data source, and they do have more than one system, so they do need to move data from one place to the other. So that's a super- low threshold. The second threshold, which is more important, is, well, do you actually have people who could take advantage of this? Do you have IT people who can run it and set it up? And even though CDPs are pretty easy to run, there's still some skill involved. And there's always going to be some integration, at least connecting to data sources. And then do you have marketers who can take advantage of it, who can actually design campaigns that are going to make use of that data? Because if you don't have any of those, and a lot of really small companies don't, then you're not going to get any value simply because you're not going to be able to use it. So yeah, we don't see like little tiny companies using a lot of CDP, even though they do use CDP- like things. They might get all their data into, say, Shopify or some tool like that and then do marketing against that. But you do have to have a certain size to be a value- add. Yeah, a$ 100 million revenue might be a reasonable threshold. Probably your smaller companies... B2B a little different world, just because B2B companies are smaller and higher value- per- transaction. But there's going to be some minimum niche which it probably doesn't make sense for.

Speaker 3: It makes very good sense. David, again, I think we're right out of time. Thank you for making the time. I'd like to thank everyone for joining live. Scott, I see your question there. I see several questions we have not answered. I will follow up with everyone directly. If anyone wants to learn more about the CDP Institute, David, they should visit the site. Sign up for the newsletter. I love the newsletter and visit-

David Raab: Cdpinstitute.org. Cdpinstitute. org. Got to get that in there. I've got to get a big sign behind me.

Speaker 3: It's a great resource. David, thank you for making the time. Thanks everyone for joining live today. Again, CDP Institute, the Cheetah blog, the Cheetah Product Podcast, PULSE. Thanks everyone for making the time. Wishing you a wonderful day.

David Raab: Thanks, Nick.