Under the hood of a Customer Data Platform (CDP)

First, just a fair warning that this piece goes into a bit of detail of what goes under the hood - and gets a bit jargon-y - about how we work with data and how we built Meiro data layer the CDP runs on.

Integrations, Integrations, Integrations

Meiro CDP can’t exist without the Meiro Integrations layer and it’s worth noting upfront . A CDP is the last-mile activation piece of an extensive set of processes - all based on data unification. We come from ETL/integrations backgrounds, and our focus is two-fold:

• Building simple(ish) integrations with complex programs
• Tagging all of that data so it makes sense and is usable

All of the components and workspaces work to one goal - to load the data into our customer data model. We designed our model to hold every customer attribute (social profile identifiers, location, touchpoints on customer care, etc.). As well as a timeline view of touchpoints - cross-device, online/offline, you name it, it’s all there. Our model both holds and standardizes everything, so any application - IT, CRM, marketing, data analysis, and science teams, etc. - can access the data in the same way.

Under the Hood of a CDP

Every component in Meiro is a Docker container - basically, a standalone “black box” that can be written in any language, using any SDK from any data source, and communicates with Meiro Integration’s core using a simple data interface. This makes creating components (data source, processor, data destination) both easy and fast, in any language - and anyone can do it. Bring the tool to the data, not the data to the tool.

See the Flow, Be the Flow

Institutional memory is great, but it’s good to have notes. I’ve been on the receiving end of bad processes, and it’s not great. Here’s an example that I suspect is all-too-familiar: Your team of data engineers and analysts are tasked with loading data from Google Adwords. They get a server (possibly a virtual one), write a script, ask an API for some data, and then store it into some database. This script lives in the server and in the minds of the programmers who built it and nowhere else. This had to end, so we built a mapping system that shows all data flows - visually. I want to see where my data is coming from and where it’s going, and we all assumed more people wanted that too. So, in our scenario, you use a component for getting the data from AdWords, use an SQL script to process it, then some pivot engine to deliver the data to PowerBI for visualization - and that’s just another workspace.

A CDP Has to be Easy to Use

All that super-complicated and interesting data science work doesn’t mean too much if the end result is the status quo. The reason we got together to create Meiro was exactly this - there’s a ton of data just sitting there, and marketing people just can’t use it. And, if they can, they can’t use it fast enough and without using resources from the IT team. It’s a huge inefficiency, and we’ve seen it over and over again. So, we sketched, drew, erased, wireframed, deleted, and then did all that a few more times. We needed the end-user to be able to look at the thing and know what to do to get the data they want. So, we made it as simple as we good - WYSIWYG. Want an audience of “existing customers in London who read your last email and have an NPS score above 7”? It’s all there, in nice little containers, and the files have normal naming conventions.

Have an Idea, Got a question?

We’re #datacurious, and are always looking to exchange ideas and solve problems. Get in touch via social or email v@meiro.io.