Where does a CDP sit in a typical enterprise infrastructure?

David Spitz:  Today we're talking with Justin McManus about the question of where does a CDP sit in the architecture of a large brand already operating with multiple customer level databases. Marketers of course use a variety of systems to design, orchestrate, and measure customer experiences. Many of these systems manage customer level data of one sort or another, and many still offer a suite of applications or integrations with other platforms to deliver multichannel campaigns. At the same time, enterprise architects at many of the world's most sophisticated companies who generally hate the idea of multiple systems performing duplicative jobs. They're gravitating towards this notion of CDPs as filling a critical missing role in their stacks. Why is that, Justin?

Justin McManus: That's a great yet tough question because every client varies. David, we don't replace our architecture. We accelerate their enterprise architecture roadmap. We actually recommend building your enterprise architecture with mParticle or a CDP in mind. What I'll do is I'll bring it across three areas:

1. Governance
2. Legacy data warehouse augmentation
3. Agility

First, let's talk about governance.

The typical marketing stack is composed of dozens of discreet components. We provide a layer of integration governance around customer record, across all these systems, through that is a deep level of security really built from day one and from the ground up, you know, tactics like ensuring data is encrypted at rest and in transfer sdks, how certificate pinning to ensure there's no picking up of that raw data as it crosses systems, and of course having a really elegant, easy user interface that lets you really control and toggle which various user identities and sensitive user information and behavioral data gets sent and controlled to each of those different systems.

Secondly, CDPS are useful for legacy data warehouse augmentation. Many systems of record are just a record, right? They serve as a great data source for the CDP and some brands really choose to update their enterprise data warehouse with information from their CDP on a regular basis to feed enterprise level analytics. We ensure that the customer profile data, all those transactional events and those attributes are available in as needed for realtime interactions across all those different systems.

Finally, CDPs can make infrastructure more agile.  Enterprise architecture is always changing, right? There's always internal projects, there's always new requests and demands from marketers as they try to keep up with consumer demand. Having a customer data platform really offers up that agility layer because we provide a standardized set of is for engineering teams to build into internal systems and we provide a set of turnkey integrations that let marketers pick and choose the best of breed tools that they want to use to really acquire, analyze, understand, and retain their user base.

David Spitz:   I realize you said every customer is different, but can you give us an example of a reference client architecture?

Justin McManus:   Yeah, absolutely. So what we're looking at here is an example of a client architecture. Well, you can see here is we've instrumented our SDKs across various platforms like native mobile and desktop, and we're collecting their first party directly from their various properties.

Justin McManus:  We're collecting sessions, user-level data; marketing identity such as email cookies, IDFAs , cell phone numbers, and we're building a centralized user profile off of that. They've also hooked up a feed from their call center, which basically allows us to understand how users are engaging with them from an offline perspective. Are users happy, satisfied, do they have open tickets? That's all data. That's incredibly important for marketers to be able to engage with them on. For example, if a user's having a bad experience and they're an upset customer, there's really no point in trying to engage with them through push email or advertising so we can save them some serious amount of expenditure through that approach. You're also seeing a notion of custom rules which allows engineering teams to perform real-time customization, as their data is being collected and sent into mParticle. Real-time data customization can include simple things like cleaning up event names or doing lookups against other systems of record pulling in the machine-learning scores.

Justin McManus: All great examples of custom rules that our customers are building. You can also see that we're ingesting data from a Kafka feed. We're finding that many customers have built out enterprise event buses or collection pipelines and they're sending that data to us in real time, server-to-server, from those various feeds, like a Kafka feed. On the right hand side, you're seeing all the ways that we activate data across marketing automation channels, retargeting platforms like Facebook, Instagram, and DoubleClick, and, of course, sending it out to predictive models and analytics solutions. So you can effectively see that we're sitting in nicely right in the heart of their architecture and we're doing a round trip approach where we're collecting data in real time. We're activating it into different channels, but we're also ingesting it back into mParticle and helping them really optimize their entire marketing analytics solution.