When a Composable Customer Data Platform Makes Sense -- and When It Does Not
Last month a Series B fintech asked me to evaluate three CDP vendors. They had a shortlist, a procurement timeline, and a budget line of EUR 84,000 per year. What they did not have was a functioning data layer. Their GA4 purchase event fired on page load instead of on transaction completion. Their CRM stored no click identifiers. Consent Mode was misconfigured, so roughly 40 percent of European sessions were being silently dropped.
I told them to stop the RFP. Not because CDPs are bad -- they solve real problems for specific companies -- but because spending EUR 84,000 per year to unify data that is broken at the source is like buying a warehouse management system for an empty warehouse.
That conversation happens more often than it should. The CDP category has exploded: the CDP Institute tracks hundreds of vendors across dozens of categories, and the list keeps growing. Marketing teams hear "unified customer profile" and assume the tool will fix their measurement gaps. Sometimes it will. Usually, it will not -- at least not until the foundation is solid.
This post walks through what CDPs actually do, what a data layer already handles, where the two overlap, and how to decide which investment comes first.
What a CDP Actually Does
A customer data platform ingests data from multiple sources -- website, CRM, email, point-of-sale, mobile app -- resolves identities across those sources, builds a persistent customer profile, and makes that profile available to downstream tools for activation (ad targeting, personalisation, email triggers).
The CDP Institute defines it as "packaged software that creates a persistent, unified customer database that is accessible to other systems." Three traits separate it from a data warehouse or a CRM: automatic identity resolution, marketer-managed operation, and real-time profile availability.
The composable customer data platform variant goes further. Instead of a monolithic product owning storage, identity resolution, and activation in one package, a composable CDP assembles those capabilities from best-of-breed components -- your own data warehouse for storage, a tool like Census or Hightouch for reverse ETL, and a resolution layer on top. Snowflake, Hightouch, and Databricks all market composable CDP architectures that keep data in the warehouse and sync segments outward.
What a Data Layer Already Handles
If you are unfamiliar with the concept, I covered it in depth in What Is a Data Layer and Why Tracking Breaks Without One. The short version: a data layer is a structured JavaScript object that sits between your website and your tag management system. Instead of tags scraping the DOM for values, your developers push clean, typed events into this object. GTM, Adobe Launch, or any other TMS reads from it.
A well-built data layer already gives you:
- Consistent event structure across every tag and platform. One purchase push feeds GA4, Google Ads, Meta CAPI, and TikTok simultaneously.
- Decoupling from the frontend. Redesigns do not break tracking because tags never touch the HTML directly.
- Real-time event data flowing to every downstream destination the moment user actions happen.
- A single source of truth for what happened on-site, which is the same thing a CDP promises for web behavioural data.
The critical difference: a data layer handles the collection and distribution of on-site events. It does not resolve identities across channels, it does not store persistent customer profiles, and it does not activate segments in ad platforms. Those are CDP jobs.
Feature Comparison: CDP vs. Data Layer
| Capability | Data layer + TMS | Composable CDP |
|---|---|---|
| Structured on-site event collection | Yes | Relies on a data layer or SDK for this |
| Cross-device identity resolution | No (needs CRM or backend logic) | Yes, built-in |
| Persistent unified customer profile | No | Yes |
| Real-time audience activation | Limited (server-side tag routes) | Yes, a core feature of a real-time customer data platform |
| Offline data ingestion (POS, call centre) | No | Yes |
| First-party data unification | Partial (on-site only) | Yes, across all sources |
| Marketer-managed segmentation | No (requires analyst or dev) | Yes |
| Time to implement (typical range from consulting experience) | 2-6 weeks | 3-12 months |
| Annual cost, mid-market (typical range from consulting experience) | EUR 0-5,000 (hosting for sGTM) | EUR 24,000-180,000+ |
The cost column deserves a closer look. Customer data platform pricing varies wildly. Entry-level tools like RudderStack or Segment's free tier start near zero but scale with event volume. Mid-market platforms -- Segment Business, mParticle, Bloomreach -- typically land between EUR 24,000 and EUR 80,000 per year in my experience. Enterprise customer data platform deployments from vendors like Adobe Real-Time CDP or the Salesforce customer data platform (Salesforce Data 360) regularly exceed EUR 120,000 per year, plus implementation services that can double the first-year cost. Salesforce Data 360 uses a credit- and profile-based model that typically reaches six figures annually for enterprise deployments.
If you are an ecommerce brand doing EUR 2 million in annual revenue and your primary need is accurate conversion tracking across three ad platforms, a composable CDP is almost certainly over-engineered for your situation. A clean data layer, server-side tracking, and CRM-to-ad-platform pipelines will cover the vast majority of the use case at a fraction of the cost.
When You Actually Need a CDP
Not every company needs one. But some genuinely do. Here are the conditions I look for:
Multiple owned data sources that need unification
If you have a website, a mobile app, a physical retail presence, and a call centre, and you need a single customer profile across all four, a CDP earns its keep. This is particularly true for a customer data platform for retailers running both ecommerce and brick-and-mortar, where online behaviour and in-store purchases need to merge into one profile for loyalty and personalisation.
High-volume identity resolution
If you have millions of anonymous profiles that need to be matched to known users across devices and sessions, you need probabilistic and deterministic matching at scale. A data layer does not do this. A composable CDP running on your warehouse with a resolution layer like Hightouch or Simon Data does.
Real-time activation at the segment level
If your marketing requires pushing dynamically updated audience segments to six or more downstream tools in near-real time -- suppressing recent purchasers from prospecting within minutes, for instance -- that is a real-time customer data platform use case. A tag manager can suppress a remarketing tag on a thank-you page, but it cannot update a Meta Custom Audience or a Google Ads Customer Match list without infrastructure that behaves like a CDP.
Regulatory complexity across multiple jurisdictions
If you operate in the EU, the UK, California, and Brazil simultaneously, managing consent at the data-layer level across every tool is painful. A CDP that enforces consent rules at the profile level before activation reduces compliance risk.
When a Data Layer Comes First
In every other case -- and in the cases above too -- the data layer comes first. A CDP cannot unify data it never receives correctly. I have seen enterprise customer data platform deployments fail because the input data was garbage: duplicate transactions, missing user identifiers, inconsistent currency codes, events firing on the wrong page.
Here is a pattern I see repeatedly. A company buys a CDP, connects it to GA4 and their CRM, and then discovers that:
- GA4 purchase events are missing a third of transactions because the data layer was never implemented properly.
- The CRM has no click identifiers (GCLID, FBCLID) stored alongside leads, so the CDP cannot stitch ad clicks to CRM outcomes.
- Consent signals are not flowing into the data layer, so the CDP ingests data it should not have, creating a compliance liability.
The CDP did not fail. The foundation failed. Fixing the data layer, pushing events correctly through GTM, and building first-party data pipelines would have taken weeks and cost a fraction of the CDP contract.
If your measurement is broken -- if GA4 and your CRM disagree on conversions, if you cannot tell which campaign drove a closed deal, if your ad platforms are optimising on incomplete data -- the first investment is the data layer and the tracking infrastructure, not a platform that sits on top. That is the work I do in a marketing measurement engagement: audit the gaps, fix the plumbing, and build the pipelines that feed accurate data to whatever tools you choose downstream.
The Composable CDP Middle Ground
The composable customer data platform architecture is worth understanding even if you do not buy a packaged CDP, because it describes what a lot of companies end up building organically:
- Data warehouse as the foundation. BigQuery, Snowflake, or Databricks stores all your first-party data -- GA4 exports, CRM syncs, transaction logs.
- Reverse ETL for activation. A tool like Hightouch or Census reads warehouse tables and pushes segments to Google Ads, Meta, Klaviyo, Intercom, or whatever tools need the data.
- Identity resolution. Either a dedicated tool or SQL logic that merges anonymous and known profiles using email, phone, or device identifiers.
This is functionally a composable CDP, but you own every layer. The advantage: no vendor lock-in, transparent pricing, and full control over what data leaves your infrastructure. The disadvantage: it requires engineering resources to build and maintain.
For companies already running a GA4 BigQuery export, the warehouse layer is already in place. Adding reverse ETL is a week of setup, not a six-month migration.
Decision Framework
Use this to decide where to start.
| Signal | Start with data layer | Evaluate a CDP |
|---|---|---|
| GA4 and CRM conversion counts disagree | Yes | Not yet |
| No structured data layer exists | Yes | Not yet |
| Single website, no app, no POS | Yes | Probably not |
| Need cross-device identity at scale | Data layer first, then CDP | Yes |
| 5+ activation destinations needing real-time segments | Data layer first, then CDP | Yes |
| Multi-brand, multi-region, millions of profiles | Data layer first, then CDP | Yes |
| Annual revenue under EUR 5 million | Yes | Rarely justified |
Notice the pattern: the data layer comes first in every row. Even when a CDP is the right long-term investment, the data layer is a prerequisite, not an alternative.
FAQ
What is a composable customer data platform?
A composable customer data platform is an architecture that assembles CDP capabilities from separate best-of-breed components rather than buying a single monolithic product. Typically this means using your own data warehouse for storage, a reverse-ETL tool for activation, and a separate identity-resolution layer. You get CDP functionality without vendor lock-in, but you need engineering resources to build and maintain it.
Do I need a CDP if I already have GA4 and a CRM?
For most small and mid-market companies, no. GA4 handles on-site behavioural data, your CRM holds customer records, and a well-built data layer connects the two to ad platforms. A CDP becomes necessary when you need cross-device identity resolution at scale, real-time audience activation across many tools, or unification of online and offline data sources that GA4 and a CRM cannot bridge.
How much does a customer data platform cost?
Entry-level CDPs start free or near zero for low event volumes. Mid-market platforms typically cost between EUR 24,000 and EUR 80,000 per year. Enterprise deployments from vendors like Salesforce Data 360 or Adobe Real-Time CDP often exceed EUR 120,000 per year before implementation costs. A composable CDP built on your own warehouse can cost significantly less, primarily warehouse compute plus a reverse-ETL subscription.
What should I fix before buying a CDP?
Start with a structured data layer that feeds consistent events to your tag manager. Then ensure your CRM captures click identifiers like GCLID alongside lead records. Finally, verify that consent signals flow correctly so the CDP does not ingest data it should not have. Without these foundations, a CDP will unify unreliable data and give you a polished view of bad numbers.
Is a composable CDP better than a packaged CDP?
It depends on your team. A composable CDP gives you more control, transparent pricing, and no vendor lock-in, but it requires engineering resources to build and maintain. A packaged CDP is faster to deploy and easier for marketing teams to manage independently. Companies with a modern data stack already in place tend to benefit more from the composable approach.
Not sure whether your tracking foundation is ready for a CDP -- or whether you need one at all? Book a measurement audit and I will tell you exactly what to fix first.