A Customer Data Platform ingests customer events and attributes from every source a brand operates (storefront, app, email and SMS, support, POS, ad-platform callbacks, subscription engine), resolves them to a persistent customer identity, and exposes the unified profile and segmented audiences to activation tools. The substrate is first-party data. Identity resolution — stitching anonymous sessions to known customers, tying cross-device behavior to one profile, attaching post-purchase events back to the acquisition source — is the load-bearing job. Without it, a CDP is a data warehouse with a marketing skin.
Two architectural patterns dominate the category. A packaged CDP (Segment, mParticle, Klaviyo’s CDP, Tealium) is a SaaS app the brand pipes events into; it owns the profile store and ships activation connectors. A composable CDP (Hightouch, Census, RudderStack reverse-ETL on Snowflake, BigQuery, or Databricks) treats the warehouse as the system of record and bolts the activation layer on top. Both claim the same outcome. The trade-offs are data-team capacity, vendor lock-in on the profile schema, and how much modeling the brand wants to own.
A CDP is not an ESP; it feeds the ESP rather than sending the email. It is not a data warehouse, though a composable CDP lives on top of one. It is not a mobile measurement partner, which solves a narrower problem on app installs and post-install events. And it is not a substitute for a measurement strategy: the unified profile feeds attribution, it does not replace the work of choosing what to measure.
The common failure mode is installing a CDP without a clear use case — which audiences, which destinations, what success metric. The result is a costly identity-resolution layer nobody queries. What separates a CDP that earns its cost is whether named use cases are wired to activation destinations on day one.