Webinar: Best practices—Implementing a CDP

Hello everyone and welcome to our Best Practices for Implementing a Customer Data Platform Webinar. We thank you so much for joining us today. With me are David Spitz, our CMO, and Paul Mander the VP of Professional Services. Just a couple of housekeeping things, if you can't hear me or if you have any issues, please send us a quick note. Please keep your questions for the very end. We'll have a question and answer session. So with that, David, if you want to start off.

Hello everyone. Welcome to the webinar. A bunch of us recently returned from the Gartner digital marketing opera in San Diego where there are lots and lots of talk about what CDPs are and where they fit into the marketing, uh, ecosystem. And this is an example of one of the types of charts that was well covered. They're talking about customer data platforms are essentially the, uh, marketing middleware that collects, unifies, and delivers data throughout the marketing and advertising technology stack for many of the world's largest brands. We also have our own whitepaper on the topic which you can download. It walks you through why CDPs are such a big deal right now and why you might need one and what to look for in a CDP. That's not what we're going to cover today. Today we're going to focus on the why and the how of customer data platforms.

These things are obviously related. If you don't have it clear, you're destined to have a crisis of value or crisis of implementation when it comes to the how. So we'll define these things, in turn, talking about three CDP must-haves. Number one, you must have a value to the customer. Number two, value to the business. And number three, you must deliver upon these expectations and be excellent at that. So, I'll start by covering the first two topics, and my colleagues will join us for the third. And we'll start with the value to the customer.

Most CDPs, as I mentioned, starts with a technology problem and, and that's, that's really a mistake on a number of levels, but the technology problem looks something like this. People look at their current technology architecture and they say, well, we have all these different external vendors, whether it's Adobe Analytics or Facebook or Google or some other analytics providers, such as Amplitude, marketing automation system such as a campaign manager or marsys, and we have all these internal systems and maybe they're integrated through some fragile point to point methods, but there's a lot of a data leakage, a lot of engineering effort that goes into that problem. This is probably a good place to start. But, not a good place to finish it in our view. CDPs certainly do solve a technology problem, but they're much more than that.

And, and we think the focus should be squarely on the customer before the technology. Number two would be that a lot of people will start to think about CDPs as a data solution to a data problem and the data problem could look something like this, um, you know, I have my media attribution data about which, uh, which channels helped me acquire a customer, but I'm not able to link that to customer analytics that tells me the lifetime value of the customer, for example. Or you might say, you know, Oh, I have all my email channels, and those work great for orchestrating messages across email, but I'm not able to coordinate that with my push notification channels which deliver very similar messages over and over mobile devices. And again, a good place to start, but a bad place to finish.

We think where you need to start when you think about the customer data platform is with the customer. You can't spell a customer data platform without it. And that means starting to think through the customer's journey, not just the journey. As you imagine it, through some internal whiteboarding exercise with your marketing team, the actual lived experience of the customer, is highly mobile and multi-device, whether you like it or not. Forrester does this study every year of the CX index, the customer satisfaction index and they found that 2017 was the first year where customer expectations while they keep going up, marketers ability to deliver on that, those expectations were flat or even down a for a majority of France. And mobile is the main contributor to that, to that dilemma. Reason being that people expect once they, whenever they pick up a mobile device to be completely connected to everything that they need in the immediate context at the moment they pick up that device.

This was a study from several years ago now that said the majority of consumers and the United States have made this mobile mind shift. So they're every day on Facebook, and they're doing their eCommerce on places like Amazon, and whether you compete directly or not; with those companies, you do compete in the mindset of the consumer with the expectation that those companies have set. So, you can think of CDPs as a solution, not just to integrate data and technology, but actually to integrate the customer experience to a level that people expect brands to be able to deliver no matter what the category. So with that, with that mindset of the customer experience experiences specifically the mobile mindset shift, it sets out pretty clearly what a CDP has to be able to do. It means that you have to be able to identify people across devices and at every stage of the journey, you have to be able to understand them in a profound way as a whole person.

Across their behaviors, which might sit in an analytics system, their relationship histories, which might sit historically in some sort of CRM system, their marketing exposures, which might lie within a campaign automation system, and their situational context, where are they at that very moment in time and space based on their geolocation data, for example, be able to marry all that together in the moment and be able to deliver that on across any channel. And that's not because of technology, that's because of customers and what they are, and what they expect your brand to be able to deliver. If you're able to do that, you can create not just digital experiences like these, but also really breakthrough omnichannel ones like these, which matter more and more across every consumer category. So that's what we mean really when we talk about delivering and defining your value to the customer first and foremost.

Now you could deliver your value to the customer, but you're not going to succeed if you're not also delivering value to the business. So that's what we mean when we're talking about the power alley here. You have to have the right balance of value to the business and value to the customer to be successful. And in a moment, I'll give you three examples of brands we've worked with who have developed just exactly that type of formula. Each one is slightly different, and that's the reason why it's important to define exactly and clearly how you're creating value for the customer and the business upfront. Customer Data Platforms, unlike pretty much any other marketing technology in history, touch so many different stakeholders across the organization, not just the mobile and the web product development or marketing teams, but also the customer service and support teams.

People who are very deep into the IT and engineering parts of the organization. Data scientists and analytics revenue and business operations much more than a historically where Martech and Adtech have been focused on point solutions primarily, uh, have used within a single function or a discipline within the marketing department. Customer data platforms, by their very definition, are touched and need to align across a great many different disciplines. So to create that sort of clarity and alignment, it's essential to be specific upfront about what kind of value you intend to deliver for the business and for these different functional groups. So we're going to give you three examples. The first one is a company we work within the eCommerce space. In November of last year, the CEO from Overstock was on the company's earnings call talking about how a competitor of theirs was spending an astronomical sum on customer acquisition, bidding up keywords, for example, that used to cost $0.15-$0.16 cents to over $2 and losing money essentially on every customer. This practice completely changed the landscape and creating this war of attrition that Overstock didn't want to play anymore.

It was a losing battle. So here's a quote from their SVP of marketing talking about how when they needed to flip the model. If they could switch to ensure that the site experience was personalized across the buyer's style, the colors she likes, items within our budget, that will make, that will ensure the greatest chance of success once you're able to acquire a customer that you're able to convert and retain that customer. But that's really only just the beginning of their customer data vision. They also use the customer data platform, this case mParticle to integrate data, not just for use on the website but also across their paid media channels, as well as through their owned media email, especially email and push notification channels. So by creating a 360-degree view of the customer, they were able to flip the model from this uneconomical customer acquisition, cost-driven model to a more holistic optimization of the return on marketing spend metric.

So marketing span is the objective, the activations through these different digital channels. But, I'd say overall, this was a success story in driving increased marketing ROI, a different but related take on this is Postmates, the on-demand delivery service that in a way competes with a UPS in the imagination of the customer because they position themselves as a logistics company. But, they want to be this logistics company with the best customer experience, almost like UPS meets the Walt Disney Company. So customer experience is so important to them is because that's what makes them different from the thousand other ways you can get food or packages delivered to your doorstep. They want to have the best and most magical customer experience. So for them, a Customer Data Platform was really about driving that experience and creating long-term loyalty and satisfaction.

So it wasn't enough to integrate marketing data as in the Overstock example that we just gave you. They also brought in data from their customer helpdesk, which in this case is ZenDesk, from the product experience itself, from various systems that attract analytics, and from interactions with different features within the app. Then, we're able to marry these things together to create better intuition and then ultimately run experiments about, well, what lever should we pull? What if we increase marketing spend? What does that do to long-term customer value? Does that create more calls into our helpdesk, for example, what's the value of an incremental investment into customer service on lifetime value? Is that better? Is that a better lever to pull than running more marketing campaigns? And through that lens, they're able to optimize for the metrics that they care about around customer satisfaction and long-term value.

Finally, a third example will give you his SeatGeek, the ticketing app. Their mission is to drive more efficiency into the secondary ticketing market. And their customer data platform is similarly oriented around efficiency metrics. They want it to make sure that they were being nimble and used the best tools that were available to them without spending a lot of time and resources on, uh, engineering every integration. So initially they used in mParticle to test and deploy a number of different services into the mobile app without having to implement a custom SDK for each one. Over time, they started to find other areas of efficiency, which I think we'll talk about a little bit later in the presentation, but essentially we have three examples here. One around marketing ROI, one around customer lifetime value and customer experience, and this third one around operational efficiency. All of them bring benefits to the company as well as to the customer. And that's the point we're trying to make here: you have to find your power alley and align your activities and objectives to your specific needs. So everyone's very clear about what the Customer Data Platform is trying to achieve. So with that setup, I will turn it over to Paul who will talk us through some of the operational aspects and best practices of implementing a CDP.

Great, thanks, David. So in terms of operational access, I think it all begins first with building your architecture and deciding what elements you need in your architecture. Specifically, we're talking about how a CDP fits into this and to go through a customer-centric architecture. So if you look towards the top where we discuss data sources, what this is saying is that you really need to be sure you're collecting data from all of the channels with which a customer engages your brand. This would mean you're collecting the browsing behavioral data from your website, whether they're doing some product research, or if you're eCommerce type of business, collecting the actual transactions. The same for goes for mobile apps. When we say voice here, this could be collecting interactions that they might be having with a chatbot through some application or even down to a summary of an interaction with the call center.

Conversely, if you're in a channel where you're interacting with your customers over connected devices, for example, again, connecting, collecting the data from there, and perhaps most importantly here is, let me say back then systems, this could mean something from a loyalty program. This could mean CRM data, data that you have going back years and years with your relationship with your customers. The key thing is making sure you're collecting all that data. As I said, the data collection is really built natively for each of those channels, and it's really important to not to try to pigeonhole data, say, from a connected device into a construct that's more suitable for a website or vice versa. Each of these data sources is a different channel for your customers. Your customers will interact with them in different ways. Therefore, you do need a specific approach for each of those channels when collecting data from them.

Once that data is is in your CDP, then it's really connecting that data to various destinations. So the first on the left side, you see some examples like analytics and attribution, A/B testing, etc. The key elements look for is that your CDP has the ability to stream that data in real time and that's, that's really important for both sides. If you look on the left and the right side of this chart, and what I mean by that is that if you're doing an A/B test or some personalization use case, it is key to have the most up-to-date information on your user or customer available to the channel that's doing the A/B testing or the personalization. In today's world, you can't afford to create a personalized experience to something that is no longer relevant for your customer.

Proximity, made a purchase, or they're browsing something else, and that old data is no longer relevant for that moment in time. So the moment in time is key. You want the same thing for the marketing side of the house. So it's not just a personalization on your own properties; but say you're in paid media, your attribution tool is going to be providing a lot of value in reporting on what paid media up-channels are working for you and help you make those adjustments on the fly to get the most ROI from your paid media, so you want to make sure that is also collecting that data in real time when we differentiate between events and audiences here, too. And then really you could put audience, you could put both events and audiences on both sides of this equation. If you think about it, when you're looking at those various channels, but really what that means is having the flexibility to get the right sort of data to the right tool at the right time.

There are some tools like we mentioned with analytics or say attribution where you do need to expose the raw data, what we call events in mParticle nomenclature, and get the raw data to these tools versus there are other tools where audience data is perhaps more important. Meaning you maybe you don't need the raw data there, but you need to get segmented user data into these platforms. So knowing which users are in which segments will help you with that marketing execution. But perhaps most importantly in all of this is really that your architecture, your CDP, has to be user-centric. And that's why we have the user at the center of this architecture, collecting data from all of these various sources with two-way connections with those execution channels that I mentioned earlier.

You need to be able to resolve all of these to a single view of the customer. Your CDP needs to have the ability to say, okay, I set a cookie on a user when they were on the web, and they authenticated it. And at that point in time, perhaps I got an email address. I need to be able to have my CDP use that email address they saw on the website to connect it back to perhaps some data that I saw from this CRM system into the CDP. Or it could be an email, open the email, open data for my DSP back into CDP. All of those discreet interactions, those discrete data points need to tie up to a single view of the customer so that, as you propagate that data throughout the ecosystem, you have it resolved to one profile and are able to efficiently execute upon those things I mentioned earlier.

So with all that said, let's get into the meat of it. How do we make all of this happen?

The approach we like to take at mParticle is to think big and start small. So what do we mean by that? Let's start by thinking big on this slide here. We've laid out a sample architecture just laying out some of the different types of connections and use cases someone could pursue through the mParticle CDP, along with some examples of each of the types of tools that could execute upon those. When embarking on this journey and saying, okay, we're going to think big. We should lay out the end-state. What do I want my staff to look like? What are some of the key components? Do I need an attribution tool? Do I need a tool for marketing automation? What are the various channels that my customers interact with me and who's data I need to get into the platform?

And where does it need to go? So layout that end-state first and have a vision for where you want to go. However, that said, we don't want to boil the ocean. So how do we talk about getting some incremental wins and starting small before we get to that big picture?

We have a quote here from one of our customers that bullets where they started with a very similar need as a CPA that I described earlier. They just wanted it to achieve some engineering efficiencies by making it easier and faster to deploy new services, new digital services from third-party vendors without having to implement a lot of custom code quickly. Though they found a customer benefit of that, as you see here, within weeks of implementing thanks to a faster, more stable app experience as a result of removing all these.

A third-party coach, could you explain how that works now? How they were able to achieve a faster or more stable app?

Technically? Yeah, absolutely. This is one of the underlying benefits of the CDP, which you can perhaps get. It gets a little lost in the discussion when you're talking about personalization and more execution, but it's really a technical win of having one integration that can connect you to a series of different tools that perform things across various functions. The win here is that without a CDP in place, you're really building some point-to-point integrations. And those integrations are painful, and this is really the win for Lilly Pulitzer. As you can see from the example of how Lilly went about it, is that the first tool they deployed through their CDP was an analytics tool.

So you do all the work of understanding what your KPIs are, what you need to track for various teams and crawl across the organization. What you need to report on to your executive team and then implement that data collection via your CDP and then begin sending that data to your analytics tool. And that's really commonly the case across our customer base; they really want to first target certain use cases, then they light up once that's done right. Further down the line, there'll be a need to do some of the other things we mentioned like attribution or other types of tools that really need to consume the same type of data without the CDP in place. Each time one of those tools comes to the table, you've got to go. The business stakeholder that needs to use that tool has to go back to the technical team, do some horse trading and, and get on that roadmap to say, "Hey, can you implement this code in our app or connect this API to our CRM database so that we can get this data into this attribution tool or to this email tool?"

Versus, well, if you did the exercise once and implemented your mParticle as your CDP and we've connected mobile apps to the analytics tool. The next tool that comes along, there'll be an integration with the CDP, and you can let the CDP do the work of integrating rather than taking away resources from your app development or whatever your core job is to do this integration. And furthermore, there's also the technical performance benefits. So there's less third-party code that you need to manage and maintain as you go about changing things in your environment, or even as your partner whose SDK is implemented or whose API is connected to make changes on their side. You need to keep up with them as well. And this is true across every platform we just highlighted, including mobile here on the left because mobile deployment until the appointment is like open heart surgery, right?

If they cut open the app and you know, create these SDKs, deploy them onto every end-user client, and it's an enormous engineering effort. Not that is easy to get data in and out of CRM systems or web systems either, but mobile adds a whole other level of complexity. And then on the analytics side, I was reading that the average large brand has two point five analytics vendors, so there's never just one tool you're trying to deploy, there's always going to be multiple over time, and you might as well create a central data layer that you could deploy once and then federate everywhere.

And a lot of times some of those things are outside of your control, like the vendor landscape is always changing, right?

We always see the new Lumasphere charts and all the other ones thrown about in the industry. And sometimes outside forces make for changing vendors, or to your point, you may need more than one even without those outside forces. So the other problem that we tend to see with customers that don't use this sort of approach is that their data is inconsistent. I'd really, really silly example, an eCommerce company might say, okay, it's called view product. When someone uses a product detail screen in one tool, it's called product view. And in one tool it says user exited five times yesterday and the other tool says user exited four times because, well you know, this code is implemented two years ago, and then the person who did that left the company, and someone else did this next one. And you have this data problem where your data is not consistent across channels.

So the good news is once you simplify the way your data gets collected and managed in a single platform, then it's also a lot easier to join up the data. And the next step in this stairway to heaven is to start to generate some additive insights. And the quote we have here is from our. Our clients used to be a jet. I'm now part of Walmart. You don't want to be looking at marketing in a silo. You want to look at how your app marketing is affecting web, how web is affecting app, and with mParticle, we can send any data we want to third parties, and we could send it back to mParticle. And most importantly we could send that data from an article to our own databases. And what she's talking about here is really the primary use case we see from a lot of brands at the stages is longitudinal understanding of the customer journey for better marketing attribution. So to figure out how to acquire this customer through channel x. Uh, did they stick around? Do they actually buy from me over the long run?

Can you take us through how that, how that works technically?

Absolutely. So in this sense, it's exactly like you said, David, the next use case to fire up through the CDP here was attribution. So you know, some, an example of some of the vendors that you could use for attribution right here on this slide. And essentially what those tools do is that hey'll integrate with your paid media out there, so they'll know which ads are being served and who they're being served to. The CDP role is really on the conversion front. So when the user will ultimately come back to your website, come back to your mobile app, they need to know what they performed, right? Whatever your campaign's goal was, that attribution's nice to know that so they can provide you that reporting to give those sorts of insights you mentioned that Lauren mentioned in that quote.

Now the key here is, and this is really where you begin to see the quick winds and the winds beginning to add up and climbing the stairways. So we always discussed before, we don't need to do another tech project to turn this attribution too long. We've already implemented our CDP, so I wouldn't have a prebuilt integration here with the attribution tool. Few clicks. Great. Now the marketing team has those insights into the marketing campaign performance at their attribution tool provides you. Well, a good CDP will—and mParticle will fall into this category, or so we like to think—we'll also have bi-directional integrations with said tools. So in other words, beyond just activating the attribution tool through the CDP, the other stuff, when this was getting the attribution's postbac data out of this attribution tool and back into the CDFI.

And guess what? So if we talk about the stairway and some quick wins, the war they did before to integrate the analytics tool with them, particle is already bearing fruit because as soon as they made this connection for the attribution's will backup and political, that marketing campaign performance data is now going to the analytics tool or tools of their choice, and now it's sitting alongside all of that other data about the revenue and other user behaviors and other KPIs that are being tracked for, for non-marketing use cases, right? Going right to the heart of the quote which was, hey, we're not going to look at marketing, and in this case, it's really paid media within a silo. We're going to look at that performance alongside all the other behaviors and things that users are doing on the app or on the website and tracking alongside all of our other KPIs that are getting really far outside of paid media.

What about DMPs?

So the CDP is not an attribution tool or analytics or replacement for those tools. It's an enhancement that enables those tools to be more effective and have a more complete picture of the customer journey. And, Paul, you spent a lot of time previously in the DMP world and it strikes me that that's one of the biggest differentiators between DMPs and CDPs is that the CDP is built to persist data over a long period of time. We have some customers that have persistent data over many years. The cookie—I don't know what's the average cookie lifetime, like 28 days or something like that. You can't really fulfill these use cases. But aside from the longevity of the data, the ability to persist data, are there other sort of non-digital sources that you would include in this type of attribution or marketing analytics enhancement? Would this be a step in the journey where you might bring in some customer service data or product or sales data or other things beyond just the digital sources?

Yeah, absolutely. I think at any point in the marketing journey the non-digital sources are some of your best data like that could be, for example, a loyalty program and the work to get it into CDP is a one-time effort. But underlying your point is that that one-time effort, no one will connect that to analytics and all the other use cases here, but to the right, you want to build up that user profile in the CDP. If talking about CDP versus DMP, really the main difference is that a lot of DMPs, they're great tools that were, that were really effective at getting cookie-based data downstream to DSPs, SSPs, out servers, etc. But really, they always had to tie things back to cookie, right?

Even if you imported the CRM database, you got to see a user on a website, have them log in to look up a hash file and you've matched to a cookie. Whereas CDP you don't really have to marry that lookup of the CRM data to your website natively say, okay, let's ingest that data based on the user's email address or based on some CRM ID and then we'll tie that single user profile together. But channels such as email, for example, there's no point going back to a cookie id when you're activating to your esp. You want to send it against an email address, and a CDP will take that data against email and marry it and anything else that you might have an incentive to collect downstream. So certainly, it is always a good time to get those non-digital sources into the CDP, and that is where CDPs excel relative to maybe some of the web-based tools out there.

Real-time data activation

So now, now we will start to talk about activating the data into engagement channels. But we're not even going to talk about advertising yet. We'll get there. We'll get there. In a minute, I'm going to talk about a very sophisticated use of owned messaging channels, which is Via, the ride-sharing service. Ori from Via has this quote, "We can really understand the specific context of every rider as he or she opens the via app and starts to request the ride request process."

So the person who opens the app and they get a personalized experience based on their physical geolocation. And by doing this, we're able to maximize the likelihood that the writer will end up booking on the platform. Now, I know who we're speaking to already, that I'm behind the scenes a lot more is happening.

A lot of people opened the app. I'm a regular Via customer, and what else for me holds true for a lot of people. If you don't see a car within seven to 10 minutes of where you are, you'll probably shut it down and use a different ride-sharing app. There are advantages to using Via: the cars are the best in the New York City area, it's cheaper because it's a great ride-sharing service, but if there's not a car in the area, you really don't want to wait 15 minutes for that vehicle. So what Via does behind the scenes is that as soon as you close down the app, it then sends a bunch of messages to drivers who are, who were in the nearby vicinity, using a CDP to power these communications. Say hey, something might be going on.

Actually, just on Saturday, a Billy Joel concert happened to be letting out at the same time that I arrived at Madison Square Garden. So I'm sure a lot of people were opening up the Via app, and Via was actively communicating with all the drivers. Say, get yourselves over to Madison Square Garden. Then what happens is if I had originated the request and did not fulfill it, I'll get a message back from saying, hey, there are more drivers in the area. You want to give us a second look. So this is a great example of using situational context, married with messaging channels to drive better customer experiences and, and better business outcomes. So talk us through how that works a little bit.

Yeah. So what does that mean for CDP implementing? One of sending one up. So one of the key activations for many customers via their CDP, our marketing automation tools and you can see an example of a couple on the, on the screen right now. So for the, for the Via example, right, it's okay, we've got data coming into this UDP coming from mobile apps, right? Key channel for, for bio of course through those mobile apps are feeding that information into the CDP about, hey, if the user is active near a Billy Joel concert, the user may or may not be looking for a ride. You'll know things about the user's account. That data then feeds into the marketing automation tool. You know, key point for Via too, if you think about it, is that they have a multi-sided marketplace. So Via needs to message their passengers or drivers, right?

"Hey, you know, you're leaving Billy Joel now, save 10 percent." Or whatever the marketing message might be for them to then want to get home with Via. At the same time, they also need to tell their drivers, "Hey, there's a, there's a Billy Joel concert, and there's going to be a ton of customers coming to this area." And so drivers can make adjustments as well. So the real-time nature of the, of the CDPs ability to get data to marketing automation tools or any sort of tool is key here. Now if we continue on the stairway theme, I should say, so we've got marketing automation in place, we've got the behavioral data in real time coming from users, mobile apps and are aware of their location, aware of their actions, but Via needs to be able to make those decisions as to strategy like, when do we send those drivers where and when do we message the riders. Like many other customers, they've implemented their analytics tool for the CDP to the analytics tool. That tool then gets that data as well and feeds it to their marketing automation tool, but it will also get the campaign performance data out of those automation tools and back into the CDP.

Now after that Billy Joel concert, they'll go back, and they'll say, okay, well did this really work for us? And it's not going to be just in a silo of seeing who opened the push, who opened the email, or whatever their messaging was. They'll be able to look at that alongside all of the other data, behavioral data from apps and websites in their analytics tool, but also from any other CRM data they might have.

Those offline channels, any propensity scoring or modeling you might've done, enter all of that into the CDP. Again, we've got that in the analytics tool. We're using that to power some of our marketing automation, and we're also bringing that campaign performance data back in to continuously improve upon what we're doing. Right. So again, you see those quick winds adding up and the effort that we did a long, long time ago to implement that once and get into our analytics tool is paying off as we become more sophisticated with our usage of data for various marketing activities.

Advertising

Let's talk about advertising just for a minute. How does all this apply for to advertise because obviously that's another paid media is another area where you'd want to activate data, to the same rules apply to cookie-based systems or are we only talking about identity-based advertising? Like what, what's the common kind of pathway when it comes to just the paid media types of execution?

Yeah, I mean I think the main thing, and this is where a CDP is key, we just talked about notifications and emails and push and push notifications and email, right? Those aren't a cookie-based type of messaging, and those aren't paid media either, but as a marketer you're always deciding, okay, well what is going to be the right channel? There's time for paid media channels, and there are times where an email or push is the right channel. Not doing that in a silo is important. Right? So you will know that perhaps you might want to customize a, an email knowing that this user has interacted with your Facebook ad or had done something with you on paid media. So that could be a huge factor In deciding the when or the how of messaging that you might be doing in a channel such as push or email. So the paid media might've been on a cookie, the second message might have been against an email address, but the key is again, having that architecture that could easily manage data through all the channels and not try to pigeonhole everything into say like a web-based or mobile only base with ComScore.

Well, that leads well into our last example. And then I think we'll have a few minutes for questions if people have any. Getting back to Overstock, until now we've really talked about a lot of predefined segments and orchestration role. So if someone opens the app and is in the Madison Square Garden area but does not book, then do this. When it comes to Overstock there, I'm using fairly sophisticated integration with a machine-learning engine to generate custom scores that are constantly being modified on the fly and then writing those back as attributes to mParticle. And I know that one of the models that attributes is channel propensity. So deciding whether people are more likely to be email engagers are aggregators and then making that decision between pain and own based on the person's profile as opposed to some aggregate understanding of what channel they think performance message in general. I know other types of scores they are creating are customer lifetime value, time of day. And all these are through a really interesting machine-learning integration.

So why don't we wrap up by getting a bit of a peek into how that looks and how that fits into the diagram that we've been building here. So you know, this is a generic example, so this isn't specifically what any one of those customers did, but protecting the security of their architecture, that's the key at the bottom where you see data warehouse or internal data cloud or insert whichever data bus you want to use. But for Overstock, it's a two-way street. It's feeding all of the behavioral data from the website and from the mobile app as well as from their marketing campaigns like email opens, push opens, paid media attribution data, and eCommerce data into that machine-learning system. Then lets this best-in-class system that will do all this analysis for you, set up whatever propensity scoring you need, do its thing, and then build an integration from that tool back into your CDP such that once you know that, okay, this particular user you've passes for propensity, that'll inform many different use cases.

Okay, a certain paid media type of execution that you will want to reach them on this channel with the sort of messaging I know for Overstock, a big one is within their own property. While paid media is key, it is certain that they know that in today's world their customer expects an omnichannel experience. I think they're a good example of someone who's actually making them happen there. They're taking data from one channel and knowing that you know, user did this or you bought that on a website and then tailoring an experience within a mobile app based upon that data. And also factoring in, like I said, other data that might've happened in paid media or email open and so forth. The key thing here is just having that connection. So it's not just, you know, third-party tools to do all like old whose logos you see on the left and the right of the slide.

But also internally, if we're using some data warehouse or heard some of the tools that they're using for analytics sorts of personalized and experience, making sure that those are properly connected to your CDP and again, hitting Oklahoma similar themes we had before that where we're solving the right identities, meaning with this channel, it was a cookie and this channel, it was an email address and we're making that data available in real time. I think that also goes back. That's probably the most important thing here when you're talking about personalization, is that the data is available in real time. And it was like a push and a pull model.

David Raab, who is considered the father of CDPs, is an independent analyst. I saw a post of his the other day on social media that doing personalization with bad data is like trying to cook with bad ingredients; it doesn't matter how good your cooking skills are, if the ingredients are bad, the personalization will be bad and that the customer experience is going to be bad. So you can sort of think of a CDPs as variety of the front end, the freshest ingredients, but not replacing the artistry of the chef, which is either the data sciences teams or the machine learning engines that they employ. To wrap up a couple of best practices that we've covered today would be one starting with the customer and their journey and thinking about the customer value before thinking about the technology architecture and business objectives.

A fast follow is aligning the business objectives so that you're in that power alley, where you're fulfilling both business and customer a customer objectives and then using, creating a map to galvanize all these diverse stakeholders across your organizations so they can really understand about what the, uh, what a CDP will deliver in terms of their, their customer experience in terms of their business needs and your particular customer experience. Because not all CDP implementations are the same. There are many different reasons for the CDP, probably as many different business strategies as there are out there in the world. It's by no means a kind of a cookie-cutter model, then stay with the customer by deploying a customer-centric architecture along the lines that Paul laid out, and putting the customer's user profile at the center and surrounding it with real-time events and all the integrations create and iterate on the right plan which essentially has you thinking big but starting small and showing incremental value along the way. Incremental value as in the case of the culture can be, you know, as fast as within a few weeks, and you should be showing wins probably every 100 days. You could be deploying new use cases and using that to galvanize the organization around the CDP program, and as you said, the wins aren't linear. There are many, many cases where the value increases exponentially the more data and connections or are integrated.

Thank you both so much. We hope that you really enjoyed this webinar and we have a couple of questions asked by a few of our attendees and if you haven't actually sent one in, but have a burning question that you'd like to hear answered head to the bottom of your page, you'll see a Q & A box and you should be able to right there.

So the first one that we have here is what is the best way to get data to DMPs and DSPs? Do I still need a DMP?

I think the question about whether you need a DMP is entirely unrelated to the question of whether you need a CDP, but I think that that tends to come up a lot because DMPs were probably one of the first digital platforms that were used to get data to marketing channels. So it's certainly understandable why there's some confusion out there. You know, there are a lot of things. DMPs do well that I think CDPs aren't trying to do right there. There's a lot of prebuilt, for example, the third-party data marketplaces, right? All the DMPs common with a lot of a third-party data prebuilt into the system. And there's a lot of good use cases for collecting that third-party, that upper funnel, and activating that on paid media channels. So if you're really looking to leverage some of that third-party data that is primarily tied to a cookie essentially, right? As we see with GDPR and other privacy initiatives, a lot of that data can ever only be tied to a cookie and then certainly you should use a DMP to layer that to send that to various SSPs, DSPs to run display ad campaigns and those are the right tools to do that sort of job.

I think if you're looking to execute upon some of the use cases that we discussed today and you're really looking to get data to various channels, get data in real time from digital and non-digital, cookie-based data, email-based data, we then really the CDPs is the right tool for the job. And increasingly what we're seeing is that a DMP ends up being a big recipient of data from a CDP. In other words, a DMP is a great, as I mentioned, to create execution channel for vet bills, paid media use cases that we mentioned, so leveraged their CDPs capabilities, leverage all the work that you did to integrate your CDP and sure activate that in your DMP.

Another question here: you mentioned Lilly Pulitzer, do most retailers start implementation with a mobile app?

I don't think there is a trend in either direction on me. If we look at our customer base, it's pretty split. Sometimes it's just dictated by a development calendar, which one you ended up doing first. Sometimes it's also where within the enterprise the priority came from. If a company is focusing on mobile as a big channel, they might have more resources galvanized and ready internally to do work on the mobile app versus on the website. So often decisions that end up dictating which channel goes first, for Lilly that happened to be where they were at that point in time. So other businesses just know that hey, our website is still the most important channel for whatever reason mobile is not, or vice versa. It may be a mobile-only this and this, so if you're only one channel of course, as the channel the implement, but when your omnichannel, I think there is no right or wrong order to do it.

It just ends up being what is right for that customer to think. Part of it's the practical matter of, like you said, the development calendar and the strategy that's in place at the moment, so Overstock did not start with mobile is another example. It's almost starting with web and expanding outward. But mobile is in Lilly's case, a very important loyalty case comprised of a very small but engaged number of users, not driving a lot of transactions but driving a very important customer experience. And particularly for millennial customers which have a particular high value and creating the best experience for them. You know, it has to start with mobile, and that's where there are the least development resources typically. Companies say, okay, we've got enough development resources on web, but then mobile is like this order of magnitude a greater data challenge, especially when you talk about having multiple platforms, Android, iOS, and others. That is typical for people to find a major need and, and start there where there's a house on fire type of issue.

So this one's just a quick follow-up to that one. Do you need an app to utilize mParticle?

Absolutely not. You could even say you don't need a website to utilize an article. I think that's the key is to, you know, if you have user data, there are use cases for you with the cd if you use your data you want to execute upon I should say. And there are use cases for you to have a CDP. So you don't need a mobile app only to use mParticle. You don't even need a website; if you have data tied to your user and you want to get that data into another system to do marketing or analytics or anything in that realm you've got to use.

Yep.

Great. So we have just two more quick ones here. The first one is what about the GDPR? Can I still collect customer data?

Yeah, that's a good one. A key CDP feature, based on the use cases we've mentioned today we didn't get a chance to unpack more and talk about how mParticle is really controlling your data. We talked a lot about activation and how effective that can be. Really controlling data is key to executing successful, knowing where your PII should or should not go, and being able to change that on the fly as some things like GDPR happen or as your regulations might change within your business is key. In terms of GDPR and how mParticle helps with those controls, a set of those apply to GDPR. In other words, what we see our customers doing is with GDPR, they're collecting and applying consent. There is a greater focus on that, a greater need for transparency around that.

So users will interact with them on websites or mobile apps, and they'll say, hey, do you consent to marketing? And ask users to agree. Users just might agree. Users might not agree. With the use of a CDP, it really helps you in a few ways. The first is, let's say they don't agree to marketing. But that doesn't mean you don't have a right to collect any data on them; you still have your customer, you probably will still profit, but you need to know who they are to provide eCommerce or to certain analytics center in-house and not third-party. So what our customers do is they'll send that consent information and then rely on some of our GDPR capabilities to attribute, "This user did not consent to marketing, so do not send their data to any marketing based tools. This user did consent to something else, so their data will only go to certain types of tools." So it really is a framework within the CDP that allows you to control where data goes based upon what consents they may or may not have received them and really beyond GDPR, you can apply that same sort of framework and we're already seeing this from some of our customers for other types of regulations that deal with that messaging and advertising. Things like HIPAA when you're dealing with healthcare data or a VPA for collecting video viewership data for if you have an app or a website where there might be content geared towards minors.

And there's a longer version of this presentation if you could believe it. The reason I mentioned GDPR under the simplify step in the customer journey and the stairway is because by simplifying and reducing the amount of third-party code in the app, um, you know, having a consistent methodology and strategy for data collection and federation. It doesn't solve all of your GDPR problems, but it's will address a good deal, and that is a customer win, as well as a business win because the worst customer experience in the world is a customer or a company that misuses your data or experience. Or worse even, being part of a data breach. So for security and data protection reasons, data simplification is actually a quick win of a CDP as opposed to a kind of the opposite of liability. A CDP gets your data in order, cleans up your house and then downstream lets you activate it in responsible ways.

Great. And so we just have this last one. I apologize that if we're not going to get to your question right here, but we do encourage you to please get in touch with us, as you can see both David and Paul's contact information right here. We're more than happy to answer via email.

Does mParticle help with global frequency? How does a CDP help with cross-channel coordination?

Yeah.

A CDP can be a key part of those sorts of things, right? So obviously frequency capping is something you will set in the execution layer, right? Where if you're a frequency capping paid media, it's in whatever channels serving paid media for frequency, capping a email or, or push it's been happening, it's going to happen in the tool that delivers those messages, but the key role for a CDP and all of that is making sure that those tools have the right data in order to adjust the frequency caps. Right? So in other words, you might frequency cap just based on like, all right, I know if it's three, three greater than three messages, I never want to do it again. Or you might do some more sophisticated a journey building if you will. That takes into account, you know, I might be frequency capping and paid media, but uh, based upon having these are having seen an email as an example, right?

I don't think I know any paid media source that talks directly to a DSP and that's where a CDP is key; where if you get your email opened data into the CDP and then use that to drive your data segmentation, that's going to be happening in paid media. Then when assigned to frequency cap, the paid media, you can do it based upon a user of receiving a particular email with the CDP is that glue that speaking, that's going to make sure that the cd, the esp is aware of what's going on in paid media.

Great. Well, again, thank you both so much for joining us today and all of you at home and work. We hope you enjoyed it and that we'll see you next time.