Missed "Between Two Firms"? Catch the replay and transcript here!

On Wednesday, July 8, we held a "fireside chat" with experts from Hull, mParticle, and The CDP Institute. If you missed out on the engaging conversation with Romain, Michael, and David, or would like give yourself a refresh on the topics, we've provided the video replay as well as the audio transcription in this blog post.

Some of the key topics covered include:

• Defining and segmenting the CDP market
• Commonalities and differences between CDPs
• Building for the enterprise vs. mid-market
• Security
• Integration breadth and depth
• Buying a CDP: considerations and timeline
• Customer success stories and use cases

Watch the replay

Embedded content: https://youtu.be/wHz13TK6VKs

Read the transcript

Abril (01:36): Hello everyone, and thank you for joining us for today's Fireside chat, Between Two Firms featuring Romain Dardour, CEO and co-founder of Hull, and Michael Katz, CEO and co-founder of mParticle. Today's chat will be moderated by David Raab, founder of the CDP Institute. Before I hand over to David, just a couple of housekeeping items. Number one, can everyone hear us? If not, please let me know in the chat. And then secondly, we will be recording this session and we make it available to you after the chat is over, and it'll be delivered right to your inbox, so don't worry. And finally, feel free to add any questions you may want answered in the Q&A box at the bottom of your screen and we will answer them during the Q&A portion towards the end of the session.

Abril (02:27): And with that, I'm going to hand over to David. Thanks so much.

David (02:32): Thank you and welcome, everyone. Thanks for joining us. So, we're going to jump right into questions here. We have two great people to answer questions and I love to ask questions, so everything's perfect here. So, let's start actually with what's the CDP really? And what isn't a CDP? That's probably the number one question here. So, Romain, you want to start?

Romain (02:56): Sure. I mean, obviously, you started with one of the hardest questions. Everyone has their own opinion what a CDP is, isn't, should be, should not be. I personally believe that it is, I mean, apart from the market differences like B2B, B2C, there's a few ... there's two very important categories. CDPs are mostly focused on data integration, creating kind of a central customer data pipeline that is consistent and reliable across systems. And there's a bunch of other products, which are also CDPs, which are more focused on the kind of the front-end systems of action. So, think predictive analytics, the ability to use a AI to derive customer value, those kind of tasks.

Romain (03:53): One of the other ways that we can see that is obviously B2B versus B2C. I think those products handle different types of concepts and objects, have different sets of connectors that are suited towards the use cases that are more valuable. I could go on and on, but Michael, do you want to add some things about that?

Michael (04:21): Yeah. Look, I think you hit the nail on the head with a lot of that. Ultimately, when I think about what a CDP is, it somewhat depends based on the buyer, the need, the type of customer, the type of data we're talking about. But yeah, ultimately it's a system of movement, right? Our job is to get data that is created across a number of consumer touch points and may reside in a number of back-end systems, create a unified view of a customer, and protect quality and integrity along the way, and then make it really easy to govern that data as it gets connected out to and from a number of different destination systems. So, whether that's analytics or customer support or marketing automation or your data warehouse. We're typically agnostic as to the types of use cases that we support and the types of systems that we plug into, but our job fundamentally is to make sure that the most recent view of that data or the most recent version of that data is synced across all those systems and as close to real time as possible.

David (05:43): So, all right, so you just added real time into the mix. You certainly talked about getting data from different sources and pulling to together and sharing it out. Then Romain talked about some CDPs do that and some CDPs are more on the activation side, although I think you would agree that they also do that first things, right? I mean, everybody's got to pull the data together. At least that's my definition of the CDP. But why is there so much confusion? That's a pretty straightforward concept, right? It pulls all the data together. What's the big deal? Why is there so much confusion in the market? Michael, may I ask you about that?

Michael (06:19): Yeah. I mean, I think it comes down to market segmentation. There's obviously been a lot written about this space and I think the attention on this space over the past couple of years is certainly warranted. But there's so many different types of CDPs, right? I think the first real bifurcation and you see it based on the two of us today is, is the CDP geared towards B2B customers or are they geared towards B2C customers? Because ultimately, the data's different, the use cases are different, many of the integration partners, the integration ecosystem is quite different. And so while I think the core of it is very similar, you peel back the layers and things do become kind of quite different.

Michael (07:15): And then I can speak to the B2C side of things and then I'll pass it over. But on the B2C side I see two different types of CDPs. I see infrastructure-centric CDPs and typically, we're focused on helping brands protect data quality to instantiate a layer of data governance and then integrate that data across their different systems.

Michael (07:48): And then we have the application CDPs, which are a little less opinionated about where data can come from or the speed by which it needs to be ingested and transmitted, and they really center around a single use case, which is to help marketers with segmentation and in some cases uncovering some additional insights. So, I think both are ... it's fair to say like both are CDPs, but the job to be done is fundamentally very different.

Romain (08:31): David, you talked about the fact CDPs more focused on kind of the segmentation side would be collect data from the various sources. I see a little nuance here. Collecting data is actually a part of the equation. Another part is how able are the products to actually send the data out and more precisely, to have bidirectional integrations. And this is where you usually see a difference. Some CDPs are really good at collecting data, but then the purpose is to show it inside of their product or to build audiences that are sent out, and some other are more about like real time streaming bidirectional or multidirectional integrations in kind of a fully connected hub and spoke system where systems would update one another. And I think this is actually a pretty complex job, I've been trying to do that for several years.

Romain (09:42): It is a thing that is often glossed over. We talk about how many integrations we have, but the reality is are those integrations just about collecting that data or are they deeper than that? And then you can go even deeper, what types of objects do they support? How fast are they? What are the limitations? How do they connect those objects and link, let's say, a user to an account in B2B? I mean, the landscape actually becomes pretty rich when you get into the data integration side of things because data itself is obviously complex and especially when it evolved from kind of an array of unconnected tools and you decide that you actually can't work more with that disconnected data and you need to centralize it.

David (10:33): All right. All right, there's two things. I want to come back to the point about that there's integrations and there's integrations, because that's like a level of complexity or nuance that's easy to miss. But before we get off the other thing, is there something that all the different CDPs have in common? Because you guys are talking about like, "Well, there's two kinds of systems, we call them both CDPs, but they really don't have much to share."

David (10:57): Is there anything that you can say, "This is what makes it a CDP and if it doesn't do this, I don't care what else you do, you're not a CDP?" Either of you. Michael, go ahead.

Michael (11:08): Yeah. I mean, I think all CDPs create some unified view of the customer, right? So, at our core I think we're all effectively trying to unify data across lots of different sources and systems, right? I think how that happens, the control around protecting data quality and integrity, the flexibility and identity resolution, the details, which ultimately heavily influence the quality by which that job happens are all very, very much kind of fundamentally different. And I think it has to map to how do you view yourself as a CDP?

Michael (12:06): I actually, for mParticle, I don't actually think we are a marketing tool or a marketer tool. I actually don't believe that we are in marketing tech at all. I look at what we do and the role that we play in the ecosystem as data enablement infrastructure that simplifies that marketing tech ecosystem and landscape, but we don't play squarely in that landscape. So, when you think about it like that, our job is to empower all of those companies that are used to help brands drive growth.

Romain (12:45): One of our customers actually coined a very, very nice way of describing us in actually those kind of ... I think the term that has been coined is foundational CDPs. He said that his job and actually he used Hull as the main tool for that was to bring the right data to the right people in the team as fast as possible. And I believe that this defines pretty well what the CDPs job is. It's actually more of a data integration job if you look at it. When we talk about B2B companies, there's marketing but there's also sales, there's customer success, there's product, and they all need data. And incidentally, data is a set of facts and ideally, you want those facts to be the same for everyone. So, that's how I would describe kind of the core job of a CDP today.

David (13:45): Okay. So, you guys, I think, looked at, we heard about two dimensions. B2B versus B2C, talking about segmenting the market, and then the infrastructure CDPs, the ones that basically assemble data. I think both of you put yourself in that category versus the marketing tool CDPs that have the personalization and predictive and all those other functionalities. Is there any other way that you would want to segment or subsegment that if those are the big four categories or combinations, two dimensions?

Romain (14:18): I would say that there's still kind of an emerging pattern here but some CDPs are really well suited to enterprise companies. Some others are made to be kind of lighter in terms of initial integration. They might have more limited features, but they enable smaller companies to be agile and to go to market faster. We are one of these kind of companies. I mean, the kind of initial approach when discussing the need for a CDP here, it's likely different. We do recommend that the go-to-market, I mean, the initial implementation starts from smaller projects that evolve into unifying things over time and expanding to more use cases. I think in enterprise companies it might be slightly different.

Michael (15:15): Yeah. I think we see the same thing. You have a number of CDPs, I think both on the infrastructure as well as the application side that are geared towards the longer tail down market. They have yet to make the necessary investment into the type of features and functionality that the enterprise requires. I mean, for us, I mean, we were built for the enterprise from the ground up. And so, I know what that has meant in terms of investment into ensuring scalability and reliability, and most importantly, security. There's kind of a number of well known data breaches across the space and when you're focused on providing a longer tail type tool, you don't think about security needs. You have to kind of move up market to get there.

Michael (16:26): But if you're built for the enterprise in mind, you contemplate that in your architecture and it manifests in the team that you hire and the processes that you have and the certifications that you get. We've never had a security breach and that's not just by happenstance. It's because we make multimillion dollar investments to protect our customers' customer data because if something were to go wrong on that front-

Romain (16:58): That would be bad.

Michael (16:59): ... it'd be game over.

Romain (17:00): Yep.

David (17:01): Okay. So, the little guys don't care about security, huh?

Romain (17:06): From my experience, they have a different approach to that. They do really care about security. I mean, there's not a single discussion that we had with prospects and customers that was not really putting security and data privacy front and center. I think it might be easier to ensure security on less complex setups, but I can tell you, I mean, for us, security's like a really big front and center concern. It depends basically how long the tail is. If you're talking about like five people companies, maybe probably they don't really care about security. When we say big market, we're talking about companies that are 200 people and up, and I mean, at that point, security's already something that is front and center.

David (17:58): Okay. I think they do have different needs in terms of user control.

Romain (18:02): Yeah.

David (18:02): So, the multinational guys, they have regional splits, they have functional splits, they have this one, they ... and they all have different kind of user authorizations, user authorities-

Romain (18:12): Yep.

David (18:12): ... which is also aspect of security. When I think of security at the enterprise level, that's the biggest difference, just the number of users. I don't know, Michael, if that's what you had in mind but I would-

Michael (18:24): Well, yeah. I mean, it's partly that, right? I think if you're really early on in your journey as a startup or a side project, security probably isn't a first order concern. It's shipping the initial customer experience, right? And that's really all I meant by that. I think security is a universal concern, I think, for all established companies. But when you're really early on in your product development life cycle, especially for a company that doesn't have existing operations, you typically layer that on after the fact.

David (19:06): Okay. Yeah, fair enough. So, let's come back to that question about the types of integration, the nuances. How are buyers who are not necessarily all that technical in many cases really supposed to assess, "Oh, this guy's integration has these four functions and that one has these six functions and they're not quite the same? And how do I know which one I need?" And blah blah blah. I mean, how do they decide, which may have nothing to do with any of that? And if they want to do it right, which I think does include those things, what should they do? Michael, you want to go first? I lost track of whose turn it is.

Michael (19:46): Yeah. I mean, look, it's a great question, right, because I think fundamental in pretty much every piece of software these days is about data portability, right, and being able to integrate across and along other tools. And so I think the notion that all integrations are created equal is a fallacy that we've dealt with for the first few years. I mean, we have a pretty well-known competitor and they tend to go pretty horizontal but not very deep, and it requires us instructing the people at the brand to inspect their docks and to do things like run proof of concepts or proof of values and start to dive into the nuances how things like identity resolution can actually have really significant downstream implications as it relates to how that secondary tool or the integration partner's functionality actually works.

Michael (20:56): There's also cost concerns, right? Our job as an integration system at our core is to also do it in a way that doesn't increase the burden in terms of cost or overhead for our customers. And so, if that fundamentally means that a ton more data needs to be shipped because you're maybe deficient in terms of your identity capabilities, you see that stuff really come out when you get hands on keyboard. Everybody has a demo, everybody tells a great story, it's all designed to be really flashy and perfect, but the proof is when you start getting real data into a production environment and connect it out to different systems. That's the only way that we've seen it to be really reliable.

Romain (21:51): I totally agree with this. I think most CDPs can send one lead to or one user into a marketing automation tool. The question is how do you send a million and can you do it reliably, and how do you update that million if only like a few changed? You have systems to mitigate the immense load that you could be putting onto the destination systems because you just created an audience that has like two million people in there. Do you have ways to control that? Make it at the same time reliable and efficient?

Romain (22:27): And when we're talking about like the depth of integrations, I think it all starts from the job to be done. If you're looking to synchronize, let's say, accounts and users if you're in B2B, well, you might want to look like does that integration actually support accounts? Or can it only send like a few [inaudible 00:22:46] on the user level?

Romain (22:48): There's also, we didn't talk about this earlier, but CDPs evolved from a bunch of separate features that have been assembled into a marketing package. And that means that if you actually look past the general overview, you realize that not all systems are supported in a way that is connected. So, let's say you could send data to a CRM but maybe you can't get that data from the CRM. Or you actually can get the data from the CRM, but you can only send it to the warehouse. You cannot send it to the marketing automation. That thing is usually where we actually want to sit down with our customers or prospects for that matter and look into what their actual use case is, what they are expecting to be able to do and see if we actually support it end to end, and if the products that they're contemplating can actually do that or if they're going to have to develop their own custom layer on top of that, which defeats the initial purpose of being agile and easily put together.

David (23:56): Okay. So, we've heard proof of concept, we've heard use case, we've heard hands on keyboard. So, is that the right way to buy these things is to really just kind of get your hands dirty at least with one or two products? That's a lot of work. And again, particularly smaller organizations who are very resource constrained, is that a realistic expectation for them? And big organizations are resource constrained too for that matter.

Romain (24:24): I would say, yeah. I would say that there is no magic system that you can just plug in and expect everything to work because data is messy. Every single customer stack that we've seen is a snowflake. It's completely unique. And so we can take a lot of load out of the complex parts of the system, such as like ensuring the reliability, operational, the security and everything, but we cannot configure the system entirely automatically. And in the same way I would say that trying to kind of buy a product that would solve all your problems in a magical way is probably going to be a very long endeavor. I mean, 10 years, 20 years ago we had an MDM, and they were supposed to do exactly the same thing if you look at it. But that was so tedious, so hard, so complex to get there that it ended up being that big thing that no one wants to touch because it's scary.

Romain (25:22): I think what CDPs enabled is a kind of a more gradual iterative agile approach to getting things right. And by starting with the right use cases, the delivery may give value, and then over time enriching that, while still being flexible. Yeah.

Michael (25:42): Yeah. I mean, I think the way that software is bought today, buyers want to be able to try things out. They want to see it, and feel it, and this, I think, falls in that kind of broader trend of the consumerization of enterprise software. So, to me, that is the status quo because I think the old way of doing it where you didn't get to try it before you buy and then you were stuck in these really long agreements with these kind of massive software vendors that would then try to jam a ton more product down your throat at the end of every quarter. Nobody wants to relive those days, right?

Michael (26:33): And so, the alternative of not being able to try before you buy is fundamentally much worse than the two week or month-long investment that you have to make to make sure that you're getting the right tool.

David (26:48): Actually, that was my next question is how long does it take to do that? POC's two week to a month rolling out.

Michael (26:53): Well, it could be longer.

Romain (26:53): Yeah.

Michael (26:53): It could definitely be longer. I was saying that kind of generically, but we've seen POCs that maybe only a couple weeks were proving that we can get data from different systems out to other systems. Other POCs may last a month or two. But I don't think it goes much beyond that.

David (27:17): Okay.

Romain (27:18): Yeah. Yeah, same. I think it's the same thing for us. It's like one week to four weeks. One week is when we have like a simple use case and we want to plug things together and then see if they actually flow through and customers have a kind of pretty clear idea of an initial jump to the gun that they can get done. Four weeks would be kind of a more ambitious approach where they have multiple systems that they want to kind of synchronize and compute data on the fly to derive information from the raw data and synchronize it. But it stays kind of really that kind of a volume.

David (27:58): Okay. I mean, a month is not that long in the grand ... it takes a month to get a response to an RFP. All right. I know we're kind of watching the clock here, so two more really quick questions. First one, how do I know I need a CDP? I mean, my answer is you're breathing, but other people might have a little more detailed answer than that. Romain, go ahead. How do you know? How does someone who's a buyer know?

Romain (28:22): I think fundamentally, CDPs are solving the problem that contrary to the product teams and the tech teams where you build everything around a central data layer, central database and you evolve your product over time around this, CDPs are here to solve a problem that there is no central place most of the time. Or at least everyone wants to be the central place and you end up with kind of a disconnected set of silos. And when it starts hurting because you lose efficiency, you will start making mistakes or just like way too slow to do anything, then you kind of want to look around like, "How do I get better at this? How do I consolidate this?"

Romain (29:04): Interestingly, I think in the future companies could start with a central place and build everything around this, which would actually make their job a lot easier. We've had customers who started that. But it's basically you're doing product and you want to ... you're doing product led growth. So, you want to react on the things that are happening in your product to trigger the right next best action in sales and marketing, and you realize that it's going to be just another one-off integration that you ask your engineering team. You want agility, flexibility and reliability, and if that becomes one of your core concerns, then you probably need a better tool for the job than just one-off point to point integrations.

David (29:50): Okay. Michael?

Michael (29:52): Yeah. I think the challenges that we solve are universally felt, right? I mean, put it this way, we are a company that helps other companies break down data silos and address fragmentation, and we as a company have data silos and fragmentation, right? And so, and we were built to help brands solve that very challenge and we face it ourselves. There's not a company in existence that doesn't wrestle with some sort of data fragmentation and data silos. So, who does the CDP make sense for? Really any company that exists.

Michael (30:40): I think to drill in a little bit, is there a moment in time by which you know that you absolutely need a CDP? I think if you look at it from the product development life cycle, I think that there are natural entry points along the life cycle. So, if you're in development pre-launch, I think I could argue that you implement the infrastructure that will allow you to collect data cleanly and in the right format and structure, and provide the controls that you will need as you grow the business. But I think I could also make a really compelling argument post-launch and into the commercialization phase or into the optimization phase that you want to be able to do things more sophisticated while also doing them more elegantly, and connecting data to and from lots of different systems, and driving consistent personalization strategies across disparate vendors and channels and tactics.

Michael (31:49): And so, I think that there's a job to be done at kind of each point within that development life cycle.

David (32:00): So, it's been said the best time to plant a tree is 20 years ago and the second best time is today. It kind of seemed with the CDP the best time was actually yesterday, but today is your second best. And you both use jobs to be done. I didn't realize that was such a common phrase these days. I'll have to note that down and work it into my next speech.

David (32:22): All right. So, let's look at some questions here. One questions is about use cases that will come up. Do you have a favorite success story from one of your clients that of course shows how great CDP is and maybe even how great your CDP is?

Romain (32:40): Michael, do you want to start?

Michael (32:43): Sure. Yeah, I mean, I think probably the most high profile success story for us over the past couple of years, I mean, there's a bunch but probably the Burger King Whopper Detour campaign that culminated with them winning the Cannes Lion Grand Prix. But the short of it was them drawing 17,000 geo-fences around very McDonald's in the United States and targeting users who had already previously downloaded the Burger King app, prompting them in real time with a push notification to redeem a coupon for a one cent whopper if they went to the nearest Burger King within the next 10 minutes. And the orchestration of data had to happen in real time across six or seven different vendors that we regularly team up with and partner with.

Michael (33:37): And the net effect, I think when you think about a brand like Burger King, I think historically, most people didn't necessarily think of them as like a technology company, but their app became the number one app in the app store. They won the Cannes Lion Grand Prix, as I mentioned. I think they successfully underwent digital transformation and it led to, I think it was something like seven to 10 million free downloads of their app, just based on the virality of the campaign. If they had done like cost per install campaigns, that probably would have been somewhere between like $15 and $50 million that they would have had to spend on that.

Michael (34:24): So, massive success and a ton of visibility.

David (34:28): Great. It's a great story. Romain?

Romain (34:31): I would say, I mean, one of my favorite customer is Pusher. We have ... I mean, we have a bunch of high profile customers but this one, they're a company that's doing real time push notifications. They're kind of a developer infrastructure tool. And so they are [inaudible 00:34:50] through the product led growth pattern. The initially came to us to solve kind of a very simple data integration challenge between Marketo and Salesforce, who are obviously hating each other probably and don't really want their integrations to work because that would siphon the users out of each of them. So, we were there to make that work seamlessly, and that was our first kind of a use case. And since then, the evolved into doing a lot more.

Romain (35:20): I mean, they rolled out more than five use cases in a year. I mean, in the very beginning, they took small steps and they kind of took feature by feature use case and they started with mid-qualification. I think the result that was that with the same set of customers, they saw a near 30% increase in their revenue through upselling because they were able to contact people at exactly the right time, but more importantly, for the right reasons. They were not just calling to say, "Hey, what's up? Do you want to upsell?"

Romain (35:54): They knew exactly what the conversation would be because they knew exactly what the customers were doing inside of the product. So, that was an interesting one. And then they implemented strategies for customer retention. Reactivation mail is a pretty interesting one. They saw that they had kind of an email to prevent turn that was going to result in a set percentage of turn cancellations so kind of retention. And they started going really deep into segmentation through the data that was stored into the CRM, the marketing automation. So, basically they were looking at like was that customer ever active or were they active in the beginning, but not later on? Do they have multiple people in the team? What the company is?

Romain (36:41): And they ended up with like a set of dozens of audiences that each had their own angle for preventing the term. They went up to like 30%, which is way higher. And then on a daily basis, they use us. They don't even have to maintain now any engineering to ensure that the data in their CRM and marketing automation is accurate and up to date. It just became invisible and I think invisibility's a good thing for a CDP. The less we hear about you, the better you are. You're just doing your job well.

Michael (37:18): Yes.

Romain (37:19): So, now they're actually, they're going into sending that same data into their warehouse to do some advanced analytics. Same thing, they have really, there are some really great BI tools and really great warehouses. We don't want to replace the BI tool and we don't want to replace the [inaudible 00:37:39] for this, and more importantly, we don't support all of the objects. We don't support invoices and products and everything else that is not a kind of a core offering of a CDP. So, when you want to do really great analytics, you want to combine those unified profiles with the rest of the data, and our job is to make that easy.

David (38:00): Okay. So, we have a couple other questions here, so let me just try to get some answers. So, one is how do you demonstrate for ROI for a given customer? Quick, easy question, right?

Michael (38:13): Yeah.

David (38:14): Quickie. Let's have a quick, easy answer. Michael, go ahead.

Michael (38:18): Yeah. I think, well for us, sitting at the infrastructure layer, there's, I'd say ROI kind of folds into the TCO analysis, so total cost of ownership. So, reducing opportunity cost, reducing switching costs, reducing maintenance cost, freeing up developer time from having to go and deploy lots of disparate tools, and then maintain them. You see that certainly in a very kind of pronounced way inside of mobile environments where you're talking about compiled code and shipped software, and there's really high carrying cost of vendor integrations.

Michael (39:12): There is a marketing ROI component to it because we can help our customers via our segmentation capabilities, then sync user lists out to their marketing channels in real time and then do global user suppression, so there's improvement from like the user acquisition standpoint. We can dramatically improve retargeting and re-engagement campaigns, especially when you layer on our calculated attributes product, which allows them to effectively bring data science as a service into the platform and start to do things like propensity scores. So, maybe some people are never going to respond to ads, maybe you should serve them emails or push notifications or SMS instead, and so don't waste money on paid advertising.

Michael (40:15): There's a number of different things that we do and we have an ROI calculator that we typically collaborate with, with our customers on to make sure that we understand the scope and how they're thinking about leveraging the CDP. Also to help them through the buying process internally. But there's, the value comes from a bunch of different areas.

David (40:40): Okay, great. So, both cost savings and marketing value. Romain, how do you do ROI on the [inaudible 00:40:46]?

Romain (40:48): So, since we're talking on the B2B side, sales is a very important part of the equation. For us, it's pretty simple. We can look at the deals and see how many deals we helped close based on the data, based on the conversations that were had. Same thing on the CSI. I was talking about churn prevention. It's a good metric. You can probably very obviously see the before and the after. And I think everything that Michael talked about is incredibly accurate. The total cost of ownership that you can measure in ... I mean, what's the time to market if you have a new idea and you want to make it live and reliable? Is it going to be six months or can you do it in three weeks? And that also helps you really clearly measure the before and the after.

Romain (41:45): Yeah, I think there's also how much time you save in manual work. In B2B, there's a lot of work with, let's say, things are still antiquated. You work with CSV files, lists of leads, and you need to exclude your existing customers and prospects from there, and that you need to do it every single week, and at every single new meeting, and that is literally dozens of hours that you spend doing that. If you can automate it and make it completely transparent and more reliable because you're relying a second set of data points, then you obviously saved a lot of your sales people team's time. So, I mean, that's usually kind of the way we go at it. We try to evaluate with our customers and prospects what are they going to be able to stop doing and what are they going to be able to start doing better and faster?

David (42:45): Okay. So, we're going to extend for just another five minutes or so here since we have so many great questions and such nice detailed answers. So, let me just jump in because there's actually a number of interesting ones. But there's a couple questions here about picking the CDP. So, is it as simple as looking at what integrates with your existing systems? What are some common mistakes that people make? Both of those are not quite the same question. Romain, go ahead. It's your turn.

Romain (43:15): I think almost every single conversation we have, not all of them thankfully, but almost all of them really quickly zone in on like, "I want to seek this and that." And we try to quickly reorient the conversation and say, "Okay, what are you trying to achieve by doing that? What is your business outcome?"

Romain (43:35): And when doing that we realize, "Okay, I just don't want to synchronize, let's say, Intercom and Salesforce. I actually want to take the opportunity object in Salesforce and apply it to the user object inside of Intercom, so that I can analyze what my opportunity looks like and do some better marketing automation with it."

Romain (44:01): The important thing is to talk about the job to be done, again, because this is what ends up answering the question, "Can we do it or not?" I mean, it's a fact of things that ... I was talking about opportunities, accounts, you have campaigns, you have users, you have accounts, you have events. All of those, they don't match the same way in the different tools. So, talking about which tool is supported is actually a very generic question. We need to go deeper and the best way to do that is to look at what business outcome you're trying to get.

Michael (44:38): Yeah, that's a, it's a great point and I think just looking at what integrations are there, again, it ignores the fact that not all integrations are created equal. But independent of that, I think we too try to get our customers to step back and to get out of this tools and tactics first mentality and to start thinking about, "How do I build the infrastructure and the foundation properly?"

Michael (45:10): So, so much of it is in the process of doing a deep dive and formulating a data strategy. So, we have this data design process that we take our customers through by which we help them think through what are the data points that matter? How should I be thinking about formatting and structure and nomenclature? What are the use cases that I want to enable? What are the KPIs by which I measure the health and success of my business? And you can kind of back into the integration piece, that's really just a means to an end.

Michael (45:52): And look, we're in the integration business. We have APIs, so whether we're building the integration or the partner is, it always ends up getting built. It's everything up and to that point where value ends up being accumulating before it gets connected out to that system where it think that there needs to be much more thought put into how the construct is actually set up.

Romain (46:21): Oh, you were muted.

David (46:24): All right. So, it's more than just our friend the use case and the POCs, thinking about more structural things and saying this the we now have a jobs to be done drinking game going on, incidentally. All right. One more question. I think we have just a couple minutes left. So, question is, always a fun one, with third party cookies going away, how is your CDP going to handle anonymous data? Or just more broadly, how does the CDP factor into this third party cookie free world? Michael?

Romain (47:00): Michael, you want to start?

Michael (47:02): Yeah. I mean, our tags when we're talking about ingesting web data, we're always deployed in first party environments, so third party cookies going away impacts some downstream integration. So, no more cookie syncing, but that was never really a big part of our offering. I mean, so much of what we do and the vision that we've tried to bring to the market is to help brands modernize their data infrastructure. And so, getting them out of this legacy paradigm where you have things like pixels and cookies and the degraded user experiences, and creating an abstracted process where you can move as much of that server side as possible.

Michael (47:53): So for us, the impact is minimal, if at all.

Romain (48:02): Yeah, I agree with this. Actually, CDPs probably benefit from this because we handle first party data more than anything else. For us, web tracking is a part of what we store and obviously, product data comes from the front end and the back end, so you also have server side data. You have a very important aspect of the data that lives in the other side services. Every single one of our customers relies on more than just the web tracking data. And I do believe that I mean, it's hard to rely today on third party data. There's been so many bad pattens, over time, there's a trust issue emerging. People are demanding that and that's why we see the market going into the direction of avoiding it. For CDPs, it's actually not very much of a concern. I mean, we're very much focused on that core first party company-owned data, so in the end, it doesn't make any difference.

David (49:15): Okay. All right, so we are out of time and so on that cheerful note, let me thank both of you. Let me thank the audience. Thanks for joining us. If you have other questions, get in touch with Hull and mParticle and they will be glad to answer. And then everybody say goodbye.

Romain (49:32): Thank you, everyone. It was great.

Michael (49:35): Thanks.

Abril (49:36): Bye. Thank you everyone. Have a great day.