Dilshat Rakhimov
July 2026 · 11 min read

"We're evaluating a CDP" has arrived in my inbox three times this year, and it has meant three different things: our events are a mess, we can't join the app user to the CRM record, and marketing can't launch a campaign without an analyst. Only one of those is a CDP problem.

I've argued before that the warehouse belongs at the centre of the stack — that's the prequel to this piece. This one is the uncomfortable follow-up: once the warehouse is there, most of what a CDP sells you, you either already own or can buy for a fraction of the contract. Here's how I sort it, and where the honest yes lives.

Do you actually need a CDP cover

What a CDP actually bundles

Strip the marketing and a CDP is five capabilities sold as one:

  1. Collection — SDKs and server libraries that capture events once and fan them out.
  2. Identity resolution — stitching anonymous ids, logged-in ids, emails and devices into one profile.
  3. Segmentation — building audiences without SQL.
  4. Activation — pushing those audiences into ad platforms, email, push, CRM.
  5. Governance — schema enforcement, PII handling, consent state.

The bundle is the product. The trap is that teams buy all five to fix one, and the one they're trying to fix is usually the one a CDP can't fix for them.

One bundled platform next to a stack of separate composable layers

Test 1: is it actually a taxonomy problem?

Symptoms: nobody trusts the funnel numbers, two dashboards disagree, the same user action is called four things.

I inherited an analytics estate at a bank insurance business that was sending 200-plus event types under 18-plus naming prefixes, with nested property objects, thirty-odd variants of a single payment event, and a generic client-side payment firing 154,000 times a month next to a stray revenue_amount at 94,000. The rebuild took it to 35 events: one screen_viewed, one technical_error carrying severity and source as properties, one server-side payment_completed fired after the payment-gateway callback with revenue inline, and a mandatory product_type with a 23-value catalogue routing every product line through the same schema.

A CDP would not have done any of that. It would have ingested all 200 events faithfully, resolved them into profiles, and charged for the privilege. Garbage in, expensively unified garbage out. If your problem is that your events don't mean anything consistent, the fix is a schema and an owner for it — and it's a two-to-four week job, not a platform.

Test 2: is it an identity problem?

Symptoms: "we can't connect app behaviour to the CRM record", "we don't know if the web user and the app user are the same person".

This one is real, and it's still usually not a CDP. The pattern I ship is an identity envelope:

LayerHoldsWho has access
Product analyticsUUID, behaviour, UTM, layeranalysts, marketing
CRM / internal DBUUID → national ID, name, phone, emailauthorised staff only
BI / warehousejoin of the two, under RBACanalysts, read-only

The analytics tool never sees personal data — it gets a UUID generated once at first login. The CRM holds the mapping. Any question that needs both ("what did this specific customer do before churning") is answered by a join in BI, behind role-based access, with the export audited.

That's a design decision plus a few days of work: mint the UUID, sanitise event properties before they leave the client, unset the PII already sitting in your analytics tool via its identify API, build the lookup view, grant it to the roles that should have it. Under Kazakhstan's personal-data law — and under GDPR for anyone selling into the EU — this isn't optional hygiene, it's the thing that gets checked. A CDP will happily do identity resolution for you, but it does it by holding the personal data, which for a regulated financial product is a harder conversation with compliance, not an easier one.

Buying a CDP to solve identity means moving your PII into one more vendor. For a bank, that's usually the argument against, not for.

Test 3: is it an activation problem?

Symptoms: "the data is in BigQuery and nobody can do anything with it."

Activation splits cleanly in two, and both halves are cheap now.

Ads activation is server-side tagging plus the conversion APIs. In the CAPI rebuild I ran for an insurance product, the diagnosis was four numbers: click-id coverage on Purchase at 0.07%, event match quality 6.8 out of 10, external id on 40.8% of purchases, email on 1.1%. The cause was architectural — the pixel loaded after hydration, and a URL-cleanup plugin stripped click ids before anything could read them — and the fix was a first-party server container on the client's own subdomain, plus capturing click ids in an inline head script before the router could wipe them. Hosted server-side GTM in the deployments I've run costs roughly $20–200/month depending on the tier and power-ups; self-managed Cloud Run lands in a similar band once you count the always-on instances.

Lifecycle activation is reverse ETL: build the segment as a SQL model in the warehouse, sync it to Klaviyo, the CRM, or an ad platform's audience API. Hightouch's free tier gives you two active syncs with unlimited destinations and seats — enough to prove the pattern before anyone signs anything.

Between those two, a warehouse-plus-server-container stack does the activation work most teams were about to buy a CDP for, at a couple of hundred dollars a month.

Test 4: is it real-time, and is the user non-technical?

This is where the answer flips to yes.

Buy a CDP when all of these are true at once:

  • Marketers must build and launch audiences themselves, without writing SQL and without waiting on an analyst queue.
  • The activation has to happen in seconds, not on a warehouse sync schedule — in-session personalisation, cart abandonment inside a live journey, next-best-action on a call.
  • You have many source systems (a dozen-plus SaaS tools, not three) and no data engineering capacity to maintain pipelines between them.
  • You need consent state and suppression enforced consistently across every destination, with an audit trail, because you operate across jurisdictions.

If two of those are true, you're borderline; run the cheaper architecture for two quarters and re-evaluate with real usage numbers. If all four are true, a CDP is the right purchase and the arguments above don't apply to you.

Note what's missing from that list: "we have a lot of data" and "our competitors have one". Neither is a reason.

The cheaper architecture, in build order

If you fail tests 1–3 and don't hit test 4, this is what to build instead, and the order matters — each layer is worthless without the one before it.

  1. Taxonomy. One schema, flat properties, declared types, an owner. Money events server-side with an idempotency key. Governance switched on: planned events, alerts on unplanned ones, automatic blocking of anything matching a PII pattern.
  2. Warehouse. Raw events, CRM records, and ad spend in one place — BigQuery is the default when you're already on GA4. This is the only layer you should expect to still be running in five years.
  3. Identity. UUID in the analytics tools, PII in the CRM, one join table under RBAC. Decide the keys before you build anything on top.
  4. Activation. Server-side container plus conversion APIs for the ad platforms; reverse ETL for CRM, email and push. Both read from the warehouse; neither becomes a second source of truth.
  5. Consent. Consent state flows from the client into the server container and travels with the event. Moving to server-side tagging does not remove the consent requirement — a misconception I correct on roughly every engagement.

Cost shape: warehouse usage, $20–200/month for the server container, a free or usage-based reverse ETL tier. Compare that to the CDP end, where the major vendors don't publish prices at all — Segment's CDP tiers are quote-only and metered on monthly tracked users, which is a metric that grows whether or not the extra users are worth anything to you.

The takeaway

Most "we need a CDP" conversations are one of three cheaper problems wearing a CDP costume: a taxonomy that means nothing consistent, an identity model nobody designed, or an activation gap that a server-side container and a reverse ETL sync close for a couple of hundred dollars a month. Run the four tests honestly. If marketers need self-serve audiences activated in seconds, across a dozen sources, with consent enforced everywhere — buy one, and buy it properly. If not, build taxonomy → warehouse → identity → activation → consent in that order, and keep the ability to change your mind about every vendor above the warehouse.

If you're somewhere in that evaluation right now, the useful first step is much smaller than a vendor bake-off: count your event types, check whether personal data is sitting in your analytics tool, and measure your actual click-id coverage on purchases. Three numbers, an afternoon's work. They'll tell you which of the four tests you're really failing — and in my experience it's rarely the fourth one.

Sources