What Is a CDP (Customer Data Platform)?
A customer data platform unifies first-party customer data from across a company's systems into persistent, individually addressable profiles that marketing and other teams can query and activate directly, without a standing request to a data engineering team. That combination of unification, persistence, and marketer-facing access is what separates a CDP from a data warehouse, a CRM, or a legacy data management platform (DMP).
What does a CDP do?
A CDP performs four jobs in sequence. First, ingestion: pulling event, transaction, and declared data from a company's own sources (web, app, point of sale, email, support tickets, loyalty programs) rather than third-party or purchased data. Second, identity resolution: stitching records tied to the same person, whether that person shows up as an anonymous cookie, a logged-in account, an email address, or a loyalty number, into one profile. Third, segmentation: letting a non-engineer build an audience from that unified profile using rules or attributes, not SQL. Fourth, activation: pushing that audience to the destinations a team uses day to day, from paid media platforms to email and SMS tools to CRM systems.
The first-party requirement is what separates a CDP from a DMP. A DMP was built for anonymous, cookie-based, third-party audience data with a short data lifespan, useful for ad targeting but not for building a durable profile of a known customer. A CDP holds data the company already has a direct relationship for, and that data persists.
How is a CDP different from a CRM or a data warehouse?
A CRM is built around sales and service workflows: records that a human enters or updates, structured around accounts, contacts, and deals. A CDP is built around behavioral and transactional signal that accumulates automatically from systems a person never has to touch, structured around a resolved profile rather than a deal record. Companies increasingly connect the two, using CRM data as one ingestion source into a CDP and CDP-built segments as targeting input back into CRM workflows, but the two solve different jobs. A closer look at where the two overlap and diverge is in CDP vs CRM: The Difference That Matters.
A data warehouse stores structured data at scale and is where a lot of the raw material a CDP needs already lives, but a warehouse on its own has no identity resolution layer built for marketing use, no segment builder a non-engineer can operate, and no native connections to activation destinations. This distinction matters because it defines the two dominant CDP architectures on the market today.
What are the two CDP architecture patterns?
Packaged CDPs hold their own copy of ingested data inside the vendor's infrastructure, which typically means faster time to a working profile but a second data store to govern and reconcile against the source systems. Composable, or warehouse-native, CDPs instead run directly against a company's existing cloud warehouse (Snowflake, BigQuery, Databricks, or Redshift), avoiding duplicate data storage and letting data engineering keep governance in one place, at the cost of needing that warehouse relationship already in reasonable shape before the CDP delivers value.
Neither pattern is inherently the right starting point; the decision depends on whether a company's warehouse investment and data engineering capacity already exist or still need to be built.
A few names worth evaluating
The CDP space spans large horizontal platforms, warehouse-native entrants, and vertical specialists, and this is a non-exhaustive sample of the field rather than an attempt to cover it.
ActionIQ, now operating under Uniphore, runs as a composable CDP directly on a customer's Snowflake, BigQuery, or Databricks environment, with identity resolution that blends deterministic and probabilistic matching. Its own documented destination catalog runs to roughly 100 connectors, smaller than some CDP peers, and setting up a new destination is described as requiring a support request rather than admin self-service; native message delivery (email, SMS, push) is out of scope by design, so it pairs with a separate engagement platform for that layer. Typical implementations run three to six months with vendor engineering involvement, and pricing is quote-based.
Rokt mParticle runs a hybrid model, combining real-time event streaming with the same warehouse-native governed-table access to Snowflake, Databricks, BigQuery, or Redshift. It documents more than 300 pre-built destination integrations spanning paid media, owned channels, and CRM tools, along with a Match Boost feature that enriches first-party audiences with third-party identifiers at the point of activation. It holds ISO 27001 and SOC 2 Type 2 certifications and documents native profile-level data deletion for GDPR and CCPA requests. Pricing is custom-quote.
Lexer is built specifically for retail and hospitality rather than as a horizontal platform, with pre-built connectors for POS, ecommerce, loyalty, and CRM data and deterministic identity stitching keyed on email, phone, and loyalty ID. That retail-specific schema shortens setup time for retailers but is a narrower fit outside the vertical. Its architecture is batch-oriented, with profile refresh documented on a daily or near-daily cadence rather than true event streaming, and it markets a managed onboarding model aimed at retailers without a large internal data engineering team, with implementation timelines measured in weeks.
Where the definition gets misused
Vendors sometimes market a segmentation layer bolted onto an ad platform, or a marketing automation tool with an audience builder, as a CDP. The test is whether the tool resolves identity across sources into a profile a team owns and can activate anywhere, or whether it just filters data that already lives inside one vendor's walled garden. A tool that can only build audiences for its own downstream use is an audience builder, not a CDP, even if the vendor uses the term.
Buyers also sometimes assume a CDP replaces the warehouse or the CRM. In most deployments it sits alongside both, drawing from the warehouse or CRM as sources and feeding segments back out, rather than displacing either system.
CartographAI runs independent, evidence-based assessments of CDP platforms and other adtech and martech categories, and the tool is free for buyers and agencies researching this category. For a closer look at what separates specific platforms once a company is ready to shortlist, see How to Evaluate a CDP: What Separates the Platforms.
FAQ
Is a CDP the same thing as marketing automation software? No. Marketing automation tools execute campaigns (email sends, workflow triggers, lead scoring) and typically hold their own customer records for that purpose, but they are not built to resolve identity across a company's full set of first-party sources. Many marketing automation platforms consume CDP-built segments as an input rather than performing that unification themselves.
Does a company need a data warehouse before buying a CDP? Only if evaluating a composable or warehouse-native CDP, which runs against an existing warehouse rather than storing its own copy of the data. A packaged CDP does not require a warehouse relationship already in place, since it ingests and stores data independently, though it will still need clean, well-instrumented source systems to produce a useful profile.
Can a CDP replace a DMP? For first-party data use cases, yes, and most companies that adopted a CDP have retired standalone DMP contracts once the CDP could support both first-party segmentation and the audience-export use cases the DMP handled. A DMP still has a role for pure third-party, cookie-based reach extension, though that use case has shrunk as third-party cookies decline.
How long does a CDP implementation typically take? Public case studies and vendor documentation across the category most often cite a range from a few weeks to six months, depending heavily on architecture (composable implementations depend on the state of the underlying warehouse) and on how many source systems and destinations need to be connected at launch.
What is identity resolution in a CDP, specifically? It is the process of determining that multiple records, such as an anonymous website cookie, a logged-in mobile app session, and an email address from a purchase, belong to the same person, then merging the associated data into one profile. Approaches range from deterministic matching (exact identifiers like email or loyalty ID) to probabilistic matching (statistical confidence based on device, behavior, and other signals), and most platforms use both.
Do CDPs handle consent and privacy compliance? Most CDPs built for enterprise use document role-based access control, audit trails, and configuration paths for regulations like GDPR and CCPA, and many integrate with a dedicated consent management platform (CMP) rather than building consent logic natively. Buyers evaluating a CDP for a regulated industry should confirm the specific compliance certifications (SOC 2, HIPAA readiness) and consent-integration depth directly, since documentation depth varies by vendor.