The Golden Record: An Interview with David Raab, Founder of the CDP Institute

DR: Well, as you know, I go back to the direct mail days and my career overlapped with some people who had been in the industry for 30 and 40 years back then. So they had been working, you know, with Time Inc and they talked about the days when they kept the mailing lists on little metal cards, addressograph cards they were called, which is before my time, I would say. So the direct marketing principles go back, you know, a century at this point, actually more than a century, and a lot of what we see today in direct marketing is still the same stuff. You know, it always amuses me that people talk, used to talk about SaaS, you know, subscriptions as a service, oh this is so different, dude, I would sell subscriptions, you know, back in the day before you had computers, when we were selling magazine subscriptions. So the fundamentals of the industry, the fundamentals of direct marketing, which is now what we do on the internet, those haven't changed at all. So it actually predates the '80s even. (8.00).

SS: It does. And, you know, it's funny, my dad worked for Reader's Digest for 35 years and, and they, you know, obviously were pioneers with respect to using advanced statistics as an example to determine who best to mail. And, of course, they had continuity mail programs going on. So, a lot of those basic practices have been, certainly, they're not new, as you say. I guess, what is new is the fact that today you've got to accommodate a multi-device, multi-channel customer who, you know, expects to be treated the same, no matter what device or channel they're coming in. And that has presented a significant challenge, obviously, for the entire industry. But today, how would you characterize the state of MarTech - its adoption and utilization in organizations? How would you depict it versus say these previous eras?

DR: Well, you know, I wanna say everybody uses MarTech and to some degree, of course, that's true, there's no company that doesn't do email today. You know, that's MarTech, right? But using it well, even having a decent marketing automation system or even an effective CRM system, if you wanna call CRM MarTech, those are things that a lot of companies still don't do that well. So although everybody has at least basic technology, because you can't run a company without having computers nowadays and you can't really do marketing without having at least some email capabilities and a website, doesn't mean that people are taking advantage of what they could take advantage of with MarTech. There's still quite a ways to go in a lot of organizations.

SS: Why is that? Is that because marketers themselves lack the technical acumen, the orientation to run, you know, sophisticated marketing ops, or are there organizational obstacles to its sort of widespread adoption? What are the challenges here?

DR: Well, yeah, that's actually kind of an interesting question. What stops people from doing it? Or doing it well, right? And I got to say well, it's because it's hard, right? And it is hard, but the reality is most people don't do it cause they can get away without doing it, their company, their business succeeds, even if they do a pretty mediocre job and even if they don't segment their emails and even if they don't personalize their website and even if they don't do a lot of things that we would consider to be sort of fundamental best practices in MarTech because, let's face it, what the marketers do, it's important, but the real success of your company has to do with how well you treat your customers and the quality of your products and the quality of your service and a lot of things that really aren't under marketers' control. So, you know, I've seen this a number of times over the years, there are businesses that are just fundamentally in the right place at the right time and as one of my bosses used to say, you couldn't kill it with a cannon. You know, I worked at "Parents" magazine pretty early on in my career. "Parents" was the same vintage as "Reader's Digest," actually the 1920s they were founded and it was run pretty poorly for a long time, but because people still insist on having kids or at least until recently they did, you know, there are always parents, they always needed that magazine, and you could do a lot of foolish things and that business was not gonna die. And there's just a lot of businesses like that. You're gonna need a plumber, you're gonna need a barber, you're gonna need a bank. You're gonna need these things. And even if they don't do the best job, as long as they don't do a terrible job, they're gonna keep you as a customer. They're gonna do okay.

SS: Although to your point earlier about whether the pandemic has accelerated some trends that have been underway for a while, which is mainly that, you can see it now, the shift away from programmatic advertising, ultimately, where do those dollars get parked? Are they just small straight to the bottom line or are they channeled into doing building direct one-to-one relationships, you know, as Peppers and Rogers talked about in 1993. So their dream, if you, you know, I had the opportunity to interview Don, it was fascinating to go back and look at some of their predictions. So, one of that is starting to come true, but there are these major impediments, and this is a subject for today, obviously, data is one of them, dirty data, data fragmentation. As long as I've been in this business, when I worked for CIBC back in the late '80s, they were talking about, you know, this idea of a centralized customer information file. They called it a CIF. It was a hot topic. I think most FIs at the time were circling around this, recognizing the inadequacy of all of this transactional data they were collecting, and yet today data is still a four-letter word even in this age of big data. Why has it been so hard for organizations to crack the code on this, for them to solve this problem? Is it because of what you just said that there wasn't quite the data dependency there is today?

DR: Well, the data piece of it is hard, okay? Marketing in general, again, you can do a sort of a mediocre job with marketing and succeed but you can't do a mediocre job with data and succeed. Either it works or it doesn't work, really. And it is really hard to pull that data together. You know, back you talk about CIBC, which I think actually might have been a consulting client of mine roughly in that era. And all the banks had what were called CIFs, customer information files, and then they had marketing customer information files, MCIFs, which were basically the precursors of today's marketing automation systems. And, again, you know, this is exactly the same practices, the stuff that Peppers and Rogers would talk about that were basically the same things that direct marketers have been doing for a long time. So the principles didn't change but the data's gotten way more complicated. Again, we have many more sources. The sources are more different from each other because web data really doesn't look much like point of sale data which doesn't look that much like e-commerce data. And so pulling that stuff together and getting the ID matching right, you know, back in the day, again, we used to just match mailing addresses, and okay, if you spell my name with two Bs instead of two A's, I'll still find that match. But if you look at my phone number over here and my browser cookie over there and my device ID here, they've got nothing to do with each other. It's a whole 'nother level of complexity to even just pull that data together, to get, you know, the famous, complete customer view that we all talk about. You know, it's just way harder. And, again, as long as the marketers can kind of survive reasonably well without it, a lot of them won't make that big extra effort to make that happen. But if you're gonna make the effort, it is a big effort, and you really can't get it half right. (14.39)

SS: It seems to me there are forces building within enterprises or organizations to realize that data is important to make these other things work as well as they need to work.

DR: Absolutely. And this is one of the themes that I harp on constantly in my writing, is that customers care about the quality of the experience, not the quality of the personalization. And marketers often think that when customers say they wanna be treated like individuals, they may not want personalized advertising. Well, every survey ever taken where they ask customers whether they want personalized advertising they say, "No. Really, we don't want any kind of advertising." So first we can't call it advertising, but secondly, what they want is they want personalized service. They want returns to be easy. They want delivery to be easy. They wanna push as few buttons as they can and, of course, Amazon has been the absolute master of that, has kind of trained everyone else to try to match the service level that Amazon provides. But it's all about service. It's not about personalization, and service and experience are more or less the same thing, but personalization is just one very tiny aspect of that. So, marketers still have a hard time wrapping their head around that.

SS: I expect this because their marching orders are to drive growth and revenue and sales and for them, that means building the funnel and pushing people through it, which is old school still, right? They still follow a classical marketing model. But certainly, my observation is that that's starting to shift a little bit. Let's talk about data, obviously. So you're credited and you coined the term "customer data platform" back in 2013 in a blog that you wrote. Five years ago, you decided to launch a dedicated industry forum, if I can call it that, called the Customer Data Institute. What inspired you at the time to start it up in 2016?

DR: So the Customer Data Platform Institute - cdpinstitute.org if anyone wants to check it out - was actually started because a couple of vendors came to me in the space. I've been writing about the space, as you say, since 2013 and said, "Hey, all of a sudden, we're getting a lot of traction on this. Let's do something to promote the category." And I didn't wanna work for any particular vendor because I'd been a vendor-neutral consultant for already at that point many years. So I came up, started with this notion of this sort of industry-wide vendor-neutral thing. And I will say, talk about businesses that are in the right time at the right place, you know, easiest sale I ever made. I went to 10 vendors and had them said, "Sure, sign me up." Didn't ask the price, didn't ask what we're gonna do, they're like, "Yes, we wanna do this thing, whatever it is." And the Institute has just, you know, taken off from then because again, there's such a need. And that really has been the story of customer data platforms, not just the Institute. There was just this huge market need to pull the data together and it wasn't met by the big vendors, you know, Salesforce, and Adobe, and IBM, and Oracle, all the people who probably should have done it. Just didn't quite grasp that it was different from what they were already doing. So they kind of kept telling the customers, "No, we've given you a tool for that. Just throw it all into your CRM system or throw it all into your marketing automation system." Or, "Don't throw it all into anything, but just pull it all together dynamically in real-time and have some sort of a shared ID." Well, that doesn't work. And it took those guys a long time to figure out it didn't work. It took the marketers way less time. And in that gap between when the marketers knew it wasn't working and the big vendors hadn't quite figured out that it wasn't working, all these other vendors came in and built systems that actually did it sort of the right way, if you will. (18.13)

SS: What vendors were pioneers in the space then and sort of realized there was a market niche that wasn't being served? Did it come out of the tag management space? Like what was the genesis of some of these solutions, some of these vendors?

DR: Well, there actually were a couple of different classes of vendors who contributed to it and, you know, back also in 2013 after I coined the term I wrote an industry report that profiled, I forget how many vendors now, you know, 10, or 20, or 30 and some of them came out of tag management. Some of them came out of marketing automation or campaign management. Some of them came out of the B2B lead scoring business. And what they had in common was they all had to assemble data from multiple sources in order to do what they kind of wanted to do, whether they wanted to do lead scoring or campaign management, or even programmatic actually ad serving, whatever it was, they needed data from more than one source that they couldn't just get within the system. That was really the core thing they had in mind. Originally, when I defined the term CDP, it was an application to build its own database and then I quickly realized that, you know, it's not really the application that matters here, it's the database because once you have the data assembled, you can use it for whatever application you built it for originally, but you could also use it for a bunch of other things. So, we kind of switched our focus and a lot of the vendors eventually came along to realize that as well. And then, you know, every now and then some of them said, "Yeah, you were right."

SS: That's good to hear. You went from, I think I read 26 vendors or something to that effect as early signups to what, are there a hundred vendors in the space now of different types?

DR: Well, yeah, I think the first report might've had 26, and I forget how many of those were sponsors at the Institute. I think we started with 10 sponsors. Now, actually, I'm just doing my next report and I think we're at 150 give or take. There's a couple who I just heard about this week, which is a normal week for me. So, I have to add them into the list before I publish the report. Of which about a third or so, about 50 or so are actually sponsors of the Institute, but there's about 150 companies that we class as CDPs. And let me make very clear because the biggest problem with CDP is just because it's so confusing because there are a lot of companies and part of the reason that we count so many companies is that we said a CDP is really a set of functions. So long as your software has that set of functions, we'll count you as a CDP no matter what else the software does. So there are e-commerce platforms that have a CDP kind of inside of there, there are email systems, and web content management companies, as long as they have what a CDP does and as long as they themselves will share that data with other systems, because if you just assemble the data for your own use and you don't share it, you're not a CDP by definition. A CDP has to share its data. But as long as you...so even if you build it kind of, you know, to run your e-commerce platform better, as long as you actually expose it on other systems for other purposes, we'll count you as a CDP, and that is the bulk of those 150 or so companies that have a whole bunch of other functions in addition to the CDP functionality. And, of course, CDP functionality is just creating those unified customer profiles. That's what makes you a CDP. (21.30)

SS: Right. And that's certainly a key term, "unified customer profile." You know, I would say that CDPs have been somewhat synonymously, if you will, associated with marketing databases. Is that because marketers mostly have been the sponsors or purchasers of these systems?

DR: That's right. Most of the early CDPs were adopted. Most of the early adoptions I should say were in marketing, particularly actually in retail and in media, were the two particular industries - both industries, we have a lot of transactions per customer with relatively low ticket, usually in a quick buying cycle. So, you can get feedback and personalization, which is the main thing you do with the CDP or rather segmentation is immediately measurable. The value of better data is immediately apparent in the quality of the segmentation.

SS: That seems to be the number one use case for CDPs, is when marketers are asked about it, they say, "Yeah, the number one thing I really want out of this is better segmentation."

DR: That's right. That's right. Because that requires that unified data. And that's what the CDP gets you, that you mostly couldn't get without one.

SS: I know you've been asked this question before, but 2016 seemed to be an inflection point. And whether that was coincidental with the start-up of your Institute, I'm not entirely sure, but do you have any idea why that year was the turning point for CDPs, why it suddenly took off?

DR: You know, I've never been able to figure it out. To be clear, it definitely was not the Institute's doing. You know, vendors came to me and said, "Hey, it's taking off. Start the Institute." And that's how I started the Institute and then it took off. So much as I'd like to take credit, I cannot. All we really know is that the products that kind of were foundational for the industry mostly started out in that period before that, so 2013 to 2016 period, takes about three years to build the products, now you're looking at around 2010. So it was just after the 2008 crash that a lot of these things and people started looking around and recognizing the issue and started to build out what eventually became the CDP industry. So certainly, if you look at the origins of the vendors, the supply side of it, if you will, you can kind of figure out why that would have been the right period of time for that to happen. Why the market took off just...the need was just more and more pressing, and people probably had time to figure out that they weren't gonna get it from their normal vendors and everybody was sort of on the same schedule and that's just when it hit. So, you know, I wish I could point to something specific. And believe me, I've scratched my head many times over it, but...

SS: Well, I guess that was the point I was making earlier about one year seems to bleed invisibly into another because there were multiple influences, obviously, that affect that. Now, you said that CDPs are or you were all doing category for a lot of folks, in part, due to, you know, the diversity, if you will, of the vendors in the space. Just for clarification then, you know, you have an official definition of a CDP. Can you just share that with the audience and how it's different from say a DMP or a master data management solution, etc?

DR: Sure. Usually, you need a slide to do this properly. The official CDP Institute definition is packaged software that builds a persistent unified customer database accessible to other systems. So packaged software is something you buy, you don't build it. So, it's not a data warehouse or a data lake that you would build for yourself. Unified persistent customer database. Unified, it brings in data from all the sources. Persistent, it stores it someplace. It's not just accessing it item by item like an integration platform, like say a MuleSoft would do to. Database, it's organized around customers. So it has a customer view of the data, not a product view or a geographic view. There's lots of other ways that you can organize data, but this is built to create those customer profiles. And then accessible to other systems, it shares the data. It doesn't just use it for its own purposes. So, a DMP is a much narrower kind of product. It doesn't actually store all your data. One of the sort of implications of that unified customer database is that you don't throw any detail away. With the DMPs, because they're built really just to generate audiences primarily for advertising, they have to work very, very quickly with huge, huge masses of data. And the way you do that is you combine some of the data, you don't store every transaction, you just have buckets that say, "Oh, this guy's a shoe buyer," Or, "This guy's bought in the last 90 days" or, you know, whatever it is. And DMPs, in particular, because they're mostly built around cookies don't really store the data for that long. They do store it, but they throw it away after 30, or 60, or 90 days because that's how long cookies last. So you don't have that long-term persistence. That is very important in the CDP definition because if you really start profiling customers over time and tracking how all of their identifiers have changed, you really got to store that data someplace. You can't just do it by accessing it in whatever the source systems are. So that's what separates … you know, CRM and marketing automation email systems, those really work primarily with their own data. They're not very good at importing other data sources. They might be able to import a little bit, but by and large, they're not built to handle that huge volume, say all the web data that you would suck into a CDP and not throw away any detail. MDM systems - master data management systems - are systems that are really about setting up masters and master identifiers. So it's only a certain kind of data, just the identifying data for people who are for MDM, you know, it could be for products or other things that have IDs. So it doesn't again, store in the volume of data that you would store in the CDP. Even though many CDPs need master data management capabilities, they do have to standardize and unify that data to pull together the profile. So, some CDPs do that, some CDPs actually would call out to a third party system or would actually adopt an existing set of master identities that the organization might have built - banks, for example, to come back to your CIBC days, they've had master customer files for a long time, because they had to do it for things like fraud purposes and tax reporting. So, they always had to pull that stuff together. So, they didn’t need a CDP for that because they already had that. They needed a CDP for other things, but they were very slow, which actually we're just now beginning to see adoption in the financial sector, in part, because they kind of didn't have quite as pressing a need because some of it, the identification bit that you might get from a CDP, they actually already had that in place for other reasons. And so, it was a little less of a need to add a CDP to get that value. (28.35)

SS: Is the CDP – yes, it creates a unified customer profile – but the main client it seems to me is obviously marketing. And that can be shared on a case by case basis with customer service or sales or whomever. But is the CDP a client database where its dependency lies in drawing data out of the data lake, out of the EDW, out of the CRM system, and just simply unifying it, or is it really a means of adding value to the data and feeding that back out to the CRM system, indeed the data lake for analytical purposes, etc.? What is the relationship there? That's where I get confused.

DR: Okay. So if you have a data lake or a data warehouse that's already pulling data from your source systems, then that can feed into your CDP. Okay? If you don't have that, then your CDP might actually ingest the raw data from the sources. So, see, some way or the other, the CDP is gonna get that data. Now, even if you have... Well, data lakes are not unified at all, right? Data lakes are just literally a bunch of little pools of data that are just sort of throw it off to the side to be used typically by a data scientist who does a lot of work on it. But the CDP then will sit on top of that, pull it together, do all the unification, and so on. A data warehouse typically has a lot of that pre-processing already done to get it cleaned up into the warehouse, but warehouses are limited in what they do. They don't have the full scope of a CDP. So either way, they can send data into the CDP. The mission of the CDP, the unique thing about the CDP, is it will pull in all that data from all those sources and unify it and bring it together and make it accessible in sort of usable customer profiles which a data lake won't do, and a data warehouse will do but with a limited subset of data, and then those profiles will be available for whatever persons who want. Now, some CDPs will have very extensive analytical capabilities of predictive modeling, for example, or attribution. Some will also even have campaign management, and personalization, and recommendation engines … so you do have a lot of those additional value-added capabilities in some CDPs, but the value of the CDP itself is constructing those profiles, making them available, just the mere act... I shouldn't say mere … the extremely difficult act of pulling together that data and making it sort of usable and accessible, properly formatted, accurate, clean profile is where you get a lot of value and making that data then and exposing it and shareable and available to your marketing automation or your CRM or your email or whatever other system, or your customer service system, or your operational system. It's not just for marketers anymore. The CDP, or that was the original use case in many organizations, because that was where the pain was the greatest and that was because the value of pulling data in from multiple systems was the most clear. Other departments in companies now, in particular, they worry more about customer experience and they define customer experience more broadly than just marketing. They now say, "Well, you know, we need this unified data to do our operations properly. We need it to do our customer service properly. We need it so we can recommend products on the website," which is not necessarily something that the marketers themselves control. We need it to tell the call center agents what to say to existing customers. It all requires unified data. So, the CDP then becomes a enterprise-level or a corporate level resource, not a marketing department-level resource. And that has some implications on who runs it and so on.

SS: It's interesting because I read the blog "Better Data Science" and, you know, which is written largely by data scientists and analysts, and it strikes me every time I read it, how much work and effort they have to put into actually drawing data from the data lake or a data warehouse as the case may be. They never mention CDPs as a reference point.

DR: That's right. If they did they wouldn't be doing all that work because that's exactly what the CDP does. And when you get into the enterprise, if it's the enterprise buying a CDP, it usually is the analyst, the data chief data officer, or the chief analytics officer who kind of owns the enterprise CDP because that's what it does, is it makes their life, you know, way, way simpler, because otherwise, they just end up doing a lot of repetitive work.

SS: And a risk of errors in doing that, but absolutely, that seems to me, one of the big, huge business cases for doing a CDP. So Gartner has - and you no doubt read this, I'm certainly interested to get your reaction to it - recently urged marketers to abandon this utopian, that's my word, utopian pursuit of a 360-degree view of the customer believing it, I think they said, to be unobtainable. Again, my words, not theirs. Now, I have to think based on what you've been saying, you disagree with that little, somewhat provocative statement. But I mean, do marketers really have a choice here? In fact, do enterprises have a choice given this desire to be more customer-centric?

DR: Well, I think... I guess there's always a choice, right? That's what we were saying earlier, most companies survive, you know, if you don't do it as well as you might. I've actually never liked the term 360-degree view because it does imply the sort of total completion which is never gonna happen. You know, you're never gonna know what I had for breakfast unless I tell you. And maybe if I, you know, if I had a video on my house, you might wanna know what I have for breakfast, but I'm a little too paranoid to have video cameras around my house other than this one. So, you know, on some level, of course, it's utopian, of course, it's silly, of course, it's never gonna happen. Of course, it's impractical. Even in terms of other things like tracking the weather, the local weather, well, you could theoretically keep a complete historical record of all the weather surrounding every one of your customers at all times, but that will be kind of silly because you would not use that except for like one one-hundredth of 1% of the time when you happen to be interacting with that customer and in some contexts where the weather matters. Inventory levels is another thing. It just wouldn't make sense to store that separately. There's certain things that just make sense to look up when you need them and just have that real-time connection. There are other things, again, like changes in customer identifiers that it does make sense to pull in and store separately. So it's never gonna be a true 360-degree view and nor should there be, and got enough that we're living in that world if there were because there's enough surveillance going, you know, even in today's world. But you have to use judgment about what does and doesn't make sense. And I think that there's a lot of data that does need to be stored in a separate system that does what a CDP does. I don't care if you call it a CDP or not. That should not just be read in real-time from other systems for a variety of reasons. So, you know, yeah, no one really ever thought that you were gonna store all the data at someplace else that's not practical, but you have to do it. You have to make intelligent judgments about what does and doesn't make sense to store. (35.50)

SS: Somebody is gonna have to suggest to Salesforce they change the name of their CDP.

DR: Again? They just changed it. I've lost track.

SS: Did it go from 360?

DR: Oh, 360. Oh, yeah. They got obsessed with 360. Everything was 360 for a while. I think it's now just Salesforce CDP.

SS: I wanna ask you though about...because you've been alluding to the privacy and the surveillance society, etc., and consumer consciousness now of being tracked. Is the CDP central then to upholding or compliance with privacy legislation, whether existing or, you know, future requirements?

DR: I thought you were gonna ask me if it's a privacy threat.

SS: I'm a marketer, David.

DR: That's right. That's right. The notion doesn't confuse marketers. It is very helpful in compliance with privacy regulations. A lot of the things that you have to do to comply with privacy regulations are the things that you have to do to build a CDP. The first step in complying with privacy is discovering where all of that customer data sits, where all that personal information sits in your systems. Well, guess what, that's what you do when you build a CDP and then you have to pull it all together in one place so you can assemble it and share it out with someone. If they ask for a subject access request, well, guess what? That's exactly what a CDP makes possible. If you automate, if there's a subject access request to change, well, guess what? The CDP gives you a way to go back to connect them back all the source systems. If you wanna store consent, capture it and store it someplace central, well, what better place than a CDP? That's what it's for. If you wanna put governors or controls or governance on the data that says, "Well, don't send out data unless you can prove that you have consent for this particular use case, well what better place than the CDP as a single point of contact with your data to funnel it all through and check it there and to keep records of your processing activity, CDP is the perfect place for that." So the CDP gives you a lot of the specific things that you need to comply with privacy regulations. So, in that sense, it is a very, very useful technology and, you know, we thank all the privacy regulators in Europe for helping those CDP sales.

SS: That's right. And coming to Canada and the U.S. soon. So let's talk about ownership. And I've talked about this earlier. I mentioned the fact that, you know, marketing database is somewhat synonymous with CDP simply because marketers were the sponsors, buyers, purchasers, held the purse strings on it. But we, as we've been talking about through this whole conversation, data now is crucial to the customer experience, and therefore, enterprises are starting to realize that that's the case. IT who, you know, has played a support role, I would say, certainly in terms of integrating the CDP, but, you know, wasn't taking necessarily the lead role in it, do they now muscle their way back into the picture? I mean, I remember the days when IT was the big obstacle to access the data - do they muscle their way back into the picture because data hegemony is gonna become crucial and therefore they will feel they will need to own that data stack, that data platform, and the CDP is a component of that? That's one part of my question. And then if IT gets involved, are they gonna wanna lean toward build versus buy? Because integration often is a tough thing. And so, you know, maybe they wanna customize the solution now, which takes me back to the early days of data warehousing. What's your sense of what IT's role will now be going forward in making that purchase decision and, in fact, owning the asset?

DR: Well, you're exactly right that IT is getting more involved, again, because there's this realization that the organization as a whole needs unified data for a variety of purposes, not just in marketing, and then they see what marketing's got this thing called a CDP or marketing wants to buy this thing called a CDP and IT, which is, you know, allegedly sitting above with this great wisdom and say, "Well, you know, other people are asking us the same question, maybe this shouldn't be marketing project. Maybe it should be an enterprise project." And then being IT people, they look at it and say, "Hey, it's just, we have data warehouse. We have a data lake. What's the big deal? We're just gonna do a little bit data unification. We have an MDM system for that matter. We can build this thing. Why should we go out and pay somebody to do it?". And then so the build/buy discussion which had kind of gone away for a couple of years, it was a nice little respite, is actually now sort of roaring back very much. And there's a lot of vendors out there who are building data pipeline systems which is a very hot category right now, for example, that are kind of providing IT with the tools to make it easier, so it gets their better tooling for IT to build it, IT wants to build it, at least wants to think about building it. You know, IT, I would say most IT departments will gladly say, "Look, if I can buy something, I'll buy it. We have enough work to do. You know, we only wanna build systems that are truly gonna give us competitive advantage," which usually means I can't buy it. Every now and then though, you'll get an argument that says, "Well, even if I can buy, I don't wanna let my customer data, which is, you know, such a critical asset out of my control," which I don't consider to be a valid argument because you know how much control is it really? But in any of event, the IT guys, they kind of wanna look at it. What they don't really understand is it's not just another data store. Managing that customer data is actually pretty tricky. Doing the data unification is pretty tricky. Having all the connectors to all your systems as something that you have to custom build for yourself is a lot of work, whereas if I can buy that off the shelf from somebody, it saves me a ton of time, and money, and effort. Maintaining this thing over time, okay, you can get it built and you can get out, you know, the 1.0 version from IT which meets maybe 80% of the initial requirements at about a 45% efficiency level, but it's good enough, but then people need enhancements and at that point you're like in the maintenance mode and the IT guys are on to he next project and you got the C team doing the maintenance on it and, you know, maybe they can tie their shoelaces. They're not gonna do great, fabulous, you know, enhancements to the system. So, you have this, you know, technical debt just keeps getting worse, and worse, and worse. So there's a lie - even if they could build it and, you know, of course, they could build it. Look, they're smart people. They're good at what they do. Often it's not the right choice. Now, where it may be the right choice, actually coming back to your banking friends, is if you really do have a really good IT department and you have a very complex environment with a lot of legacy systems, which a lot of banks do, for example, where there are not gonna be any connectors available off the shelf anyways, you're gonna have to build them anyhow. So, you know, and if you have like a good customer information file, if you have the matching in place already, then maybe the CDP building those unified profiles is a modest extension of a very complex environment that actually does make more sense. So I've had people in big financial institutions make what I consider to be a reasonable case for building it in-house, or at least taking a close look at building it in-house, but you really got to know what you're doing and you really got to remember all the ancillary things – its the connectors that can kill you. Building all those connectors to your dozens of marketing, or hundreds of marketing systems. You’ve got to build a custom connector to each one - not much fun.

SS: Yeah. We're gonna talk about that momentarily, but the other, you know, potential trend, and I'm interested in your opinion on it, is the verticalization of the category, that is you have financial-specific data models, retail models, etc. Is that a likely direction the industry will go in?

DR: Oh, yeah, definitely. We've seen that really for a couple of years now. It's been clear, and so there are now, for example, you know, three or four financial services, banking CDPs, just all they do is bank a bit, banking plus insurance, which they do have the pre-built data model. And the people who understand it and they have the connectors into the banking systems and they have the functions that they know bankers are gonna need that retailers aren't gonna need or telcos aren't gonna need. And in banking, in particular, they're gonna run on-premise because the bankers wanna run it on-premise for security reasons. Telcos also bought on-premise, not so much for security as much because the data volumes are just too big to move. So, you know, there are specifics for each industry. We see there's two or three travel CDPs, you know, they talk to ticketing systems and have those functionalities. In every industry, actually, we see specialist CDPs cropping up.

SS: Well, it's kind of what happened to the CRM industry back in the '90s, same thing. Now, in terms of the future of the CDP industry, you know, there's some question as to whether it remains an independent, separate category. You know, we talked about Salesforce earlier having its CDP, Adobe has its CDP, you know, all of the other, I'm pretty sure, marketing automation solutions see a big play there too. It's almost back to the future to some extent here. Do you see a merger between those marketing automation suites, if we wanna call it that?

DR: Yeah. Well, again, we consider a CDP to be anything that does what a CDP does regardless of what other function it is. So you can have a CDP inside of a marketing suite. And, again, like Salesforce and Adobe have finally built ones that meet our definition. Persistence was the thing that it took them a while to accept that they needed, but then they all realized that kind of, you know, from painful experience of trying to do it the other way and finding it didn't work. So they're all there, they all have systems that are CDPs. They're baked into their larger platforms, which makes total sense. And, again, from a user's perspective, which is really the perspective that I try to adopt, as long as the users get what they need, as long as they can get access to those unified profiles into using their marketing systems, or their customer service systems, or, you know, whatever operational system they need to do their jobs, I really don't care if it's baked into something or not. It's almost it does what it needs to do and it gives the users what they need to do and everything else is of less importance to the people who are selling it, the vendors, but really kind of opaque to the actual users. (46.16)

SS: So I just wanna shift gears in the time remaining here from CDPs to now that we're talking about the marketing automation platform market, there's something called Raab's law, which obviously you're familiar with, that says that marketing suites will always trump best of breed systems. I did have this conversation with Scott [Brinker] who, you know, implied that momentum seems to be swinging in favor of what he termed, and I think usually goes with the term as well, platform ecosystems, where you had this core set of modules that are connected to as many third-party apps as you want. It seems to me that in a business where the number one nemesis as I say is complexity, that may just add to it and also puts the onus on users to figure out what the best apps are to use and I think the other figure I've seen is that, you know, most marketers only use about 60% of all the apps within those solution platforms. Which way is this likely to go? Are you seeing this big shift yourself into these, you know, for lack of a better term, ecosystems, and does a CDP live within that ecosystem?

DR: Well, I think I still think that Raab's law, which we just summarized that suites win...we're gonna terse little people here, so far it still holds. You know, people will buy separate applications and attach them to a platform if they can't get what they want in the suite. So if I really need the latest, you know, virtual reality presentation tool and it's not part of my Adobe suite, then I'm gonna go out and buy it from whoever I'm gonna buy it from … Colton apparently does that. But once it becomes popular, Adobe will say, "Oh, that's really just a feature in my content creation suite. I'll just add it in." And then all of a sudden, maybe somebody wants that best of breed version of that but 90% of people say, "Yeah, it's part of my thing. I've already paid a license for it. I don't have to integrate it." And if I disagree with anything in the platform ecosystem notion, it's that integration goes away as a problem because it just never does. We just moved away from an all-in-one tool that had our website and our email on the same platform to having WordPress over here and MailChimp over there and Zapier in between. And it has taken months to make what is the absolute, simplest integration in the universe. Like it's supposed to be click, click, click, it's done. Well, guess what? It's not. And developers, you know, are tearing their hair out to do a very, very simple integration. And, you know, these are not, you know, people who do this every day. They're really web developers, so probably maybe somebody else who could do it in two seconds, but the reality is it still works. And if I wanna add yet another tool and now I have two databases, and all that, it just doesn't go away. So the idea that, you know, these things just plug right into the ecosystem and they work, unless it's really something that has very limited functionality, is really relying on the core platform to store all the data and I'm just sort of doing some little API calls here and there, if it's anything more complicated than that, which most things are, then there's a cost to that integration. So yeah, you know, you can look at, you know, Salesforce has done a great job, right, you know, with the app store that they have, right? And obviously, you know, Apple with the true App Store, of really making things really easy to do, but once you get past really simple stuff, there's always technical work involved with that. I don't think that will ever go away. And that's always gonna make it easier to just buy one system to do it all.

SS: And where does this no code, low code movement fit?

DR: Well, for the evidence thing, which no code and low code, you know, Excel is no code. You just do stuff. You don't have to know anything about programming unless maybe you wanna use a macro and a complicated formula. And so, no code is for business users, for human mortals, right? Low code makes developers more productive, but you still have to know what you’re doing, you still have to be fairly technical. So it actually, it's people lump them together and they're really pretty different. And we actually just did a blog post on this sort of saying, "Well, which makes most sense to when?" If it's something where there's a lot of variety and the users each do things differently and fairly complicated, then giving them a tool like Excel where they can just kind of like do their own and they're not gonna do too much damage if they make a mistake in Excel formula, that's a great low-code application. But if it's something, we have hundreds of people doing exactly the same task, and if that task is something that is actually standard across an industry like say a lot of accounting tasks are, just buy a package because the package vendors figured out how to do that. But if it's something that not a lot of people do, but it's still a lot of people share, then maybe do a low code thing so my developers can custom build it because nobody else does it the way my company does it but hundreds of people across my company are doing exactly the same and I wanna make sure they do it exactly the same way. And I wanna make sure they do it right. That's where you kind of wanna have professional developers involved because at least in theory, they have better discipline and better control and governance than, you know, your random business users will have. So, there are certain situations where kind of one makes more sense than the other. It's not that anyone is just gonna, you know, take over the world and everything's gonna be no-code or everything's gonna be low-code or packaged or anything else. It's the right tool for the right job.

SS: Well, and it strikes me that, you know, that yes, there's a challenge with unifying data, there's a challenge with unifying, to some extent, systems as we've been talking about but also there is a challenge with respect to unifying processes. And, you know, this was the CRM challenge back in the '90s, trying to re-engineer a process around a solution doesn't exactly work. So, you know, the no-code, low-code thing, you know, may hold out the promise of being able to address that particular gap. I don't know. I wanna take the few minutes remaining here, Dave, and this has been really enlightening and I've been in this business a long time.

DR: You're the first person that's ever mentioned Raab's law to me actually.

SS: I don't know why that would be the case. You're very well read and very well-known. Let's look at the MarTech landscape as it exists today and as we started this conversation, you know, there's been sort of, you know, various eras that we've passed through over time, but we seem to be hurtling toward this new era of omnichannel engagement, real-time personalization. To your emphasis earlier on service being crucial to the value proposition and needing to get that right, you know, does that suggest that even the term MarTech ultimately becomes obsolete, that the industry has to recognize that this isn't about marketing. This is about one customer, one relationship across multiple channels. Is that going to fundamentally change the landscape as we know it today?

DR: Well, you know, it really should be called customer experience tech, but somehow CEX Tech doesn't quite...I can't use that one in public for obvious reasons. So we have to find a better term that's...

SS: David, you coined "customer data platform." Surely you can come up with something!

DR: We're working on it. But yeah, it has to be customer... customer management actually is kind of an insulting term. You shouldn't manage your customers, right? You should service your customers. So experience is probably a better term for that because that's what's usually given an experience, you let them have an experience. You co-create it, whatever. Yeah. It's not just marketing, you know. For a while, we talked about MadTech, which is marketing tech plus ad tech equals MadTech, which was sort of fun because it had a fun little name to it. Some people actually use that term, but it's not just that. It really is CX tech in a broader sense. And we'll get there. Well, again, probably not with that particular acronym to it, but because the boundaries are just dying and, you know, marketers think they're in charge of customer experience, but nobody else thinks they are.

That concludes my interview with David Raab. As we learned, the CDP category has exploded in the last few years, driven by marketer’s need for a single view of the customer and the urgency to offer a better customer experience through the use of first party data. The CDP is explicitly designed to assemble and store a unified customer profile and expose it to other systems so that it can be activated. For marketers, tired of waiting for IT to create the mythical “golden record”, the CDP fills a gaping hole in the data stack. And for IT, it relieves them of trying to replicate that functionality in the data warehouse environment, when they have so many other end users to please.