CDP: Is the Future Now?

Speakers:

• Josh Francia: Chief Growth Officer, Blueshift
• David Raab: Founder, Customer Data Platform (CDP) Institute

Welcome and Introduction

Josh Francia: Hello everyone and welcome to today's webinar. Please take these first few moments to get settled. We will start in just a moment here. All right, we'll go ahead and get started. So hello everyone and good morning or good afternoon.

My name is Josh Francia, and I'm the Chief Growth Officer at Blueshift. We are a Customer Data Platform, focusing more on the activation side of CDPs. I'm really pleased to have David Raab here. David, would you mind giving a quick introduction to the team and to the group here about yourself?

David Raab: Always happy to talk about myself, Josh. That's my favorite. So yeah. As you say, back in 2013, I did coin the term Customer Data Platform. I've spent most of my career as a marketing technology consultant and industry analyst. Before that, I worked as a marketer. But now, I really spend my time evangelizing and trying to help companies do a better job with their customer data, which in many situations means they need a CDP. So those two things go together quite nicely.

Josh Francia: Yeah, absolutely. Today, David, we're going to be talking about a variety of things related to CDPs, but mostly focused on: Is now the right time? Is the future now? Is now the right time to kind of talk about a CDP, to get a CDP into your stack? We'll cover:

• What is a CDP?
• What is not a CDP?
• Are there different types of CDPs?
• Can you have more than one, and can they work in harmony?

I encourage you all to ask any questions you may want. On the bottom of your Zoom window, you'll see a Q&A button. You can click that and post a question. David and I will be able to look at those questions and respond to them throughout the program. We are also recording this, so we'll be able to send this recording out to everyone that attended and also anyone that was not able to attend.

Defining the Customer Data Platform (CDP)

Josh Francia: Let me just start with a very broad, high-level, but important question: What is a CDP? How do you define a CDP? David, give us your definition.

David Raab: So the official CDP Institute definition is: "A CDP is packaged software that builds a unified, persistent customer database that's accessible to other systems."

There are three key components to that:

1. Packaged Software: It's something you buy, not something you build like a data warehouse or a data lake.
2. Unified, Persistent Customer Database: It takes data from all different sources and unifies it. It stores this data in its own data store, which is very important. It's not just pulling it from one place on demand, which would make it hard to see history.
3. Accessible to Other Systems: It's designed to share data with other systems. Many pieces of software build unified, persistent customer profiles but only for their own use. A CDP, by definition, is designed to let other systems use its data as well.

Josh Francia: And if you think about that, when you talk about the accessibility, what do you feel like CDPs were originally created for? Who was the target audience for accessing that data?

David Raab: The origin story was back in 2013. I began to see systems that were building their own customer databases as part of an application (e.g., a lead scoring system or a campaign management system). Before then, predictive analytics tools or campaign management tools would be attached to a custom-built data warehouse or customer database. What was new about the CDP was that it was packaged software building that database.

The original users, by and large, were marketers. They were the ones suffering from the pain of having cool predictive modeling or campaigning tools but not being able to use them because they couldn't get a database with all the necessary data. This was happening as we saw more and more online data coming in (beyond just email, direct mail lists, or old commerce customer lists). It became increasingly obvious and painful to have data in different silos. So, marketers said, "We really need to get this in one place," and the CDP evolved from that demand.

Josh Francia: I'll echo that. I remember being in marketing in travel and finance, and you'd salivate over all the data the company brought in. Then you'd get really disappointed when using your email marketing platform or social media platform, realizing you only knew what that platform told you about the customer. You knew the company had a ton more data, but you had no way of accessing it to influence your marketing. I felt that struggle a lot, thinking, "Man, if only we had access to this, our campaigns would be so much more relevant and better."

I think that's what drove CDP adoption. That need was real, and it became even more real as more channels emerged where people were producing data. Ten or fifteen years ago, email data floating only in email systems was okay because there wasn't a ton of other relevant data being produced. But now, people are on mobile, desktop, in-store, on the phone – all producing data inside the company. Marketers struggle if they can't access all that data to make relevant points and offers. That's where the friction lies.

The Evolution of CDPs: From Niche to Enterprise

Josh Francia: So, how have CDPs evolved since then? I feel like every day someone else is claiming to be a CDP. Talk to us about how it's evolved since maybe the beginning and when you initially coined the term, as well as when the CDPI was started.

David Raab: The original impetus was application software building its own database. Many early application vendors or CDP vendors discovered that there was more value in the data they were assembling than in the application itself. Predictive modeling tools and campaign managers were common, but the assembled data was uniquely valuable. They quickly realized that other systems and even other departments could use this same assembled data and gain significant value.

So, CDP vendors expanded the accessibility part of that definition. We even changed the official definition from "application software" to reflect this. That's probably the first big change: the recognition that access is a crucial part of the CDP's value proposition.

In more recent years, we've seen the category mature, similar to how CRM matured. This leads to more specialized systems by vertical industry, company size, or user type. More recently, we're seeing an interesting trend of CDPs being pulled out of the marketing department and becoming a corporate resource for IT department use, so that everyone can use it. That's one of the newer trends in the last couple of years.

Interestingly enough, there's also a resurgence of the build versus buy debate. By definition, a CDP is packaged software you buy, not build. But once the IT department gets involved, they might say, "Oh, it's a database; we can build a database." Of course, it's way harder than it usually looks. The good ones at least take a careful look before they leap. Some others just say, "What the heck, we'll give it a shot," and two years later, they're still struggling. That's life in the big city.

Josh Francia: It's funny how that build versus buy debate comes up all the time. Engineering groups, knowing their data best, want to build. That's what engineers love doing. They feel they can build a customized version specific to their needs that might even offer a market advantage, a proprietary technology to gain an edge over competitors. These are often altruistic ideas.

But what ends up happening more often than not, at least in my experience, is that the enthusiasm quickly wanes when they start getting their first feature requests and bug reports. Teams that were so enthusiastic eventually leave, leaving no documentation on how the system was built. Then, an incoming engineer says, "I don't know how this thing works, but everyone wants it, and I'm not sure how to fix it, so we have to rewrite it." If you fast forward, they could have bought something and been miles ahead, still with the customization they need. That's one of the greatest things about CDPs as platforms: they ingest data from various sources a company has, but they offer a lot of flexibility in how that data is used. Different companies can get wildly different results from the exact same implementation. It's not necessarily the CDP itself; it's more about facilitating value delivery to your customers.

Have you seen that happen a lot, where companies think building is a good idea, but ultimately, they could have customized a bought version more effectively?

David Raab: Exactly what you said. They start enthusiastically, then find out it's harder than they thought. Some will plunge ahead. Often, the marketing department or the business user sponsoring the project will get frustrated, go off, and buy one, or force the issue. By definition, CDPs are built to be flexible. They're built to take all data sources and share data with all destination systems. So, they are inherently a very flexible kind of technology. And as you just said, ultimately, it's up to the user to make good use of it. You can't blame a CDP or any home-built technology if a user doesn't know what they're doing, or how to take advantage of it, or doesn't take the time to learn the system. You won't get a lot of value.

Just to go back to the question about change, the other big change in the last two years or so has been the privacy issue. It's come up so much more than it had been. And that's part of the reason that enterprise IT groups are taking more interest in the CDP, because it's become very, very clear that privacy and security are enterprise issues that somebody can't let the marketers handle by themselves. They're not equipped for it, technically, and honestly, they're not all that emotionally intuitive.

Josh Francia: Well, that's true, right? Because it becomes a liability for companies now if they can't audit, enforce, or report on customer privacy decisions. GDPR, CCPA, CAN-SPAM – these laws mean companies must honor a customer's right to say, "Don't market to me at all," or "Forget me." They have to honor that universally, not just in one siloed application, and be able to audit and prove when it happened and when they stopped. CDPs provide a nice value-add for companies to be compliant with these things. They also allow marketers to execute and operate on clean data; they don't have to worry about whether they can market to a person or not, because the information is right there.

Classifying CDPs and Their Harmony

Josh Francia: Let's go back to the classification of CDPs. There are a lot of different CDPs out there. At Blueshift, we say we're more of an activation CDP, focusing on campaign management and connecting the omnichannel journey. There are other CDPs that are very data-focused CDPs, and they don't really talk about the orchestration side. How do you classify CDPs? What's a good parallel or classification you can share with the group, and when they're evaluating CDPs, what bucket should they fall into?

David Raab: Well, we have five buckets at the moment. Although, to be honest, I think the two that you just laid out – ones that focus on data, and ones that focus on application or activation – are probably all you really need. But, you know, the world is divided into two kinds of people: those who divide the world into two kinds of people and those who don't. I'm actually one of those who divides it into three kinds of people, so I had to have at least three different classes of CDPs, and it's now up to five.

But again, we talk about:

1. Data CDPs: These just build the unified persistent database, and that's all they do. That's what makes them a CDP.
2. Analytic CDPs: These build the database and have an analytical capability, usually predictive or recommendations, sometimes attribution.
3. Campaign CDPs: These do the data plus the analytics plus message selection (which we abbreviate as "campaign" because "message selection" is too long). This is about picking the message for an individual. Any CDP can create a segment, but to say, "Josh should get this message, and David should get that message, even though they're in the same segment," that's message selection. This might be for an outbound campaign (like email) or for real-time interaction (like web personalization).
4. Delivery CDPs: These do all the stuff I just talked about, but also deliver the message. So they have an email system built in or a web personalization engine that actually sends out the web pages.
5. Operational CDPs: These are CDPs embedded in a larger system, like an e-commerce system or even an ERP system, part of the actual operating system or reservation system of the company.

They all have that CDP at the core. If they don't build that unified persistent database, they're not a CDP. Now when you get to something like a delivery or an operational CDP, obviously there's a lot more going on there than just building profiles. So at that point, we talk about having the CDP inside of a larger system.

Josh Francia: So if we simplify it a little bit to just marketing-focused activation and data-focused management as maybe the two higher-level categories they all kind of fall into, how do you then align? Can CDPs work together? Can you have companies that have a data management CDP and a marketing activation CDP? And also, what types of customers do they attract? Are they going after the same group, and they have to make the decision? Or are they going after two different groups, two different use cases, and they can work kind of in harmony?

David Raab: It's actually surprisingly common for a company to have two different CDPs. And it usually is one that's really good at the data management, particularly the data collection bits. Some CDP vendors who started out as tag managers for analytical tools, where they were really designed specifically to assemble data, tend to be strong at that. And then you might hook that up to an activation CDP or a campaign CDP that has really strong functions for that message selection capability. By definition, we wouldn't call it a CDP if it couldn't assemble the data, but some are better at it than others. And sometimes it just makes sense to take one that's really good at one thing and one that's good at something else and put them together.

Now, the activation CDPs, that's more of a departmental tool, right? That's something for marketers. So those vendors are building a lot of marketing capabilities. Whereas the data CDPs, that's more of an enterprise-level capability. So the data CDPs tend to be bought more by big companies that are looking for a solution that just does that because they already have activation systems in place and they don't want to switch out their email engine or their web personalization tool. Whereas the activation CDPs tend to be purchased by somewhat smaller companies, where they're really more concerned about saving the integration costs, even though theoretically easy to integrate. Reality does always involve work. And they're not opposed to throwing away the existing tools. So that tends to be a mid-tier purchase.

Josh Francia: And what we've seen sometimes too, is they're replaced from a single channel to more of an omnichannel tool. So they say, "Hey, we have a decent email tool, but it's just email. And we want to do mobile and email and web personalization all together. Do we really want to buy three? No, let's just buy one." And it would also be great if we had data together. So we see that sometimes as well, as an impetus to actually changing course.

CDP vs. Other MarTech Tools: CRM, MA, DMP

Josh Francia: Let's go to a question. We have a couple of questions in here, and thank you for those that have put questions in, and please continue to if you have any others. So this one comes in around, what is the main difference between a CDP and a CRM? And where do you feel like there's an overlap between those two things? David, we're going to play a little bit of alphabet soup here, but this might be the first one of CDP versus CRM. What's the overlap and what's the difference?

David Raab: Okay. So they are really different. And I understand why people get them confused, or at least why they ask the question, because they both store customer data, right? So, hey, they all have a 'C' in fact, 'C' stands for the same thing even.

But CRMs are designed primarily for sales and service. They're designed to give an individual agent (talking to you or in a call center) access to one person's records. You want all the information about that one individual. Technically, this is designed using a highly normalized relational database. The CDP, by contrast, is designed not to pull out that individual customer record, but to pull in all the data and do bulk analysis. It will also pull out individual records, but that's not its only purpose. And it's not designed to update them in real-time necessarily. So, there are different use cases, and therefore different technical designs to optimize for either of those two use cases. They're different enough that it's really hard to make the same system do both. So, at the core, they're just architecturally different, and that drives everything else.

Where they overlap: Yes, they have customer data. Can you pull a mailing list out of a CRM? Yes, but it's usually kind of ugly. Can you do individual interactions out of a CDP? Yes, to some extent, but it's not really the core design spec for that one either. So, there's a little bit of overlap, but they're really optimized for different things.

Josh Francia: I would just add speed is a big difference in my mind. When you try to query a CRM to get bulk lists and deep segmentation, it's not very responsive. It takes a long time. It's not pre-computed; it's not optimized for that use case. But with a CDP, it is. One of the greatest functions of a CDP is high-volume segmentation and granularity. I remember when I was first evaluating CDPs, I was shocked at the speed at which they could segment massive amounts of data, tens of millions of rows. In a CRM, you don't usually even have that many rows because it's very focused on sales and individual contact records. So, that's also a huge difference in my mind: the way they operate, operationalize to speed, and the ability to act quickly and respond to different things.

David Raab: And just to add, the other two big things from the CDP standpoint are:

• The CDP is designed to take in all data sources, whereas CRM mostly works with data generated within the CRM itself.
• CRMs are designed to use their own data; they're not really designed to share data out. If you've ever tried a big export from one of the large cloud CRMs, it tends to be really ugly. Technically possible, but very slow. So, they're good at what they're for, but they're not the same things.

Josh Francia: Okay. So we have another question that's on a similar topic. What's the difference between a CDP and a marketing automation tool? And if you combine these together, is that what you're calling an activation CDP?

David Raab: That's actually a really good question. It's an interesting one. We're seeing more and more people say that they think the CDP is sort of the marketing automation system of the future. To some extent, it's a similar issue about optimizing for different use cases, but marketing automation is much closer to a CDP in terms of its design to do bulk segmentation and large lists quickly. Most marketing automation tools are basically used for email.

If you think about a delivery CDP (which has an email system built in) or a campaign CDP (which has that functionality built in), then yes, that could pretty much by definition replace a marketing automation system. Not all CDPs fall into those categories. So yes, if you want a system that builds a database and does campaigning and even does message delivery, you can find a CDP that has that scope of functionality, which is what we have been calling here an activation CDP. So yeah, that could indeed replace marketing automation.

Marketing automation is more of a B2B term, at least originally, now often used for B2C as well. And CDP was more used historically for B2B, but now more often there are quite a few B2B implementations. So that distinction becomes less important than it was, say, two years ago.

Josh Francia: All right, we're going to round out alphabet soup here with the last alphabet soup question, which is CDP versus DMP. What are the similarities and differences between those two technologies?

David Raab: Interestingly, DMP in Europe was really sold as "all of your first-party data will be stored in this system," so the sales pitch was quite similar to the CDP sales pitch. In the U.S., not so much. In the U.S., it was always pretty clear that DMPs were really about cookies and audiences for display advertising, a pretty narrow use case.

The way you optimize for a cookie is by designing a certain fashion, basically a big flat file, where you have just one row with all the attributes of every profile (usually a cookie). This means every attribute is a bucket or a column in that data structure. So, you can have thousands of columns (e.g., "male: yes," "lives in New York: yes," "made a purchase in last 30 days: yes"), but you cannot store all the detail. You can't store transaction records. So, if I want to find people who bought red shoes on a Tuesday morning in a size eight, you're not going to have a column for that. You inevitably lose detail when you use the structure of DMPs. That's fine for DMPs because they're just about pulling out broad segments (e.g., "all people who bought in the last 30 days who live in New York"). They're good at what they do, designed to pull out those columns, but not to store all the granular detail you might use for, say, a predictive model.

Josh Francia: The way I always looked at DMPs is that, one, by definition, especially in the U.S., they didn't allow you to have PII data in them. So you can't have a customer's first name, last name, email address, phone number in a DMP; it violates their ability to do it. It was much more about allowing acquisition marketers to say, "Find me people that are in-segment, in-market for my product in broad senses." If they just blast display or programmatic ads to the general market, they won't be very efficient. But with a DMP, they can identify people in-market for a specific category, influencing their acquisition strategy and making their ad spend go further. But they're not figuring out the individuals.

Whereas CDPs tend to focus on once you've identified the customer – once they've actually become a customer – how you continue to engage with them, reactivate them, and make them a more loyal customer over time. So, I almost look at them as able to work together in many ways.

Currently, DMPs struggle because many cookies are being deprecated, which was their main source of data for identifying who's in-market. Many different technologies are trying to solve these issues. CDPs don't struggle as much with this because they deal with known, first-party data, not third-party cookies. That's kind of how I think about it.

Data Readiness and CDP Implementation

Josh Francia: All right, we got a few more questions. This is great. So one question here is around data readiness. David, what would you say to someone, a prospect, a company that's saying, "Hey, I want to get a CDP, but what kind of cleanup do I need to do with my current data in my own systems before I'm ready to implement a CDP? What are the steps? How do I know I'm ready to actually use a CDP?" What would you say to someone like that?

David Raab: Well, the consultant in me now rises up and says, "It depends." It certainly will depend on the state of your current data. So that's the first thing: look at what you've got and see what shape it's in. Recognize that it's all about fitness for purpose. Quality is a relative term: "Quality in relation to what?"

Often, data in your CRM (a primary source for your CDP) might be entered by salespeople and not be entirely complete or accurate because they don't need it to be. There might be many duplicates in a CRM because a salesperson doesn't care if an old record exists; they'll just create a new one, knowing which one to use. But the CDP doesn't have that local knowledge; it's not a human looking at it. So it will pull in all those duplicates, and then it has to figure out what are true dupes and what are old, dead records it can discard.

So, the source data may be perfectly usable for its original purpose and still not be suitable for the CDP purpose. You have to know what that CDP purpose is. Is it to create a mailing list? Even for an email list, everyone has multiple emails these days. So how do I deduplicate not just on the email (anyone can merge duplicate email addresses), but that's not enough. Many old marketing automation systems just deduplicated against email addresses, which doesn't work anymore.

So, what are you going to use that data for? How good is the data for that purpose? Start with a couple of basic things. There are a lot of data sources out there. We'll see counts in a big company of 150 sources, not uncommon in a CDP. Even a smaller company will have a dozen or so. But you might only need two or three to get started for your core use cases. And then the data elements within those sources, because you're not going to use all the fields in the database, you're just going to use a few. So, start simple and look at those things. Once you have a process in place, once you have the data flowing through the systems, then you can begin to expand your scope a little and look at a few more fields and check the quality of those. But again, always, always, always in relation to a particular application.

Josh Francia: And I think we've seen that a lot where our advice to many people is "start with the end in mind." So what are some of the things you want to accomplish? We talk to most marketers because we're more of an activation-focused CDP. So we say, "What kind of things do you want to be able to do in your campaigns that you can't do today?" They say, "Well, we want to be able to do this, this, and this." Okay, great. Which ones are most valuable? Stack rank them. Then we say, "Okay, what data are you missing today to be able to do one through five?" And they say, "Oh, we don't have this record." "Okay, where does that record live?" You work backward from that, because then you have applicability for the data, which makes getting the data in far easier because now you know how to use it. This is versus the approach of just "put everything in, we'll figure it out later," which feels like a very big hill to climb with no applicability at the end.

So we kind of go in that same direction: find a few use cases that you can get some value out of. And then the nice thing about CDPs is they're flexible; they're flexible on purpose. So you can add data in and not disrupt the data you had before. You don't have to reset everything every time. I think that's a main big difference from a lot of other more standard relational type tables where changing one thing could influence a ton of things in the system. In CDPs, it's not so much like that. It's built to be flexible. It's built to be scalable and adjust to your business as your business changes.

Global CDP Activation and Privacy Concerns

Josh Francia: All right, so we have a few more. We're getting some great questions. Thank you everyone for putting these questions in. So one question is regarding activation of CDPs and how much does it vary in different regions? So we have the Americas, we have EMEA, we have Asia versus having maybe one system of rules and processes and regulations that should be globally adopted. In each part of the world, there are different regulations, different compliance. Are you seeing that activation CDPs vary a lot by regions? Are there ones that are only focused on EMEA, only focused on Asia, only focused on Americas, or are there some global options that kind of say, "Hey, we can focus and work across the globe for any types of more geographical related compliance issues?"

David Raab: Well, there certainly are CDPs that are sold globally. And the more interesting question is, are they actually using a single instance or are they using multiple instances of the database? Technically, at least the bigger ones, the more advanced ones, could use a single database and partition things so the data from different regions is handled differently. You can do that through rules as well as physical partitioning. Nowadays, of course, in many regions, the data can't leave the region. So even though the CDP may technically be capable of putting it all in one place, legally the data has to remain separate anyway.

The challenge is that even within a given region, you may have different rules in different countries or different data types. And then, of course, consent now often factors into it. So people who have given different kinds of consent need to be treated differently. A lot of that comes down to the rules that are embedded in the CDP. And again, this is where privacy is really driving so much of the CDP industry. We joke about GDPR being the "CDP Full Employment Act," because it was such a big impetus in Europe. CDP vendors made a huge difference in adoption of that. So yeah, there are, and then there are plenty of local CDPs that are smaller companies sold within a given region. And obviously, they're going to be optimized. But privacy regulations, they kind of tend to follow the same general structure, region to region, maybe differences in the details of what's allowed. But the general notions of things like consent, and limitations of purpose, and keeping track of your records, those are part of most required, most different regs, even though the differences of what consent is, and how you can get it and store it and improve it and all that may be different. So you kind of need a similar structure. The same core technology can handle most regions.

Josh Francia: We have another question around CDPs: Is it common for CDPs to offer service agreements that cover the liability of security for the customer data? So that's a very interesting question. I don't think I've heard that before. I'd love your thoughts, David, of, you know, is it common for CDPs to offer these types of service agreements to say, "Hey, we're going to cover your liability if there's a breach of customer data or something like that?" Have you seen that in the market at all?

David Raab: I have no idea. I don't see those agreements. No one has ever mentioned that to me as an issue one way or the other. So maybe it's in every agreement, maybe it's no agreement. It's not really been a topic. So it's a great question. But I just honestly don't know. I'll have to ask.

Josh Francia: Okay. All right. So then another question we had is, and we talked about this a little bit, but how will CDPs be impacted once cookies go away? Let me just frame this question a little bit where the cookie Armageddon and all these things started out really as being able to track people. Legislation kind of started it and said, "Hey, you have the right to essentially say, 'Don't track me anymore. Don't use my data to market to me without my consent.'" That's kind of what GDPR and CCPA are, in very high-level terms. But then technology companies went a little further. Apple and Google have kind of said different things that we're not going to track you anymore with third-party cookies if you use certain systems, and we're going to deprecate them completely.

I think that was the premise of a lot of people saying, "Oh my gosh, if Chrome says no more third-party cookies, what is going to happen to a lot of my marketing?" Now they're talking about third-party cookies, not first-party cookies. First-party cookies are things that you, the website (e.g., blueshift.com or apple.com), drop directly into your web browser. It's directly from them, and they can read it and do what they want. Third-party cookies are when, for instance, a website shows an ad, and that ad itself drops a cookie. All of a sudden, you didn't tell ad company one, two, three that they could drop a cookie on your web browser and then track you wherever you go and read where you're going. That's the third-party cookie piece that's at risk. So when we talk about how will CDPs be impacted when cookies go away, cookies going away is really third-party cookies going away, not first-party cookies. So David, what's your call on that? Are you going to see a big disruption with CDPs as cookies eventually go away? We know Google pushed it out a little bit again, but once that date actually comes and we see a big separation in third-party cookies, do you feel like there's a big impact on CDPs?

David Raab: Not a big impact. This is where DMPs, which are built around those third-party cookies, are being impacted. Some DMP vendors are morphing into CDPs, so they have a way to continue to stay in business. Mostly, again, CDPs, as you said earlier, are about first-party data. So they're not really generally dealing with third-party cookies. Not that they couldn't, and technically they could, and sometimes they will, but it's not been the primary use case.

It almost goes the other way: people say, "Well, if I'm not going to be able to use third-party cookies or get my hands on third-party data from other sources" (which gets back to privacy, raising consent, and goes beyond just cookies), "then my first-party data becomes more important because I can't get it elsewhere." It's not a one-for-one exchange because third-party data is more about finding new customers, and first-party data is more about doing a better job with your existing customers. So there's some overlap where it's like, "Well, I can take my existing customers and do lookalike modeling to go out and prospect for more," but by and large, they're different things. So there's a shift in emphasis, but it's not a one-for-one substitution. In any event, it's a good thing for CDP because it makes you pay more attention to how they're dealing with their first-party data, and that drives you right back to CDP land.

Josh Francia: All right. So here's another question around CDPs and the variable they use to unify customer data. So if they, you know, so what you've seen out there is how do they take all these data inputs, right? So you have different data inputs from a variety of different sources, and how do they unify that customer if it's not maybe an email? Email is a fairly common identifier, but maybe they don't have email from all these data sources. What do they do? What are you seeing CDPs do to actually stitch this together and create that unified view of the profile when they may not have a common identifier across everything?

David Raab: Well, the first thing to say is, there's no magic here. Sometimes you can't unify the profile, and you shouldn't expect that the CDP is going to solve this problem and have a miracle happen that can't happen in any other technology. It's not miraculous about the CDP.

So what CDPs can do in almost all cases is at least what's called deterministic matching. If I go to a first-party website, drop a first-party cookie, and then fill out a form providing my email, now I know that email address belongs to that first-party cookie, so it belongs to that device. And maybe it belongs to that customer if they bought something, I have a customer ID that's attached to that. So I can stitch together those things in a deterministic fashion where the data coming from the customer directly says, "Hey, this is me," and "These two identifiers both belong to me." Most CDPs can do that; it's pretty common.

The other kind of matching is probabilistic matching that looks at and says, "Well, this phone and this computer, they sort of seem to travel together. They're used in this location at home during the evening, and they're used in this office during the day." So it kind of looks like they're the same person, they visit the same websites. So even though we don't have a deterministic, a direct connection (because one doesn't have the email or whatever), we say, "Yeah, probably the same thing." That's another kind of matching that is much more difficult, obviously, much more prone to error. So there are all kinds of complicated rules involved. Some CDPs do this, many don't. Some argue that's dubious legality under some privacy regulations anyway, so you don't want to do it. Some say it's just fine. The law is not yet really determined, I don't think, on that. So some of them will do that. And that sounds more like magic. But, you know, at the end of the day, it's not going to be magic either. It's just going to be that kind of stuff. And, you know, don't expect miracles.

Josh Francia: Yeah, that's right. But they do make it easy, right? So I think a lot of CDPs take that stitching and make it easy where there are natural ways of identifying the customer, which I think is a big value, because a lot of companies do struggle with that, especially if they have mobile customers and email customers and website customers, and they have to manage that independently. A CDP will help you bring all those things together where it's a natural deterministic fit. And the nice thing about deterministic is it is accurate. It's like, "Yes, that person is that person." It's not this guess of "we think it's that person" because of some model that the probabilistic uses.

So it's helpful when you're trying to say, "How many customers is this cookie actually this person?" "Well, yes, it is because they logged in on this web address five days after they visited our website, and we know it's the exact same person's actual cookie, exact same web browser they use. And so, by the way, it's the same person." I think those are really valuable because you're starting to reduce the noise of some of your anonymous cookies and anonymous behavior. One of the greatest things we see is you can track anonymous behavior for a long time. And then when it becomes known, all of a sudden that anonymous behavior is attached to that profile. So it's not like when they become known, that's the first time you actually know what they've been doing. You can know what they were doing weeks or months beforehand. And as long as you can stitch it together, CDPs do that magically. We say magically, I'll put in air quotes, and they don't like the term magically, but they do it automatically. Maybe that's a better way of saying it. And you don't have to think about it as a marketer. And you say, "Hey, this is amazing. This person is now not anonymous. He's known or she's known. And now I do a lot more with them, right? Now all their transactions are coming through and stuff like that."

Forecasting CDP Trends in 2022

Josh Francia: Okay. So let's shift a little bit. We only have about 12 minutes left. Based on what we've seen in CDPs, I'm going to ask you to put your psychic hat on a little bit. And I want you to forecast trends that you see happening in this year, in 2022. What kind of trends are you starting to see that will play out in the CDP landscape?

David Raab: I think we're going to see continued differentiation. And that division between data and activation CDPs that you mentioned earlier, which again, is not really the official Institute position, I think may have to become the official Institute position. Five categories, maybe too much. I got to get down to three. But that is becoming a more broadly understood difference. For a while, people have been very confused about all the different things that are CDPs. And you still hear a lot of complaints about that. But I think people are kind of beginning to guess, you know, there really are these two sort of clusters of capabilities that are both CDPs. I still argue that they're both CDPs. But they are pretty different. And you kind of probably want one or the other. So I think that that clarity will help.

I think, what we've seen just recently is we've seen some of the big independent CDP vendors raise a lot of money, like a couple hundred million dollars. And those guys are going to spend that on something. I'm expecting to see some more acquisitions by those vendors, which is not historically something that we've seen. And there actually just was one last week by MParticle. But I suspect we're going to see a lot more of that as those guys try to flesh out their system, particularly if they're on the activation side and they want to become more of a full suite tool. Because that's the other thing that we've seen over the last few years is companies that already have activation tools (email and things like that) buying a CDP that kind of merges all the channels together. Because often they bought separate systems for SMS over here and email over there, personalization over there. And they need something to glue it together, which of course is a CDP. So we've seen a round of acquisitions. So I think those are going to already mature because those acquisitions have already happened in many cases. But now once you do the acquisition, then you have to go and re-engineer and really integrate the products. So that stuff's going to start hitting the market pretty soon. There are going to be some pretty big changes. And of course, Salesforce and Adobe and those guys who relate to the market, but now have a year or two of product in market under their belt. Those products are going to continue to mature. They did rush them to market. So those are going to begin to really have some traction. Actually, they already have traction, but they're going to have more traction. So that's going to be another sort of consideration. And then finally, as I say, the build versus buy. There are now more tools that you can purchase to assemble a CDP with if you're so inclined, if you're an IT department that wants to do that. So that also is going to have more and more of an impact on the market.

Josh Francia: All right. Well, those are a lot of good forecasts and projections. There was another question that came in as you were talking. I'd love your opinion on this. The question was, could a customer journey orchestration platform be a CDP? And the question is, if it has a unified identification, user identification, and omnichannel activation capability, could that be considered a CDP? What's your take on that?

David Raab: Yeah, well, for us, that's when it falls into the campaign CDP or possibly the delivery CDP category. Again, what makes it a CDP is it's got that data unification, that unified persistent customer database. If it has other stuff like orchestration, hey, that's fabulous. It's a CDP that's got that stuff too. Or maybe it's an orchestration tool that happens to have a CDP inside, as I said earlier. But there's nothing that prevents one of those tools from having a CDP inside. And there's nothing that requires one of those tools from having a CDP inside, because you can easily hook those tools up to a CDP, which has actually been pretty common.

Advice for CDP Evaluation and ROI

Josh Francia: So for people that are thinking about getting a CDP this year (mid-January, budgets renewed), and they're thinking about the marketing side of CDPs, what would be some of your advice on things that they look out for, things that they understand, things that they go in in their evaluations as they approach the market, so they can make a really good decision for their company? What advice would you give them as they start evaluating?

David Raab: Well, it's always the same advice. And you said earlier, "start with the end in mind." So figure out what you're trying to do. If I'm marketing-oriented, what marketing programs do I want to run? What's preventing me from running those programs? Now, where are the gaps in my systems? And is the CDP the best way to fill those gaps? Because sometimes those gaps are delivery tools. I don't have a recommendation engine. Well, a CDP might do that if you buy a CDP that has a recommendation engine. But if you for some reason already have great unified data, but you simply lack the analytical tool, then buy an analytical tool. So where are the gaps? And is the CDP the tool to fill those gaps? That's the high-level way to do that.

How do you know if you're looking for a shortcut, which everyone does? If you need to share data across systems. If you have two systems that need to communicate somehow, those are the core CDP use cases. Every CDP use case involves sharing data across systems. So if you have a bunch of issues, gaps that involve, "Gee, I can't do this because there's data in the email engine over here and in the e-commerce engine over there, and they don't talk to each other," that's a CDP use case. And that's a pretty good indication that you need a CDP. And of course, which CDP you need, again, just get into more details of what specific things you have as gaps that you need to fill.

Worry about scalability. Worry about a fit between the sophistication of the tool and the sophistication of your users and your resources. If you don't have a lot of resources to help with the implementation, if you're going to need technical help, look at professional services that are available. So look at usability. Some of these things are more designed for technical users. Some are more designed for business users to do more on their own. So, look at things like that. But above all, understand your organizational issues. Understand how your company is going to use it, who's going to use it, what they really need to do. Because that is much more important than technology. It's getting the user straight, getting the organization straight. That's what's really going to drive your success much more than this tool or that tool.

Josh Francia: Yeah, no, that's great. Great advice. For myself, as I evaluated several before ultimately choosing and joining Blueshift, I agree with that. When I was evaluating, I had just a high-level list of five things I wanted to accomplish. And I used that rubric as I went through and asked each company. I said, "Okay, tell me how you do these five things." If their sniff test in the very beginning passed, I said, "Okay, you at least have enough to answer the question," and then let's have a further dialogue. If they say, "Listen, we only really do two of those five," then it was a very easy decision to say, "Okay, that's not the right fit for us."

So you have to whittle it down because there are a lot of vendors out there, right? If you don't have what you need as your core competencies that you need to accomplish, you're going to be a little bit lost looking at all these different vendors and being confused about what does what. You have to know what you need for your company to be successful and list that out. Maybe it's two things, maybe it's three things, maybe it's six things. And then evaluate your companies based on that. You'll quickly realize that there are only probably a handful that can probably do the things that you ultimately want to do. Then you go deep with those, that handful. Go deep with them, really uncover the way they do it. Is it the way you need them to do it? Is the usability the way you want it to be done? Is the scalability the way that needs to happen? And then you kind of arrive at a very good process, and you don't waste a lot of time evaluating 20 or 30 CDPs at that level. That's just too much for anyone to do. So that would be my kind of advice as well.

All right, David, we're quickly approaching the end here. It's crazy how quickly an hour can go with you. Again, I appreciate all of your wisdom and your advice and counsel. We've had a lot of great comments from people here. So thank you again. We are recording this. So we will share this out with everyone.

Let's take one final question. I'll combine a couple of questions that came in. One of them was about how do you show an ROI for a CDP? The other one was really about convergence of ad tech, martech. A lot of CDPs talk about values around engagement outcomes, loyalty outcomes. What do you think about paid media outcomes? So again, the underlying theme for both of those questions: where's the value for this coming from? Where's the ROI coming from? What are the biggest ROI-driving kind of use cases?

David Raab: Well, since they mentioned RFPs, I should at least mention that the CDP Institute at CDPinstitute.org has an RFP generator that might help people when they're actually designing their RFP, and a use case generator for that matter.

But in terms of estimating the value, remember that chart that had the different applications (data, analytics, predictive, and so on). That's what you are looking at. And again, the value comes when you actually are doing something that's interacting with the customer. So when you want to look at that, the shorthand formula for that, and this is something we do workshops on, is:

• How many customers are affected?
• What's the change in value per customer?
• What's the cost involved in making this happen?

So it's a pretty straightforward ROI calculation, assuming, of course, you know those numbers.

Josh Francia: That's right. And I think the capability of being able to personalize to a point where conversions dramatically improve, lifetime value and engagement downstream improves. And at the same time, on the cost side, workflow efficiencies get built in. You don't actually have to rely on IT teams to build your basic segments. Business users are much more empowered to run faster. Experimentation kind of goes up, leading to obviously more measurable outcomes from the experiments. Those are typical ways of measuring the ROI. And I think the ROI has been pretty significant.

While this is more about Blueshift than CDPs generally, we had a study done by Forrester, which attributed about a 781% ROI and an average revenue lift of $128 million per customer attributed to Blueshift. This was a very systematic, time-adjusted, risk-adjusted study. The attribution of the ROI specifically, I would say, was for three or four levels:

1. The uplift from real-time interactions and AI-powered targeting. So really CDP enabling the real-time and the AI and that leading to more conversion, more revenue was key.
2. Cross-channel coordination, because messages that are coordinated across channels are orchestrated. So that's kind of the way that you're using that kind of use case to drive that incremental LTV. And that's very measurable.
3. Workflow efficiencies of less dependence on IT.

So those are key thematic ideas, and you can build a great ROI case around that.

David Raab: If you go back to the previous slide here, you're going to see those categories. What's interesting is that those things on the right—less IT reliance, fast reaction—are sort of the practical cost savings, just operational things. But they can be real. And I don't recall your study in particular, but some of those studies show that those cost savings by themselves can almost pay for the CDP, even if your business didn't improve. Even though the bulk of the business benefit certainly comes from higher revenue.

Josh Francia: That's right. The bulk of the business benefit comes from the higher revenue, but you're right that the cost savings probably at least break even on the CDP investment. But really, for the listeners here, I'd encourage them to focus on the business benefits, which are primarily around these orchestration, message selection, and predictive use cases.

Conclusion and Farewell

Josh Francia: With that, I know we took a few questions and had a great discussion. I want to kind of, you know, bring in Joan back to talk about some of the closing notes. I think there's been a fantastic discussion, and I've definitely benefited a lot from your perspective. Joan, over to you.

Joan Jenkins: Yeah. Yeah. Yeah, definitely. So thank you everyone for joining. This has been such an insightful discussion. And if you have any other questions that haven't been answered, definitely, you know, ask these two. I know they're open and definitely willing to provide that, you know, provide, answer any questions. And with that, this webinar will be available on demand. So we'll send out a link to everyone who joined. Feel free to share with colleagues, friends, anyone across the board. I think it's been really helpful information around CDP. And with that, any final remarks, Vijay?

Vijay Chittoor: Firstly, thank you, David. I think this was very insightful to kind of hear from you because you've seen the evolution of CDPs literally from day one. And really, I think my biggest takeaways from today's discussion were to encourage customers of CDPs to start from the use case and benefits first, because everyone eventually is focused on ROI. People are focused on stack simplification. So really focus on CDPs that can deliver the full range of value. Think about the modern data stack and the data warehouse, but at the same time, understand that CDPs need to prepare the data in a form that can be executed for orchestration and message personalization. And finally, AI, treat CDPs as a big enabler of AI. That's the next big revolution in enterprise tech in general and in customer experience. And CDPs are a very, very critical part of that enabling that revolution. So those are my takeaways. Excited to have had this discussion. David, great to have this audience here and looking forward to the follow-up dialogue with all of you. Feel free to reach out to me or David on our email or LinkedIn. Thank you.

David Raab: Thanks, everyone. Thanks, Josh.