A customer data platform (CDP) promises a single view of every customer and the ability to act on it across channels. For years that meant buying a packaged CDP and copying customer data into it. A composable CDP takes a different route: it builds the same capabilities directly on your existing data warehouse or lakehouse, and connects outwards to the marketing and advertising tools that need the results.

This article explains the building blocks, the trade-offs and a practical way to start.

Packaged versus composable

Packaged CDP Composable CDP
Where customer data lives A copy inside the CDP vendor's platform Your warehouse or lakehouse
Data model Vendor-defined Your own, extended as needed
Governance Managed separately from other data Same catalog, access controls and lineage as the rest of your data
Time to first value Often faster for standard use cases Faster when a solid data platform already exists
Skills needed Marketing operations, vendor configuration Data engineering plus marketing operations
Best fit Limited data engineering capacity, standard use cases Strong data platform, custom models, strict governance

Neither is always right. Composable approaches work best when an organisation already has a well-governed data platform and wants customer data, analytics and AI models to share one foundation.

The building blocks

A composable CDP is a set of capabilities, each of which maps to parts of a modern data platform.

1. Data collection

Bring customer signals from every touchpoint into the lakehouse: web and app events, CRM, transactions, service interactions, email and advertising engagement. Event streams land in bronze tables through streaming ingestion; batch sources arrive through ELT. Consent status must travel with the data from the start.

2. Identity resolution

Identity resolution links records that belong to the same person or household across systems.

  • Deterministic matching uses exact identifiers — login IDs, hashed emails, phone numbers, loyalty numbers.
  • Probabilistic matching uses combinations of weaker signals where appropriate and permitted, with confidence scores.
  • The output is an identity graph: a table mapping every source identifier to a stable customer ID, rebuilt or updated incrementally as new data arrives.

Keep the matching rules transparent and versioned. Marketing teams need to understand why two profiles were merged, and privacy teams need to know which identifiers are used.

3. Customer 360 profiles

With a stable customer ID, build a unified profile in the silver and gold layers: attributes, consent, lifetime metrics, recent behaviour and engagement by channel. Model it once and reuse it across analytics, personalisation and service teams.

4. Intelligence

This is where a lakehouse-based approach shines, because data science teams work directly on the same data:

  • Propensity to buy, churn risk and lifetime value models
  • Next-best-action and product recommendations
  • Behavioural and value-based segmentation
  • AI-generated audience descriptions and campaign insights

Scores are written back to gold tables as profile attributes, ready for activation.

5. Audience building

Marketers need to build segments without writing SQL. Composable audience tools, or an internal audience builder over governed gold tables, let them combine attributes and scores into audiences with previews of size and overlap.

6. Activation

Activation syncs audiences and attributes from the lakehouse to the tools that act on them — often called reverse ETL:

  • Advertising platforms such as Meta Ads and Google Ads, for targeting and suppression
  • Marketing automation and email platforms, for journeys and campaigns
  • CRM and service tools, so sales and support see the same profile
  • Personalisation engines on web and app

7. Measurement

Campaign responses and conversions flow back into the lakehouse, closing the loop. Attribution and incrementality analysis then run on the same data that built the audience.

Governance and privacy

Customer data carries the highest privacy expectations, which is one of the strongest arguments for keeping it in a governed platform:

  • Apply one set of access controls, classifications and masking rules across all customer data
  • Store and enforce consent per purpose and channel, and respect it in every audience sync
  • Honour deletion and access requests once, in one place, and propagate them to downstream tools
  • Use lineage to show exactly which data fed which audience

A practical starting sequence

  1. Pick one high-value use case — for example, suppressing existing customers from acquisition campaigns, or a churn-prevention audience.
  2. Land the minimum data needed for it: one or two event sources, CRM and transactions.
  3. Build deterministic identity resolution first; add probabilistic matching later if the use case needs it.
  4. Create a first Customer 360 table with the attributes the use case needs.
  5. Activate to one destination and measure the result against a control group.
  6. Expand to more sources, models and channels once the loop is proven.

When a packaged CDP is still the right call

Choose a packaged CDP when there is little data engineering capacity, when real-time, in-session personalisation is the core requirement and the vendor excels at it, or when marketing needs to move before a data platform is ready. Many organisations run a hybrid: the lakehouse as the system of record for customer data and models, and a packaged tool for specific real-time activation.

The takeaway

A composable CDP is less a product than an architecture decision: treat customer data as part of your data platform, not a separate silo. Done well, the same foundation serves analytics, AI and marketing — and every new use case gets cheaper than the last.

Exploring customer data platforms or identity resolution? Talk to our customer intelligence team.