Concept
A Customer Data Platform is the layer that builds and owns a single, persistent, identified view of each customer, and makes it available to everything else. Strip away the demos and it does one structural thing: it takes the fragments a person leaves across web, app, email, store and support, resolves them to one identity, and keeps that profile alive between campaigns. It is a place data lives and gets reconciled, not a place messages get sent.
Why it matters
The reason to name the CDP as its own layer is that identity is a single-owner problem. Either one system resolves who the customer is and everyone else reads that answer, or every channel tool guesses from its own slice and you end up with as many versions of the customer as you have tools. Those versions never fully agree, so personalisation contradicts itself and no report reconciles. Once you treat the CDP as the layer that owns identity and persistence, the architecture question becomes clear: what feeds it, what reads from it, and who is allowed to write back. If you instead treat it as a feature bundled into a channel platform, you have quietly decided that identity will be shallow and channel-shaped, which is the decision most teams make without noticing.
A simple example
A shopper browses on mobile without logging in, later buys on desktop after signing in, and returns a week later through an email link. To the email tool she is an address, to the web analytics tool she is two anonymous sessions, and to the commerce platform she is one order. None of them, alone, knows these are the same person. A CDP stitches the anonymous mobile session to the logged-in desktop purchase to the email identity, so the next decision is made against one history rather than three partial ones. Same events, but only one architecture ever sees the whole customer.
The architecture view
Where the profile lives. The difference is whether one system owns identity, or every tool invents its own.
This is why a packaged CDP like Adobe Real-Time CDP or Salesforce Data Cloud leads with identity resolution rather than messaging, and why a warehouse-native approach on Snowflake or BigQuery has to answer the identity question separately before it can honestly call itself a CDP. When you assess one, look first at how it resolves a single person across anonymous and known states. That capability, not the channel connectors, is what makes it the layer described here.
The mistake I often see
The recurring error is buying a CDP to fix an activation problem. Campaigns feel slow or personalisation feels thin, so the team acquires a CDP expecting richer sends, then judges it on how well it messages. But messaging lives in the engagement layer, not the data layer, so the CDP underwhelms at a job it was never meant to do while the real gap, unresolved identity, stays open. The opposite mistake is treating the warehouse as if it were already a CDP because the data is technically all there. Co-located tables are not a resolved profile. Without identity resolution and governed access, you have storage, not a customer view.
Go deeper
For the full history of how these three letters won their naming war and then began dissolving into suites and warehouses, read the acronym piece on the CDP. For what changes once this layer meets the engagement layer, When CDP Meets CEP traces the convergence.
This node sits in Data & Identity, next to what a CEP is and what decisioning is, the two layers that read from the profile this one owns.