What Is a Customer Data Platform (CDP)

The CDP Opportunity

I’m going to explain how customer data platforms (CDPs) work later. But first I want to define the opportunity a CDP represents. CDPs let you put all your data in one place and feed it to all your tools. That means you can:

• Move data back upstream to tools that handle previous stages of the cycle. This setup gives you feedback on each action you take, and let’s data from one tool inform actions everywhere else in the stack.
• Automate this process and you’re getting updated customer data in real time.
• Each of these is huge, both together can be a  totally new ballgame.

Let’s look at an example: a prospect visits multiple pages of your website on the same day.

Whether this visitor is an inbound sales lead or a marketing lead or just someone who got lost on the way to your press pack, the question is, what do you do about them? If you’re like most businesses, you’ll fork that person over onto a high-touch marketing flow and maybe have a live chat option. Or maybe sales will jump on them as an inbound lead.

The problem with this approach is that the decision as to which action to take often depends on:

• Which tools are used to collect the data.
• Who owns those tools.

If your marketing department is in charge of watching what happens on your website, with a marketing-friendly tool like CrazyEgg, they’ll decide; if sales runs the show, using something like LeadFeeder, they’ll count this person as an inbound lead and start selling.

And if there’s no clarity and both departments have some data and some say, then both departments might act without knowing what the other is doing.

That’s a recipe for a hot mess from the customer viewpoint. If customers hate handoffs—which they do—how much more do they hate mixed messages and fumbled catches? Not the best way to develop a profitable customer relationship.

I’ve watched this happen, with sales and marketing both working hard side by side to reach and convert the same customer. It wasn’t even an alignment issue—in the case I’m thinking of, there was no way to feed data along the process to different departments, especially in real time.

So there was no way to stop SDRs contacting a customer who had already made a million-dollar order through the website and asking when would be a good time to talk about making their first order.

Instead, how about we meet that prospective customer with targeted messaging that’s based on what they’ve previously shown they’re interested in, augmented by the data we have on previous customers who matched that prospect’s most crucial characteristics?

How about instead of triggering individual departments to act based on behavioral triggers alone, we combine everything—behavioral, geographic, demographic, and technographic data—connect it to the actual person and respond based on all that?

This has doubled ROI for companies. We’ve watched it happen with our clients, and it’s not dependent on location or vertical or anything else but CDP selection, stack taxonomy, and implementation.

A CDP isn’t another tool in the stack—it’s an opportunity to finally realize the potential of data-driven marketing automation and to connect all of your tools’ data together.

Double-Edged Sword: The CDP Opportunity Downside

A word of caution: CDPs create exponential changes both ways. They offer a massive opportunity and a massive opportunity to screw up.

CDPs let you automate complex operations using rules and logic. That’s great if your facts are straight, and catastrophic if they’re not.

Back in 1897, the State of Indiana came close to passing a law saying that Pi was 4. It’s actually 3.14159…, but 4 is simpler—until you start trying to build things, especially round things.

Indiana stopped short of trying to rewrite the laws of nature in the state legislature, but it illustrates the point: if your facts are all true and your logic is impeccable, the result will be exponentially better.

If your facts are false and your logic is impeccable, the result will be an absolutely intractable, exponentially-worse-than-ever-before disaster. Garbage In, Garbage Out, no matter how good the process or the data.

That’s the opportunity a customer data platform gives you: the chance to straighten out your customer data once and for all and use it to build an automated, super-effective marketing and sales machine, and the chance to screw it up so badly that you’re gonna want to nuke it from orbit and never speak of it again.

CDPs run on data, and they excel at making sense of unstructured data and getting marketing tools to talk to each other. But underneath it all, they depend, not on structured data, but on data structure: a taxonomy of data that’s consistent across all your tools. Or as we like to say, “stack taxonomy.”

We’ve had Segment, a CDP we use often, leap to our assistance during a problematic install and fix a technical bug with us, but however good a tool’s helpdesk is, they can’t help you with your data taxonomy.

That’s something that has to be tailored for your business and implemented from the ground up across your whole marketing technology stack, preferably by a team with the experience to do it right the first time.

We’ll talk about how to implement a CDP properly further down. Let’s look at the landscape first, then get into how to select a CDP that fits with what you need.

How to Build a Customer Data Platform: 3 CDP Types & How They Work

You can split CDPs into three broad groups:

• CDIs that pipe data from one tool to another but don’t retain it
• Standalone traditional CDPs that store and process data as well as communicate with other tools
• Orchestrating CDPs that do all that, plus messaging, prediction, and other functions

A lot of the time, these lines are blurry and getting more so as more players enter the CDP market.

CDI: Pipe data

Source

Customer data infrastructure tools like Segment and MetaRouter move data around inside your stack without doing any other work on it or storing it themselves. They can move data in real time. (A CDI does host your data, but it doesn’t give you access to it on the tool itself.)

We’re going to talk about Segment because it’s the best-known, a pioneer in the space, and comes with the most out-of-the-box integrations.

One of the things I love most about Segment is that the basic process of installation is fast and simple; notice that I said the basic process. How you implement a tool or software matters a lot, which is why we spent a decade getting good at customer data integrations like Segment. Segment hasn’t been around for a decade yet but we cut our teeth on integrations in some of the original people-centric, event-based analytics tools like Kissmetrics and Mixpanel.

But to kickstart the process, all you have to do is install Segment on your site and server and write a single line of code that you then send to Segment. Segment then takes that code, “translates” it as necessary, and sends it on to all your other applications. This means marketers don’t have to lean on developers to make every little change, which means you can move now, not when your job gets to the top of development’s to-do list.

Let me explain a little further. When you work with marketing tools, you will need to add their code to your site or server. When you add this code, it is going to be in that tool’s “language,” also known as syntax.

This means if you want to track conversions to Facebook, you have to write the conversion tracking in Facebook’s syntax (code). If you want to track conversion in Google Ads, you have to write the code in their Google Ads’ language/syntax.

Simply put, if you want Google Analytics, Facebook, Google Ads, Adroll, Marketo, Drift, Hotjar, and Hellobar to all work properly and track what happens on the site, you have to add all their code and their tracking events, in their language, to your site.

This also means if you want to track an action the user does, like submitting a form or signing up, you will have to write code in the language/syntax of Google Analytics, Facebook, Google Ads, Adroll, Marketo, Drift, Hotjar, and Hellobar. This would mean your developer has to write the tracking for that action eight times to make it work with each tool.

This is one of the age-old reasons why developers hate marketing, and sometimes marketers. We peskily ask them to do repetitive tasks that suck! Just so we can have data points about marketing campaigns and customer experience in real time.

But this is how Segment is different, and how it revolutionized the space. With Segment, you only have to install their tracking script, and then write one language or syntax, and they will translate it downstream into all the other tools. They do all the heavy lifting of translating the data (code) so you only have to write for them and then they deliver it in the other tools’ languages.

We like to call this the Rosetta Stone of APIs.

To take this further, they also allow you to make other tools sources of data, too. Suppose you want to analyze some data you stored in Zendesk and mix that in with other data you collect from your site. Say, for instance, you want to see what issues your free trial users are generating and improve conversions from that to paid accounts.

Segment lets you just plug straight into Zendesk, with no wait period or setup. It connects with Zendesk out of the box using a “source,” Segment’s term for ready-build integrations. Which is great.

But once you do that, you then can pipe that data out of Zendesk, through Segment and into a data warehouse platform such as AWS Redshift to analyze it with Looker.

The big advantage of this approach is that you can plug Segment, or a tool like it, into the stack you already have. No need to rebuild from the ground up. Think of CDIs as “Zapier for data”—it’s one API to bring everything together.

CDP: Store and analyze data

Source

A traditional CDP will pipe data between tools and host it (like a CDI), but it will also provide customer data visibility and analytics. You’re not just piping data around, you’re creating a new repository for it which will be your source of truth for the whole organization. (This can be an issue if you lose access to that tool, so watch out for that.)

Lytics is a major player in the field and we often recommend them to clients who we feel could take advantage of a customer data platform benefits, so we’ll use them as an example.

Suppose you have the same issue as mentioned in the previous section—you want to collect data by feeding Zendesk data into your analytics. You’d choose Lytics’ ready-made Zendesk integration from their integrations page, just like Segment’s recipe.

Source

Superficially, the integration process is similar. But under the hood, something very different is happening. By using a CDP like Lytics, you wouldn’t have to then pipe that data over to Redshift to better understand the data Instead, analysis can take place inside Lytics itself.

Lytics comes with four types of data analysis ready to go right out of the box: behavioral scores, content affinity, discovery insights, and delivery optimization. Taking behavioral scores as an example, Lytics lets you get a lot more granular than a simple “did they/didn’t they” approach, measuring and analyzing things like frequency and recency, momentum and intensity, to arrive at a more accurate view of what that customer is really doing and why.

Orchestrating CDP: Plan and execute right from CDP

Source

Orchestrating CDPs do what standalone CDPs do, then add some marketing automation functionality on top. (In fact, Lytics does this too; these divisions are getting less clear-cut as the CDP market matures.)

BlueShift, a well-known orchestrating CDP, will create a single customer view. It will also apply its proprietary AI to predictive modeling and customer journey orchestration. The goal for BlueShift is to be more than a source of truth. Instead, it’s the center of your marketing stack, with every other tool relegated to feeding data or receiving commands.

In addition to everything that a standalone CDP will do, orchestrating CDPs will let you build and execute campaigns from inside the tool. You can send emails, SMS, push notifications, or banner ads. Not to mention send API calls to just about anything to enable and action somewhere else.

There’s an email campaign builder inside the tool that lets you build HTML emails from templates, for instance.

Source

More importantly, you can construct campaigns that match your customer journey, as revealed by a tool like this—right inside the tool itself. 

This kind of CDP is among the riskier to implement because it involves a lot more automation. Any kind of predictive modeling is an extrapolation, through logic, from the facts at hand. So the facts better be right and the logic better be tight.

What Kinds of Data Can a Customer Data Infrastructure Handle?

What can you feed into a CDP? Basically everything. 

Source

Every tool in your stack can feed into a modern customer data platform, and receive data back. That includes:

• Ad platforms
• Ad networks
• Analytics and analytics platforms
• CRM tools
• Marketing automation tools
• DSPs
• Lead capture forms
• Offline sources
• Websites
• Mobile apps
• Web Apps
• Totally raw data
• How raw is totally raw? Crucially, CDPs don’t need data to be organized a certain way going in. If you want that data to be usable, though, and not have nightmares later, you need to organize it from the start.

The organization of data that underlies customer data platform  performance isn’t the same as a rigid spreadsheet that you upload to a CRM. Instead, it’s about building a structure of data recording and nomenclature that’s clear, consistent, and action-focused across your whole stack. This, not installing a program or choosing between two different CDPs, is where most implementations fall down.

Typically, a CDP Handles Data Differently than Other Tools

They accept it differently…

Where marketing tools can read each others’ data, they usually do it with an API. If there isn’t a predefined API name, then the data gets dropped. Think of an API like a communication pipe. When you connect Ebsta to Salesforce using Salesforce’s plug-anything-in-anywhere, Swiss Army knife of an API, it takes the data coming from Ebsta and matches the name to a field name in Salesforce to obey Salesforce’s data taxonomy. If Salesforce does not have a field for the data to go to, or it has not yet been mapped to a field, it simply does not collect the data.

CDPs don’t work like that (their APIs might, but that’s a slightly different story). Instead, they accept all the data that goes in and create new fields on the fly. It’s not in “Salesforce-ish” or “Ebsta-ish” anymore, it’s just another bit of data we know about that user. CDPs can accept any data that is based on a customer identity and attach events, demographics, company data, and more to those customer IDs.

It’s pretty different from a CRM. In CRMs, you have fields for all kinds of data, but no field = no collected data. If there’s no pre-arranged place for that data to go, it doesn’t exist in the CRM’s eyes. This is the same for most marketing automation, email service providers, or really any tool that is field-based.

In CDPs, that doesn’t happen: whatever data you have, whatever form it’s in, you can just pipe it straight into your CPD.

This is the crucial step that makes CDPs able to become central to marketing stacks. Other tools are built around short-term, department-specific tactical requirements. Sales tools track sales; email tools track emails; social tools track social. CDPs track everything about your customers.

…they store it differently…

Most CDPs use a data structure called a non-relational database. This is a bit counter-intuitive and very technical, so we will keep it brief. But it matters because it explains how CDPs are able to do what they do.

A relational database is the kind of database we’re all used to seeing. If you’ve ever used Sheets or Excel, you’ve made a relational database: two axes that relate to each other such that you can find any value from its coordinates. The trouble with this kind of database is that it forces the same relationship between the values that are stored in it: it’s a box full of boxes. Organized, yes, but rigid. If there is not a field, or column for that field to create a relation, then that data just won’t be stored.

A non-relational database holds and organizes its data fundamentally differently. It first holds the data and then arranges relations between it, so being accepted into this database doesn’t rely on fitting its structure.

Take the example of the weather. Suppose you have dates and whether it rained or not as your values. In a relational database, you can easily and quickly mark off that it’s the 23rd and it didn’t rain. But if it snowed, you have nowhere to put that information. In a non-relational database, you can record that it’s the 23rd and information such as that there  was some sleet and thick fog: a more accurate description, but much harder to build a pre-existing structure for.

In CDPs, data like customer behavior and even demographics won’t always fit your pre-existing ideas, so it doesn’t always fit the pre-existing structures you build to house it either. Building the tool around non-relational databases means data can be added first, and sorted later.

… and they transfer it differently

As well as being able to receive information from all your tools, without needing a ready-made custom field to drop it into, customer data platforms have another major advantage over other martech tools: they handle data transfer programmatically.

Rather than handing all data to one tool, or never passing data to a certain tool, CDPs have complex logic—not just yes and no, but If This Then That (ITTT). For instance, if a CDP receives some revenue data, it can make a decision based on preset rules about which tools it will share that data with.

What Makes a CDP Different from CRM, DMP, or Marketing Automation Tools?

You can break down the tools available to manage customer data into Customer Relationship Management tools (CRM), Customer Data Platforms (CDP), and Data Management Platforms (DMPs). Some marketers are leaning pretty hard on marketing automation tools too, sometimes with a CDI in the background, sometimes not. (I have seen a Frankenstack or two in my time.)

What makes all these types of applications different from each other? First up, here’s the quick-and-dirty checklist:

Holistic customer data: Does the platform combine data from all available sources?

Lasting customer profiles: Does the platform retain individual customer data for a long or discretionary (until you delete it) period of time?

Works out of the box: Does the program work without any initial configuration or do you need to set it up or adapt it?

Real-time capability: Does data in the platform get updated in real-time or does it take time to percolate through the system?

Open platform: Is getting data into the system simple? Is getting it out again simple?

Cross-channel personalization: Does the tool allow for personalization across multiple customer touchpoints or journey stages?

Identity resolution: Does the platform let you connect established IDs with new data from new sources?

Main data types: What types of data does the platform process?

Insight and analysis: Does the platform return reports and insights on groups or cohorts, or on individual customers?

Funnel/journey stage: Where in the customer process is the platform functional and useful?

CDP (Customer Data Platform) vs DMP (Data Management Platform)

A Data Management Platform (DMP) gathers, classifies, and categorizes audience, campaign and behavioral data from across your stack. It lets you target audiences more effectively in ad campaigns, provides a central storage location for cookie IDs, and makes programmatic ad buying easier and more effective.

At first glance, it looks like this is kind of similar to what a CDP does, except with a clear top-of-funnel focus. But the really important difference about them is how they treat the customer.

DMPs focus on collecting marketing data for ad targeting, meaning they’re identifying responders to ads based on cookies or behavioral data. They base their data taxonomy on audiences using behavioral data.

CDPs focus on the individual customer and base their data taxonomy on customer IDs: it’s not “people we’re tracking with this cookie,” it’s “John Smith, CFO of ProductTronic.”

So how’s that different from what a CRM does?

CDP vs CRM (Customer Relationship Management)

Salesforce defines CRM as “technology for managing all your company’s relationships and interactions with customers and potential customers.” That sounds a lot like CDP, so what’s the difference?

Partly it’s about who owns it. Sales owns CRM, marketers own CDP. And partly it’s about what you’re tracking. Customer data platforms track behaviors, CRM tracks interactions. But mostly it’s about the types of data they support.

CRMs take in data about customers, including transactions and touches, and get more data from marketing tools and third-party data providers. But, and it’s a big but, a CRM imposes rigid data structures on the information it takes in. If there’s no field for the data type, a CRM is blind to it. (This rigidity is one of the things that reps dislike about CRMs: everything is either compulsory or impossible and data entry is a time suck.)

Source

A CRM also doesn’t match data across channels or pick up offline data.

By contrast, CDPs are omnivorous and insatiable: they’ll take any data that’s available, as much of it as possible, and they don’t mind what form it comes in. It can operate online and offline. CDPs can automatically collect and store data on things like what content a buyer prefers, identify the same person even if they’re using different emails, and tie data from across the funnel to one persistent customer identity.

There’s no conflict between a CRM and a CDP—it’s not a question of choosing one over the other. Instead, a CRM should be one of the tools that feeds data to and from your CDP.

Who Needs a Customer Data Platform?

CDPs don’t come cheap. Segment runs around $1,200 to $200k a year, Lytics about $60k to $300k. So the first question you have to ask is whether it’s worth the price tag. In most cases, the reduction in developer hours doing integrations for marketing will allow the CDP to pay for itself.

Personally, I think any business can benefit from a more structured approach to data, and you don’t need to be dropping this kind of money on tools to build an effective data taxonomy.

But smaller businesses should focus on developing best-practice sales and marketing processes that fit their income stream. While a Customer Data Platform can support these smaller businesses and will help save them time if they are not a tech company building software the actual integration phase may be just too expensive.

You can tell your company would benefit from a CDP if you’re at the stage where you want to consolidate all your customer data into a single place, or if you’re searching for a granular understanding of customer needs and you’re getting tired of creating new mandatory fields in your CRM. If you’re thinking of switching analytics or marketing vendors, that can be a good time to make the upgrade to a CDP, too.

Beyond that, the best answer I can give is that, sooner or later, everyone will need one. The effects that we’ve seen properly-implemented CDPs deliver for our clients has been dramatic enough to convince me that these tools will go from a competitive advantage to compulsory pretty quickly. If you’re looking to better understand the direction marketing is heading, this is the answer.

The choices you have to make are which you’ll use and where in your business’ growth journey you’ll shop for and start using one.

How to Implement a Customer Data Infrastructure (or CDP)

The best way to implement a CDP is with the guidance of someone who’s done it a bunch of times before. This is where I’m going to insert a legit plug: we have done this 100+ times for clients in diverse verticals, and we’re good at it.

If you come to us, we’ll look at how your business operates and handles its data day-to-day and strategically, including going over your stack and asking a bunch of questions. Then we’ll figure out what your needs are and how your stack already processes data. I often find that Segment is best for smaller businesses or ones with a less complex business model because you get so much CDP goodness with so little additional setup. But it’s a long way from being right for everyone.

If you’re implementing your CDP yourself, here’s where I would start:

Start focusing on data taxonomy early and seriously

CDPs can make sense of all the different “languages” your tools speak. But what it can’t do is make sense of a taxonomy where the same thing—say, email signups—is labeled differently in different tools. Your CDP has no way of knowing these are the same action, not a handful of different actions. The solution is to have business-wide, obsessively accurate nomenclature that’s the same across departments and tools. That way when you do implement your CDP, your data is ready.

Even that isn’t enough. Accuracy alone won’t give you the taxonomy you need to leverage a CDP instead of having it blow up in your face. This is an area where even the best cheat sheet is no substitute for experience and expertise, because when you’re building your whole stack on your CDP, and betting your CDP’s behavior on your data taxonomy… you really, really want your taxonomy to be right.

Decide how much control you want

More control and customization can be great or a liability, depending on how much time and how many resources you’re able to allocate to the task. CDP-lite solutions that offer a lot of ready-made tools out of the box can be up and running in just a few days, but be aware that they’re going to create your new business model in their image, to some extent. More custom-fit options will typically cost more and take longer. Dollars and time on the line tend to focus the mind on budget, but this is really a strategic decision about how you want your business to operate. If you can’t find an off-the-shelf Customer Data Platform that fits your business goals, I recommend doing some CDP tailoring to get a good fit.

Don’t act like it’s a marketing tool

…because it’s not. It’s a business tool. It needs the whole company on board—IT to help set it up and run it, sales to feed data back into it and get data in return, operations, and customer success, everyone. You can do everything from tracking potential customer behavior to analyzing the effectiveness of your customer support, all in real time. That means selling it internally on the basis of how it improves everyone’s lives.

Read the privacy statement

You’re piping a whole lot of data through a CDP. Check up on their security and privacy before you sign with one. This is about to become a huge issue across the SaaS space as the insecurity of a lot of APIs moves front and center. Get ahead of it and look for a CDP with genuinely respectable data privacy and security measures.

Conclusion

Claiming the benefits of a CDP means moving your business over to a model where data dictates actions, and your main job is managing the data. It’s exponentially more effective, but it calls for a new way of viewing business processes as well as paying for (and setting up) the tool itself.

Make that jump, though, and you’ll be in a position to build your whole business around your customers, meeting them wherever they are with messaging that you know will resonate. ROI will go up, conversions will go up, and sales and marketing will become friends. OK, maybe not. But doubling ROI sounds like something to shoot for in the meantime.