What a customer data platform actually is, when you need one versus when a well-architected data warehouse is sufficient, and how the composable CDP model changes the build vs buy calculus for enterprise marketing data.
The customer data platform (CDP) is one of the most misunderstood categories in enterprise software. Marketing vendors sell CDPs as the solution to data fragmentation, personalisation failures, and attribution problems. Data engineering teams often find that CDPs duplicate capabilities that their data warehouse already provides — at significant additional cost. The truth is that the decision about whether to buy a CDP, build a composable CDP on your warehouse, or conclude that you do not need one at all depends on specific capabilities your organisation actually needs.
What a CDP Is (and Is Not)
A CDP is a platform that creates a unified, persistent customer profile by combining data from multiple sources — web analytics, mobile apps, CRM, email, advertising, point-of-sale — and makes that profile available to downstream systems for activation (sending emails, personalising web experiences, targeting advertising).
The key capabilities a CDP must provide:
- **Identity resolution**: stitching together events from different systems that represent the same customer (a mobile session, a web visit, and a purchase may all have different identifiers that need to be linked to one customer ID)
- **Real-time event streaming and profile updates**: updating customer profiles within seconds of a new event
- **Profile API**: exposing customer profiles to downstream systems in real time or near-real time
- **Audience segmentation**: creating and activating segments of customers for marketing use cases
A CDP is NOT:
- A data warehouse (CDPs optimise for real-time profile access, not analytical queries)
- A data lake (CDPs are highly structured and schema-driven)
- A BI platform (CDPs are operational systems, not analytical ones)
- A magic solution to data quality problems (CDPs require clean, consistent input data)
Traditional CDPs: Packaged Solutions
Traditional CDPs (Segment, mParticle, Treasure Data, Salesforce CDP, Adobe Real-Time CDP) are packaged platforms that provide the complete CDP capability stack: data collection SDKs, event streaming, identity resolution, profile storage, segmentation, and activation.
Strengths of traditional CDPs:
- Battle-tested identity resolution algorithms
- Pre-built integrations with dozens of advertising and marketing platforms
- Real-time profile access APIs out of the box
- Operational infrastructure managed by the vendor
Limitations:
- Significant cost (enterprise CDPs are typically $100K-$1M+ per year at scale)
- Data duplication: your data now lives in both your data warehouse and the CDP
- Limited analytical capability: CDPs are not designed for complex SQL analytics
- Vendor lock-in: migrating off a CDP is expensive and disruptive
- Schema constraints: CDPs impose their own data models that may not match your data perfectly
Composable CDP: Using Your Data Warehouse as the Foundation
The composable CDP model inverts the traditional architecture. Instead of a packaged CDP that ingests your data and provides a walled-garden platform, a composable CDP uses your existing data warehouse (Snowflake, BigQuery, Databricks) as the foundation and adds specific capabilities on top.
The components of a composable CDP:
- **Data warehouse**: unified customer data storage, analytical queries, historical data
- **Reverse ETL** (Census, Hightouch, Polytouch): syncs data from the warehouse to downstream activation tools (Salesforce, Braze, Google Ads, Facebook) — reads the warehouse, writes to operational systems
- **Customer profile API** (Hightouch Profiles, Snowflake Data API): exposes customer attributes from the warehouse in real time for personalisation
- **Identity resolution** (Databricks Identity Resolution, Amperity, or custom dbt-based): matches customer identities across systems
Advantages of composable CDP:
- No data duplication: the warehouse is the system of record for all data
- Full SQL analytical power on customer data
- Cost efficiency: no duplicate storage or ingestion cost
- Flexibility: use best-of-breed tools for each capability rather than one vendor's implementation of all of them
- Governance: customer data access controlled by the same warehouse governance model as all other data
Limitations:
- More assembly required: you are integrating multiple tools rather than buying one
- Real-time profile updates may require additional streaming infrastructure
- Identity resolution at scale is technically complex
- Reverse ETL adds another dependency in the data pipeline
Do You Actually Need a CDP?
Before buying a CDP or building a composable one, the honest question: what problems are you actually trying to solve, and can your existing data infrastructure solve them?
You likely need a CDP if:
- You need real-time (sub-second) customer profile access for personalisation at the moment of a website visit or app interaction
- Identity resolution across anonymous and known identities is a core use case (matching a pre-login web session to a post-login purchase)
- You have large marketing teams who need self-service audience segmentation without SQL
- You need to sync customer segments to 10+ marketing and advertising platforms continuously
You probably do not need a CDP if:
- Your personalisation requirements are satisfied with hourly or daily audience refreshes
- Your marketing stack is small (1–3 platforms to sync to)
- The "data fragmentation" problem is really a data quality and integration problem that a good data warehouse and dbt pipeline can solve
- Your marketing team is technically capable of writing SQL or using a BI tool for segmentation
The most common CDP purchase mistake: buying a CDP to solve a data quality problem that no amount of CDP infrastructure can fix. Clean, consistent, well-governed data in a well-structured warehouse is the prerequisite. The CDP (traditional or composable) is the delivery mechanism for that data to marketing systems, not a substitute for building it.
For data architecture design that addresses customer data unification, identity resolution, and marketing data activation, our data architecture consulting practice can help organisations evaluate the build vs buy decision — contact us to discuss your requirements.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →