A customer data platform earns its keep when support, a campaign, and the product itself read the same person. The CDP Institute’s 2026 definition calls it software that creates and maintains a persistent, unified customer record that is accessible to other systems. The record has to say who the person or account is, which events belong to them, and which uses are allowed. A traffic chart does not do that. A CRM deal stage does not do that either.
This page is for a team deciding whether to buy that record, compose it on top of a warehouse, or have it built. It covers use cases, architecture, identity, consent, and the cost drivers. It does not rank named vendors, and it does not try to rank for a vendor’s own name. If the job is market prices, positions, or a ledger, that belongs on a financial data platform. If the job is historical tables for analysts, that belongs in a data warehouse.
What is a customer data platform?
A customer data platform is the system responsible for the customer record other systems read. The Institute’s longer wording, on the same page, says the CDP assumes primary responsibility for defining and maintaining customer identity and customer record structure over time, and for providing a unified interface through which customer data services are governed and made operational. David Raab named the category in 2013 and founded the CDP Institute in 2016. The 2026 wording also says storage, identity, enrichment, governance, and activation may run inside the CDP or be composed from a warehouse and other components. What distinguishes the CDP is who owns the customer context, not which box stores the files.
Admin dashboard concept by Shakuro. This screen is not a customer record.
Four jobs follow from that definition.
- Collect events and attributes from the product, billing, support, and email, and keep the source of each field.
- Link those rows to a person or an account with a written match rule.
- Keep the profile, including what the person is allowed to receive, for as long as the retention rule says.
- Let another system read the profile, and delete or suppress that person in the destination when the record says so.
A CDP does not replace the product database, the general ledger, or the gradebook. It also does not choose the legal basis for processing. Counsel does that. The software has to store the basis and enforce it.
How is a CDP different from a CRM, a DMP, and analytics?
These systems get confused because each one holds a slice of the same person. The split is which slice, and who is allowed to treat it as the record.
| System | What it owns | What not to ask it to do |
| CRM | Contacts, deals, owners, and tasks a salesperson will act on | Rebuild every click into a note, or be the only copy of consent |
| CDP | Identity, the persistent profile, and the interface other systems read | Replace the ledger, the learning record, or the ad auction |
| DMP | Audiences for ads, often anonymous and short-lived | Be the system of record for a known customer’s consent |
| Product analytics | Funnels and events inside one product | Merge billing, support, and email into one governed profile |
| Data warehouse | Historical tables for analysis | Serve a live profile unless a CDP layer owns identity on top |
CRM dashboard concept by Conceptzilla. A deal stage is not a customer profile.
A SaaS analytics platform answers which step of the product people drop out of. That answer can feed a profile. It is not the profile. A warehouse can hold the history the profile was built from. Analysts still need a written definition of “active” before two dashboards agree.
Product analytics dashboard concept by Shakuro. Funnels are not identity resolution.
Which customer data platform use cases belong in a first release?
A first release does one action a person can explain without a model. The action has a signal, a destination, and a reason not to send. Everything else waits.
| Use | Signal | Action | Stop if |
| Cart or checkout reminder | A known checkout with a product id and a contact | One message, only if the consent record allows that purpose | You cannot tell which checkout is still open |
| Trial or plan change | A product account and the current plan | An in-app prompt or an email to the account owner | Three buyers share the account and nobody owns the recipient |
| Support context | Plan, last error, open ticket | The ticket shows that context | Support and the product use different ids and nobody owns the map |
| Audience sync | A segment written in words, not only in a query | The destination receives people the record allows, and can remove them | The ad account cannot delete a person |
The cart reminder is an e-commerce software development problem when the order system and the email tool disagree on who abandoned what. The trial prompt is a SaaS development problem when the account has seats, an owner, and a billing contact, and the campaign picks the wrong one. Neither use case needs a score that claims to predict churn. A score without a written definition and a holdout is a number on a slide.
Marketing dashboard concept by Conceptzilla. A campaign screen is not proof that identity rules exist.
Skip, for the first release, a multi-touch attribution argument, a lookalike audience, and any “next best offer” that nobody can restate. Those projects fail in the identity map, then get blamed on the model.
What does CDP architecture have to include?
The architecture is the path from a source event to a profile another system can read, plus the path that removes that person later. A diagram of boxes is not the architecture. The failure you can see is.
| Piece | What it holds | Failure you can name |
| Ingestion | Events from the product, billing, support, and email | A source stops and the monitor does not name it |
| Event contract | One name, one timestamp with a zone, one schema version | signup_completed and registration_done for the same click |
| Identity | Keys and the match rule, including matches you refuse | A merge you cannot undo |
| Profile | Attributes with a written definition | “Active” means three different things |
| Consent record | Purpose, status, time, source, and the text version shown | A campaign that never reads it |
| Activation | The destination and the deletion path | An audience that still contains a deleted person |
| Warehouse copy | History for analysis, not the live profile | A report that treats yesterday’s dump as consent |
Moving the events is data pipeline development. The pipe does not decide that two emails are one person. A live action, such as a failed payment message while the checkout is still open, needs real-time data processing. A weekly segment does not. Building the stream and skipping the match rule produces a fast wrong message.
Operations dashboard concept by Shakuro. A live chart is not identity resolution.
The data model for a first release is small. Person or account id from the product. Email as a login, not as the permanent key, because logins change. Event name, timestamp, source system, schema version. Consent purpose, status, timestamp, and the text version. One calculated attribute, such as “paid plan”, with the sentence that defines it. Account versus person matters in business software: the buyer, the admin, and the seat user are three recipients. Write which one the campaign uses.
How should identity, consent, and event quality work?
Identity is a rule, not a similarity score you hope is right. Prefer the stable user id or account id the product already issues. Email is useful and unstable. A shared device, a company domain, or a similar name is not a match. Write the refusals before the first campaign. A wrong merge sends one person’s orders to another person’s inbox. Every merge has to be reversible, and the source keys have to remain on the row.
Consent is not the only legal basis, and a CDP that treats every row as consent is wrong. The consolidated text of Regulation (EU) 2016/679, the General Data Protection Regulation, on EUR-Lex says in Article 6(1) that processing is lawful only if and to the extent that at least one listed basis applies. Consent is point (a). A contract is point (b). A legal obligation is point (c). The basis is a decision for counsel, and it can differ by purpose and by country. Where the basis is consent, Article 4(11) defines it as any freely given, specific, informed and unambiguous indication of the data subject’s wishes, by a statement or a clear affirmative action. Article 7(1) requires the controller to be able to demonstrate that consent. Article 7(3) says the person may withdraw it at any time, withdrawal does not affect processing that was lawful before the withdrawal, and it shall be as easy to withdraw as to give consent.
The record that satisfies that demonstration is purpose, status, timestamp, source, and the text version the person saw. Activation reads it. A segment built in a warehouse query that never joins the consent record will send the message anyway. A missing answer is not consent: Article 4(11) requires a statement or a clear affirmative action.
Erasure is a path, not a button on one screen. Article 17(1) gives the person the right to obtain erasure without undue delay where a ground applies, including withdrawal of consent when no other legal ground remains. Article 17(3) lists cases where that does not apply, including a legal obligation and the establishment, exercise or defence of legal claims. Deleting the profile and leaving the person in an ad audience is not erasure of the copies you still control. Article 17(2) also expects reasonable steps to inform other controllers when you made the data public. This page is not a legal opinion. The firm’s basis, the exceptions, and the countries in scope come from counsel. The build has to implement the decision, including the destinations the deletion must reach.
Medical practice dashboard concept by Shakuro. A clinical screen is a different product, not a CDP.
Event quality is the third gate. One name per action. A timestamp with a zone. The source system. A schema version. An event that fails validation is a row in a monitor, not a silent drop. If two products emit the same click under two names, the profile splits, and every downstream segment inherits the split. Fix the contract before you add a destination.
Should you build, buy, or compose a CDP?
Buy when a packaged tool already connects the sources, business users can build the segment, and the product does not need to read the profile inside the app. Compose when the history already lives in a warehouse and someone will own identity, consent, and activation on top of it. Build when the product must read the profile, when the account model does not fit the tool, or when deletion has to reach a system the tool cannot see.
| Path | Fits when | Does not fit when |
| Packaged tool | Common sources, and the first action is a segment the tool can build | The account hierarchy or the consent text does not fit the tool |
| Warehouse plus a profile layer | History is already governed, and identity rules are written | The warehouse is a dump and nobody owns the match rule |
| Custom build | The product reads the profile, or deletion must reach systems outside the tool | The only goal is a vendor logo on a slide |
A small company with a store, an email tool, and an ad account should test the packaged path on one action before paying for a custom profile. An open-source collector is a component, not a finished CDP. It becomes one only when someone owns the identity rules, the consent record, and a way for another system to read the profile. That is the Institute’s point about composed services: the location of the files is not the definition.
Searches that ask for the best tool, or that name a packaged product, are a comparison of connectors, identity, and deletion. This page does not publish a ranking. A ranking without a method and without your source list is an advertisement. Enterprise needs are the same jobs with more brands, more roles, and a deletion path that reaches every activation. They are not a different definition.
Campaign reporting concept by Shakuro. Choosing a screen is not choosing the match rule.
If the packaged path fails the account model or the deletion path, get in touch with one use case: the sources, the action, and the consent constraint. That is enough to say whether a build is the next step.
What belongs in the estimate?
A license is not the estimate. The work is the source connectors, the identity rules, the consent record, activation that reads that record, an admin for the people who will change a segment, and a monitor for a sync that stops. A week count without that list is a guess. We do not publish one.
- How many sources, and which key each one uses for a person or an account.
- How many match exceptions you already know, including emails that change and accounts with several buyers.
- Which purposes need a consent record, and which destinations must accept a deletion.
- Who may see a profile, who may change the match rule, and who may export a segment.
- Which calculated attributes have a written definition, and who signs off when the definition changes.
Connectors and the event contract are usually Python app development. The screen where an operator sees the segment, the consent state, and the last failed sync is UI/UX design plus custom web application development. Operators who live in a warehouse console still need a page that shows why a person was included. A query is not that page.
Operator dashboard concept by Shakuro. The admin has to show why a person is in a segment.
The calculator below is a starting scope for a software project. It is not a quote for a CDP license, and it does not know your source list.
Get in touch when you have the source list and the one action the first release must perform. We will say if that action fits a packaged tool, a profile layer on the warehouse, or a build.
Which published work is adjacent, and which is not a CDP?
Shakuro does not have a published customer data platform case. Two public projects get cited next to this topic, and both stop short of it.
CGMA is an e-learning platform. The published case says the team rebuilt the product foundation, migrated data from the old databases, and integrated Salesforce for customer relationship management, ActiveCampaign for email marketing automation, and Freshdesk for support tickets. Admins received business analytics for customer records. The updated project launched in May 2020. That is a learning product with a CRM and an email tool beside it. It is not a persistent customer record that other systems govern. The classroom product itself is LMS development.
Symbolik interface by Shakuro. A social product for analysts, not a customer data platform.
Symbolik Social is a social platform for financial analysts. The published case says the work included restructuring information architecture and designing the experience, and that WebSockets and RabbitMQ deliver instant updates across discussions, watchlists, and financial analytics. Auth0 handles authentication. Those are live updates inside one product. They are not a match rule for marketing audiences, and they are not a consent record.
The screens below are other interface concepts that have appeared with this article. They are not evidence of a CDP.
Trading analytics dashboard concept by Shakuro. Market screens are not customer profiles.
Crypto trading dashboard concept by Conceptzilla. Not a customer data platform.
What should you verify before the first release?
Six checks, in this order. If one fails, the next one does not matter.
- Name the one action the first release must perform, and the person who receives it.
- List the sources and the key each one uses for a person or an account.
- Write the match rule and one example it must refuse, such as a shared device or a company domain.
- Name the legal basis. If it is consent, name the purpose and the text version.
- Name the destination and the step that removes a person from it.
- Name who can see a profile and who can change the match rule.
Bring that list when you get in touch. A conversation that starts from a vendor logo ends in a connector inventory. A conversation that starts from one action ends in a scope.
FAQ
What is a customer data platform?
It is software that creates and maintains a persistent, unified customer record other systems can read. The CDP Institute’s 2026 definition uses that wording and adds that the CDP owns identity and the record structure over time. A chart, a CRM deal, and an ad audience are not that record.
How is a CDP different from a CRM?
A CRM holds the contacts, deals, and tasks a salesperson acts on. A CDP holds the identity and the profile that the CRM, the product, and a campaign can read. The CRM should not be the only copy of consent, and the CDP should not be asked to replace the sales process.
What are useful customer data platform use cases?
A checkout reminder, a trial or plan prompt to the account owner, support context on a ticket, and an audience sync that can also delete. Each one needs a signal, a destination, and a reason not to send. A churn score without a written definition is not a first release.
Should you build or buy a CDP?
Buy when a packaged tool covers the sources and the product does not need to read the profile. Compose on a warehouse when the history is already there and someone owns identity. Build when the product must read the profile, the account model does not fit the tool, or deletion must reach a system the tool cannot see.
How do you choose among CDP tools?
Compare connector coverage for your sources, the match rule, whether consent is stored with a text version, and whether a deletion reaches the destination. A ranked list of products, including any product a search already named, is not a method. This page does not publish one.
What belongs in a customer data platform data model?
A stable person or account id, email as a login rather than the permanent key, event name, timestamp with a zone, source system, schema version, and a consent row with purpose, status, time, and text version. One calculated attribute is enough at the start, if its definition is a sentence someone can sign.
Is an open-source collector a customer data platform?
No. A collector or a warehouse table is a component. It is a CDP only when someone owns identity, the consent record, and a way for another system to read the profile. The 2026 Institute wording allows those pieces to be composed. It does not say the collector is the platform.
What drives the cost of a custom CDP?
The number of sources, the match exceptions, the consent purposes, the destinations that must accept a deletion, and the admin for the people who change a segment. A license line is not that list. We do not publish a price without it.
How long does a first release take?
As long as the source contracts, the match exceptions, and the deletion path. A store plus an email tool is a smaller job than five brands with different consent texts. A week count without that list is a guess, so this page does not give one.