Choosing the right Customer Data Platform (CDP) by understanding the history of the industry

If you’ve ever tried to evaluate a Customer Data Platform (CDP) and walked away more confused than when you started: you’re not alone.

And no, it’s not because you "don’t get data".

It’s because the industry is a swirling heap of overlapping tools, inflated claims and diagrams that make everything look magical and inevitable. The reality isn’t quite so clean.

Most vendors don’t lie.

They just don’t clarify.

And that’s a bigger problem than people admit.

I’ve been in this space for over a decade. I helped build Vero, one of the first messaging platforms that uses customer activity data in a meaningful way.

In this post I want to share the history of the development of Customer Data Platforms to help you understand what features solve which problems and bring clarity to what you really need.

Rewind: event tracking breaks through

Let’s go back to 2009.

That’s when tools like Mixpanel started doing something revolutionary—tracking what users actually did, not just what they told you in a form. This was the birth of event tracking: clicks, signups, purchases, even scrolls—all streaming in real time.

By 2012, we launched Vero with a bold idea: if you could use that event stream for messaging, you could deliver personalized, behavior-based communication at scale.

It worked. Really well.

Suddenly, every tool needed the same data

By 2012, the marketing stack was exploding.

Analytics tools. Email platforms. In-app messaging. Support tools. CRM systems. All of these tools were now more powerful, using the same event-driven behavioral data—and every one of them needed you to install their separate SDK.

Things got complicated, fast. Teams were managing customer data like they were duct-taping pipes in a leaky basement.

Enter: the CDP.

The CDP was born of this pain

The original idea behind the Customer Data Platform was simple: one SDK.

One clean pipeline. One unified customer profile that all your tools could share. Segment led the charge. Instead of juggling ten different SDK integrations on your website or in your mobile application, you installed one. Events were tracked once from this SDK to Segment and then forwarded to all of the other marketing tools in your stack.

Data consistency improved. Data accuracy improved.

These things were a real boon for both marketing and engineering teams.

On top of this, CDPs made it easier to add and swap tools in your marketing stack.

Adding missing data with Extract, Transform and Load (ETL)

Just as the CDP category was peaking, something else was starting to peak too: the data warehouse.

Amazon AWS Redshift, Snowflake, Google BigQuery had all made it super affordable and achievable to store almost unlimited data in your own, private database.

But data tracking doesn’t stop at customer interactions captured on-site or in-app. There’s a wealth of information in other business tools. A classic example is your payment gateway (Stripe, Adyen, etc.). Capturing data from platforms like Stripe wasn’t covered by the first iteration of CDPs.

This meant a wealth of valuable data was missing from the tools in your marketing stack.

ETL tools solved this problem. Companies like Fivetran pull data from platforms like Stripe into your central central data warehouse, whether that be Snowflake or BigQuery.

Initially the need for ETL was driven by for Business Intelligence (BI) use cases. But, as data in the warehouse became more-and-more reliable and larger, it became clear it wasn’t simply useful for reporting: data warehouses had become a company’s source of truth.

Enter: reverse ETL (rETL)

Another acronym!

If ETL tools let companies pull data from the likes of Stripe, Zendesk, etc. into your data warehouse then reverse ETL—tools like Hightouch and Census—pull data from your warehouse and push it to the products in your marketing stack, like Vero, Amplitude, Zendesk, etc.

When reverse ETL tools first launched, people said "CDPs are dead". The thinking was that you could buy an ETL tool + a data warehouse + a reverse ETL tool and fully replace CDPs like Segment.

But CDPs weren’t dead…the stack was just shifting.

The great vendor merge: everyone becomes a CDP

Enter the current era:

• Analytics tools added activation features.
• Email marketing tools added CDP-style data layers.
• Reverse ETL rebranded as the "composable CDP".

…and everyone started building features from everyone else’s platform!

The result? Massive feature overlap and massive confusion.

Everything claims they’re a CDP. But it’s not clear who actually is and isn’t.

Worse—vendors often lean into the complexity. "Activation layer." "Composable stack." "Zero-copy architecture."

Great buzz. Not great for clarity when buying.

Bringing clarity to the core components

At the end of the day these are the things a Customer Data Platform needs to do to, well, be a CDP:

1. Collect on-site/in-app data. Capture first-party data about what your customers are doing.
2. Load data from software and platforms in your stack. Pull data from platforms that you don’t control, such as Stripe and SaaS products you use in your organisation.
3. Stitch and merge all of these data sources. Tie all of the above data together cleanly and merge profiles so you have something close to a "single view" of each user and customer.
4. Send the clean, organised data to the software and platforms in your stack. Critically, send and activate this clean data to the tools in your marketing stack.

These are the four, fundamental components of a CDP. CDPs can solve these in different ways. Some, like Hightouch, store all of the data collected from your site and apps in your data warehouse, stitching and merging inside your warehouse before loading this data to tools in your stack.

Others, like the original Segment, store this data in their data cloud, storing and stitching data on their side, before sending it downstream to your stack.

These tools have strengths and weaknesses and various features to support this core functionality. But the first thing to understand is the fundamentals you need and to make sure you’re buying a tool that has them.

Here’s the part not one wants to admit

Most marketers don’t know enough about data infrastructure to evaluate these tools properly.

And they shouldn’t have to.

Marketing teams are experts in storytelling, segmentation, and strategy—not schema design, identity resolution, and API throttling.

When you’re buying a CDP (or something CDP-adjacent), you’re being asked to make decisions that touch all of those things. And the marketing sites don’t help. They show you sleek UIs and smart workflows, but they gloss over the fine print:

• You’ll need engineering help.
• "Real-time" isn’t always real.
• Some features only work inside their ecosystem.
• Identity resolution is magic until it breaks—and then it’s your fault.

Ask these questions first

Before you buy a CDP—or a messaging tool, or a reverse ETL platform—ask:

Do we know what data we need to power our key workflows?

Are our teams aligned on how that data is defined and structured?

Do we have a clear sense of what’s real-time vs. batch, what’s system of record vs. reference?

Who owns data quality? Who owns activation?

Plus, perhaps most importantly, get all of the stakeholders involved early. Work closely with engineers and data engineers to build out a clear picture of what you need and sense-check what you’re hearing from vendors.

It’s time to get aligned!

Final thoughts

At Vero, we’re pro-CDP. We work closely with tools like Segment, Rudderstack, Hightouch, Census, Snowplow and more.

But we’re also pro-clarity.

We’ve seen marketing teams buy the wrong tools and burn hundreds of hours integrating features they didn’t need yet. We’ve seen marketing teams succeed with less.

But we’ve also seen teams succeed wonderfully with the right stack. Your stack matters.

Don’t get sold. Get educated.

If you ever want help making sense of it all—we’re here for that. Get in touch!