Customer Data Platforms explained: what they are, and packaged vs. composable

A Customer Data Platform collects customer data from every system you run, stitches the fragments belonging to the same person into a single persistent profile, and makes those profiles available to the tools that act on them.

That is the whole idea. The complexity is entirely in the execution, and the reason CDPs exist at all is that most organizations cannot answer a deceptively simple question: who is this customer, across everything we know about them?

Consider one ordinary customer. She browses your site on her phone without logging in. A week later she opens an email on her laptop and clicks through. She buys in store using a loyalty card. She contacts support from a different email address than the one she ordered with.

You now hold four records in four systems, all describing one person, none of them aware of each other. Your analytics counts four users. Your email tool sees a subscriber who apparently never purchased. Your ad platform pays to re-acquire someone who is already a customer. Your support agent has no idea she just spent nine hundred dollars.

Multiply by several million customers and a dozen brands, and you have the condition CDPs were invented to treat. Nothing here is a technology failure. It is the consequence of buying good tools independently over a decade.

The term is applied loosely enough to be nearly meaningless in vendor marketing. A useful working test is whether the system does all four of these things. Three out of four is a different category of product.

1. Ingestion from every source

Web and app behavior, transactions, CRM records, support tickets, email engagement, offline and point-of-sale data — both streaming and batch. A tool that only sees website behavior is a web analytics platform.

2. Identity resolution

The genuinely hard part, and the capability that most separates real CDPs from imitations. The system must decide which anonymous cookie belongs to which logged-in user, that two email addresses are one person, and that a loyalty card and a device identifier share an owner — deterministically where possible, probabilistically where not, and always with rules you can inspect and defend.

3. A persistent, unified profile

Not a report and not a query result: a durable record that survives, updates as new events arrive, and is available to other systems. Persistence is what distinguishes a profile from an analysis.

4. Activation to other systems

Profiles and audiences must flow out — to ad platforms, email and messaging tools, personalization engines, and customer service software. A CDP that cannot push data anywhere is a database. Activation is what makes it operational.

Most confusion in CDP projects comes from conflating it with adjacent systems.

The value is not the platform. It is what becomes possible once one profile exists.

• Suppression that actually works — you stop paying to advertise to people who already bought.
• Frequency capping across channels rather than within each one separately.
• Personalization grounded in the full relationship, not just the current session.
• Support agents who can see the customer's actual history.
• Marketing attribution that counts one person once.
• Consent honored consistently everywhere, because preference lives on the profile rather than in six systems.

Once a company accepts it needs a CDP, the next question arrives immediately and is much harder: buy a platform that does everything, or assemble one on top of the data warehouse you already own?

The industry has spent several years turning this into a religious argument. It isn't one. Both architectures work. They fail in different ways, cost money at different points, and demand different things from your team.

Strip away the marketing and the distinction is simple. In a packaged CDP, your customer data is copied into the vendor's system, where it is stored, resolved, segmented, and activated. In a composable CDP, the data stays in your warehouse, and a set of tools reads from it to do that work. Everything else — cost profile, governance implications, delivery speed, failure modes — follows from that one difference.

A packaged CDP is a single vendor product covering the whole chain: collection, identity resolution, profile storage, segmentation, and activation. You send it data, configure it in a user interface, and audiences flow out to your marketing tools.

Example platforms

• Adobe Real-Time CDP — deepest fit if you already run Adobe Experience Cloud; strong on real-time edge segmentation.
• Salesforce Data Cloud — the natural choice where Salesforce is the system of record for sales and service.
• Tealium AudienceStream — unusually strong on client-side and server-side collection; often chosen by teams wanting tag management and CDP from one vendor.
• Twilio Segment — the most developer-friendly collection layer, with the largest catalog of destination integrations.
• BlueConic — popular in publishing and mid-market retail; strong on first-party data and consent.
• Klaviyo — B2C and ecommerce focused, with messaging built in rather than bolted on.

What you get

• Speed. A competent team can be activating audiences in weeks, not quarters.
• One vendor to hold accountable when something breaks.
• Marketer-usable interfaces — segmentation without writing SQL.
• Identity resolution that works out of the box, without you designing the matching logic.
• Pre-built connectors to hundreds of marketing destinations.

What it costs you

• A second copy of your customer data, in someone else's system, with its own access controls and regulatory surface area.
• Pricing that usually scales with profile count or event volume — costs grow as you succeed.
• Real switching costs. Audience definitions, identity rules and integrations are expressed in the vendor's language.
• A ceiling on modeling. If the vendor's data model does not express your business, you work around it rather than change it.

A composable CDP is not a product. It is a pattern: use your existing cloud data warehouse as the storage and compute layer, then add specialized tools for the parts a warehouse does not do — identity resolution, audience building for non-technical users, and activation to marketing platforms.

The activation piece is usually called reverse ETL: reading a query result from the warehouse and syncing it into an operational tool like an ad platform or an email system.

Example platforms

• Hightouch — the best-known reverse ETL and composable CDP layer, with an audience builder aimed at marketers.
• Census — reverse ETL with strong data-quality and observability features.
• RudderStack — warehouse-native by design; covers collection as well as activation.
• GrowthLoop — audience building and orchestration directly on the warehouse.
• Simon Data — campaign orchestration on top of warehouse data.
• Amperity — identity resolution specialist, frequently used as the matching engine in an otherwise composable stack.

Underneath these sits the warehouse itself: Snowflake, Google BigQuery, Databricks, or Amazon Redshift. That is where the customer data actually lives, and it is the component you already pay for.

What you get

• One version of customer truth, governed once, in the warehouse you already secure and audit.
• No data duplication — a materially smaller privacy and compliance surface.
• Modeling freedom. If your business has an unusual customer structure, you model it exactly.
• Component-level replacement. Swap the activation tool without rebuilding identity resolution.
• Cost that tracks warehouse compute rather than profile count.

What it costs you

• You need a data team. This is not optional, and it is where most composable projects quietly fail.
• Identity resolution becomes your problem to design, build, and defend.
• Longer time to first value — months rather than weeks.
• Multiple vendors, and integration seams that belong to nobody but you.
• Real-time is harder. Warehouse-based activation is typically minutes, not milliseconds.

Treat the binary as a simplification with a shelf life. Packaged vendors have added warehouse-native modes that query your data in place rather than copying it — Adobe, Salesforce and ActionIQ all offer versions of this. Composable vendors have added packaged conveniences like hosted identity resolution and marketer-facing audience builders.

Most enterprise stacks we implement are hybrids: a warehouse as the governed core, a packaged tool for real-time edge use cases, and reverse ETL for everything batch. The useful question is not which camp you belong to; it is which component belongs where.

In practice the decision is usually settled by three questions, in this order.

1. 01Do you have a governed data warehouse and a data team who own it? If no, composable is a project you are not yet staffed to finish. Buy packaged.
2. 02Is your primary use case real-time — on-site personalization, in-session decisioning, cart abandonment within minutes? If yes, lean packaged, or plan a hybrid with a packaged real-time layer.
3. 03Is your customer model unusual — multi-brand, franchise, B2B2C, household-level, or heavily regulated? If yes, composable will fit your reality where a packaged data model will fight it.

The most expensive CDP mistake is not picking the wrong architecture. It is picking one and then not resourcing the work that architecture demands — governance and identity design for composable, or integration discipline and cost control for packaged.

And one closing caution that applies to both: a CDP will not fix bad data. It will make your bad data available everywhere, faster. Identity resolution amplifies whatever discipline already exists in your collection. Organizations that succeed almost always fix measurement, taxonomy, and governance first. The platform is the last step, not the first.