Is this a customer data platform? No — no ingestion, no identity resolution, no segments

Where a customer data platform wins

A CDP exists to do three things this framework does not do in any form: ingest records and events continuously from many source systems; resolve them into one profile per person or account; and build segments over those profiles that can be frozen, suppressed, and synced to downstream destinations. If any one of those sentences describes your problem, the comparison is already finished and the answer is not this. That is a description of the category by the jobs it is bought to do — not an evaluation of any product, for the reason given in the last section.

On ingestion, the absences are total. There is no CSV import (JTBD-DO-01), no email or calendar sync (JTBD-CM-01, JTBD-CM-02), and no integration adapter of any kind — a notification provider contract exists and nothing sends (L-05). There is also no scheduler, task engine or queue, so even if an adapter existed there is nothing to run it on a cadence (L-04). A pipeline needs both halves and this has neither.

On identity resolution, the same. No duplicate detection on import or entry (JTBD-DO-02), no merge of two Companies or Contacts (JTBD-DO-03), no search across modules (JTBD-DO-07), no unified activity timeline for a record (JTBD-DO-08). Every record here is what a person or a workflow wrote, and two records for the same human stay two records forever.

On segmentation, the same again. No dynamic audience from CRM data (JTBD-MK-01), no frozen audience snapshot for a send (JTBD-MK-02), no exclusions or suppression sets (JTBD-MK-03), no audience sync to a provider (JTBD-MK-06). And on the governance a CDP buyer usually asks about first: no consent or lawful-basis record (JTBD-DG-01), no export of everything held about a subject (JTBD-DG-03), no view of what was shared with which provider (JTBD-DG-06), no restriction of sensitive fields by role (JTBD-DG-07) — because there are no roles (L-01). The framework states the conclusion itself: you cannot put real customer data in this yet (L-09).

Where this is different

What does exist is the opposite shape — per-record decision history rather than a population view. A lead is captured, enriched, scored, routed, qualified and converted through explicit actions, each one atomic and audited (C-06); a score carries the fingerprint of the model version that produced it, with one contribution row per rule, so a number from last quarter can still be accounted for (C-07); every mutation leaves an audit event and a step-level trace (C-16). The question that answers is why this one record got this outcome and under which policy version, a year later. The question it cannot answer is how many people match a rule across your systems — which is the question a CDP is bought for.

The one thing here that superficially resembles ingestion is not ingestion. Lead enrichment calls a provider outside the write transaction and stores an immutable snapshot with its provenance — and that provider is a checked-in fixture. No external data source is wired and no credential ships (C-06). One provider call inside one action is not a pipeline, and describing it as one would be the kind of sentence this site exists to avoid.

How to choose

If the sentence you would write is unify our customer data across systems, stop here. Nothing in this framework does that, and building it on top would not be an extension but a different product: there is no ingestion path and no scheduler to run one (L-04, L-05).

If the sentence is our commercial process needs stages, quotes, approvals and an audit trail, and one record's outcome has to be explainable afterwards, that is the narrow case this exists for — with the standing caveats that there is no authentication, no tenancy and no place for real customer data yet (L-01, L-09).

If both sentences are true, they are different layers rather than competing options: the CDP owns the profile and this owns a process. They do not connect today, because there is no integration runtime and no import (L-05, L-06), so any bridge between them is engineering work you would own outright.

If what you actually need is marketing execution — audiences, campaigns, journeys, attribution — the answer is the same and is recorded rather than implied: every one of those jobs is marked not supported in the job matrix, so you can confirm the refusal instead of taking it on trust.

What this comparison does not cover

No CDP product is named, ranked, priced or evaluated on this page. docs/strategy/COMPETITOR_MAP.md — the only source this cluster may use for facts about other software, researched on August 4, 2026 — covers CRM and CRM-adjacent projects and carries no CDP research whatsoever. A specific claim about a specific vendor would therefore have been invented, and inventing one would undo the credibility every other page here is built on.

The category description in the first section is definitional: the three jobs a CDP is bought to do. It is not a statement about how any particular implementation does them, how well, or at what price.

Nothing about data warehouses, reverse ETL, event streaming, identity graphs or consent management platforms, for the same reason: no researched source here carries them.

No roadmap. The absences listed above are current state, and recording them is not a commitment that any of them will be filled. This entry carries the research file's date rather than the date it was written, and must be re-read when that file is refreshed.