Why should developers care about Customer Data Platforms?

Thanks so much for signing up for An introduction to Customer Data Platforms for Engineers. Welcome to part one of the series. To start off, let’s zoom out a little bit. 

There are many instances in our work (and lives) in which we do something repeatedly without considering if there’s another way. In our habits, we make the implicit assumption that things can only be done the way we are doing them. 

This brings to mind the black swan theory, popularized by Nassim Nicholas Taleb, describes an event or finding that was unexpected but when looked at in hindsight reveals assumptions and has a significant impact on the future (swans were assumed for centuries to be all white, until the first European settlers arrived in Western Australia and discovered black swans everywhere, debunking the entire theory).

In the world of engineering, we often hold assumptions in the way in which we build things and construct systems. Occasionally, a new insight or innovation comes along that exposes one of those assumptions and transforms the way we do things. 

An example of this is how engineering teams provide marketing and product teams with customer data. As the martech landscape has rapidly evolved over the past few years, growth teams have taken advantage of this development by getting their hands on the best-in-breed tools across the ecosystem and using them to support powerful use cases such as real-time messaging, advanced analytics, machine learning, and more. Every tool, however, is powered by customer data. Each requires a new SDK implementation, ongoing library updates, and introduces third-party dependencies. Dealing with these tasks falls on the plate of engineers, who are often called away from working on customer-facing features to complete them.

Engineering will always need to support internal data requests, as the reality is that not everyone can understand and update your codebase (nor should they). But within this workflow is an implicit assumption that causes great efficiency – every downstream vendor used by marketing and product needs to be implemented directly into your codebase to be used to its full potential.

Customer Data Platforms have arrived to expose that assumption. CDPs provide a single point of collection for all of your customer data (either through SDK implementation or API connection). Once that data is collected into the CDP, it’s run through data quality validation and data governance rules before being accessed by marketing and product stakeholders so that they can choose which tools and systems to send it to. mParticle, for example, has an ecosystem of 300+ server-side integrations that growth teams can use to set up data forwarding within the UI.

You’re able not just to spend less time shipping data to marketing stakeholders, but also to eliminate excess third-party libraries from your code.

If you’re interested in seeing how this actually works with mParticle, you can check out our developer docs here.

We hope this was a valuable introduction to CDPs and their relevance to techncial teams. Check out the next installment in this series on how to escape from vendor integration hell.