Customer data platform: why unified profiles often stay siloed
You bought the customer data platform. You paid the license, signed the MSA, stood up the connectors, and brought the marketing team and the data team into the same war room for the kickoff.
Customer Data Platform: Why Unified Profiles Stay Siloed
Six months later, your CRM still tells a different story than your helpdesk, your ad platform is rejecting uploads because the user IDs do not line up, and the CFO wants to know why the unified profile dashboard never matches the commerce platform dashboard. Welcome to the operational reality of customer data platform rollouts.
The pitch is seductive because it sells a fantasy that every operator secretly wants: press a button, kill the spreadsheets, watch the duplication disappear. The reality is uglier. The CDP Institute's 2026 definition describes a customer data platform as software that creates and maintains a persistent, unified customer record accessible to other systems. The CDP owns the profile. The CDP takes responsibility for identity, record structure, governance, and downstream usability. What the CDP does not own is the source-of-truth obligation inside your CRM, your commerce platform, your ERP, or your ad accounts. Those systems still hold their own records. The CDP sits in the middle, stitching what it can, and the seams show.
The Myth of the Golden Record: Why CDPs Are Not Master Data Management
Salesforce says it out loud, and we wish more vendors did. Their documentation explicitly states that identity resolution can create actionable unified views but does not create golden records and is not a master data management system. That sentence alone is worth framing above the desk of anyone signing a CDP contract. A unified profile inside the CDP is not automatic write-back to your operational systems. It is not synchronization. It is a view.
This is where the budget meets the disappointment. We have watched brands spend meaningful sums — six- and seven-figure rollouts are common in mid-market and enterprise deployments — and then act surprised when the support team pulls up a ticket and sees a customer record that does not match what the CDP says about that same email. The support team is querying the helpdesk tool. The CDP is querying its own stitched profile. Both are correct, neither is the master, and nobody wants to fund the engineering work to actually reconcile them.
The cost framing here matters. A CDP is a middle layer. It eats integration hours, ongoing connector maintenance, identity-rule tuning, and activation feeds. If you bought it expecting MDM-grade source-system reconciliation, you bought the wrong product. Master data management is a separate discipline, a separate cost line, and a separate governance headache. Pretending the CDP covers both is how pilot deployments quietly stretch into multi-year programs, how scope creep becomes the norm, and how the finance team starts asking pointed questions at the QBR.
A unified CDP profile is a view, not a write-back. If your CRM and your commerce platform still disagree on who the customer is, the CDP is not going to fix that for you.
Identity Resolution Mechanics: How Platforms Decide Who Is Who
Strip away the sales deck and identity resolution is a matching engine with rules. Every CDP does it differently, and every implementation does it differently from the next one. That is the first operational reality most buyers miss: there is no industry standard for how a CDP decides that event A from the mobile SDK and event B from the web pixel belong to the same human.
mParticle's documentation is blunt about the failure mode. If an identification request contains no identifiers that match an existing profile, the platform creates a new anonymous profile based on the device ID. That is the default behavior. Anonymous traffic gets its own row, and unless something later identifies that device against a known user, it stays anonymous. Multiply that across millions of sessions and the "unified profile" starts to look like a folder of folders, with overlap you cannot prove and gaps you cannot close.
Adobe Experience Platform goes further with a guardrail that operators trip over constantly. If a single incoming experience event contains two or more identities with the highest namespace priority, Adobe rejects the entire event as bad data. One event, two top-priority IDs, the whole payload gets dropped. We have seen this surface in production as missing conversion events, missing attribution, and missing revenue in the dashboard. The fix is not a software patch. The fix is deciding, with the marketing and analytics teams in the same room, which identifier actually wins when a logged-in user fires an event from a shared device with a stored loyalty card.
The matching rules are configuration. That is not a flaw, that is the product. But every configuration choice carries a cost: an engineer to write it, a data steward to validate it, a quarterly review to adjust it. The brands getting real value out of identity resolution treat it like inventory reconciliation. You do it on a schedule, you log the exceptions, you accept that some shrinkage is permanent.
| Matching scenario | What typically happens | Operational cost |
|---|---|---|
| Known user logs in on a new device | Identifier matches existing profile, history merges | Low — handled by default rules |
| Anonymous browsing, no identifiers match | New anonymous profile created from device ID | Medium — creates duplicates you can never resolve |
| Logged-in user fires event with two top-priority IDs (Adobe) | Entire event rejected as bad data | High — silent attribution loss until someone notices |
| Cross-device journey, partial identifiers | Identity resolution depends on rule priority you set | Variable — depends on steward time |
The Conflict of Truth: Navigating Merge Policies and Dataset Precedence
Matching answers who is who. Merging answers whose version wins when two systems disagree on the same field. These are not the same problem, and confusing them is a common reason CDP rollouts stall in legal review.
SAP's Customer Data Platform documentation draws the line cleanly. Matching rules decide whether profiles from different sources belong to the same person. Merge rules determine which source wins when attributes conflict. An organization can designate some application identifiers as higher-priority and immutable. That word, immutable, is where the contract gets interesting. The moment a vendor promises you can lock an identifier, your data governance team needs to be in the loop. Locking the wrong field costs you re-ingestion, re-merging, and possibly a retroactive consent audit.
Adobe Experience Platform caps merge policies at five per organization. Five is not a lot once you start carving up the business. The slots typically go to:
- B2C consumer profile for ecommerce and lifecycle marketing
- B2B account-linked profile for sales-led motions
- Anonymous browsing profile for top-of-funnel personalization
- Loyalty member profile with stricter consent and retention rules
- Sandbox profile for testing new rules before production rollout
We have watched teams burn three of those slots within the first quarter because nobody aligned on segmentation strategy before the implementation kicked off. Each merge policy is also a manual ranking of which dataset you trust more. Adobe exposes two attribute-conflict methods: dataset precedence and timestamp ordering. Dataset precedence lets the organization rank trusted datasets manually. That is a human decision, and human decisions need a meeting, a sign-off, and a change log.
The cost math is direct. Every merge policy you create is another rule someone has to maintain, audit, and defend in a privacy review. Every dataset precedence choice is a statement about which upstream system you trust more, which has political weight inside the company. The CDP does not make these decisions for you. The CDP enforces whichever decision you feed it.
Operational Barriers: Why Ingestion and Enablement Gaps Persist
Buying the license is a small fraction of the work. The rest is ingestion, schema, and enablement, and this is where most of the deadhead miles get burned. The license gets you a contract and a login. The integration work gets you a working system, and that is the longer road by a wide margin.
Adobe's Real-Time Customer Profile documentation spells out the trap clearly. Adobe requires both the schema and each relevant dataset to be enabled for Real-Time Customer Profile. Records ingested before enablement are not included in profiles unless the data is re-ingested. That last clause is the cost bomb. Re-ingestion means rerunning connectors, replaying events, and paying for storage and compute that you already paid for once. We have seen brands absorb significant re-ingestion costs because enablement was treated as a checkbox rather than a phased rollout. Six-figure surprises are not unusual, especially when connector compute is metered.
Source ingestion is also uneven by design. Your commerce platform might push orders in near real time. Your ERP pushes inventory nightly. Your support tool pushes tickets on a webhook that drops when traffic spikes. Your loyalty system syncs weekly in a batch. The CDP receives all of it on different cadences, with different latencies, and the "real-time" claim on the sales deck quietly degrades to "near-real-time for two of our twelve sources." That gap shows up in personalization. A customer browses, abandons cart, and gets an email twelve hours later referencing an out-of-stock SKU the warehouse just replenished. The CDP worked. The ingestion cadence did not.
The operational parallel is the warehouse floor. You do not build a pick-and-pack line and assume the inbound dock will deliver on time. You staff for the worst case, you instrument the handoff, and you measure shrinkage. CDPs need the same discipline: source-by-source SLAs, ingestion monitoring, and a named owner for every connector. Without that, the platform becomes an expensive data lake with a friendly UI and a quarterly invoice.
The CDP is not the source of truth. It is the middle of the road between a dozen sources of truth, and every connector is a rest stop where data can get lost.
Governance and Compliance: The Hidden Constraints on Data Activation
This is the section most CDPs do not put on the sales call. Under the GDPR principles summarized by the European Commission, organizations must specify purposes for personal-data processing, process only data necessary for those purposes, keep it accurate and up to date, avoid incompatible reuse, retain it no longer than necessary, and apply appropriate technical and organizational safeguards. Every line in that list is a constraint on what you can do with the unified profile.
The cost of getting this wrong is not theoretical. It is a fine, a remediation order, and a marketing freeze while legal re-reviews every activation flow. The cost of getting it right is a privacy program that touches the CDP at the schema level, the consent level, the retention level, and the activation level. The brands we have watched scale CDPs cleanly built that program first, then wired the CDP into it. The brands that did it the other way around are still untangling consent records and answering auditor questions.
The hard operational fact is this: not every field in your unified profile is fair game for every channel. A loyalty tier collected under one lawful basis cannot be used as a lookalike seed for paid social under a different basis. An anonymous device profile cannot be matched to a known customer retroactively just because the matching engine now says it can. Privacy obligations follow the data, not the platform. The CDP is a steward, not a lawyer.
We also see brands underestimating the retention problem. The CDP will hold the unified profile for as long as you configure it to. That is dangerous. The longer you hold identifiable profile data, the larger the blast radius of a breach and the heavier the deletion-request workload. A retention policy that purges inactive profiles on a defined schedule — somewhere in the twelve-to-eighteen-month range is what we typically see in production — is not a technicality. It is a margin item, because every stored row costs storage, every deletion request costs labor, and every overdue retention check is a compliance liability sitting on the balance sheet.
The ROI Reality: What the CDP Actually Buys You
So what does a customer data platform buy you, in plain business terms? It buys you a place to put identity and attribute conflicts so they can be resolved once instead of in every downstream tool. It buys you a persistent record that your analytics, your ad platform, and your lifecycle email can all query against the same definitions. It buys you a governance surface where consent, retention, and purpose get enforced consistently.
It does not buy you master data management. It does not buy you automatic write-back to your CRM. It does not buy you guaranteed real-time sync across every source. It does not buy you the right to ignore schema enablement or merge policy trade-offs. And it does not buy you compliance with privacy law in any jurisdiction where you collect personal data.
The honest ROI calculation looks like this:
- License cost, annualized and divided across the activation use cases you actually plan to run.
- Integration hours for every source you intend to connect, plus the connector maintenance on top.
- Data steward time to own identity rules, merge policies, and dataset precedence choices.
- Storage and compute for the retention window you commit to under your privacy program.
- Minus the labor you save on manual reconciliation across marketing, support, and analytics tools.
- Minus the campaign performance lift you can credibly attribute to consistent segmentation and identity.
If the net is positive over a realistic payback window and you have a real activation use case feeding revenue, the CDP pays. If the net depends on MDM-grade reconciliation or automatic cross-system write-back, the CDP does not pay, and you will be writing a renewal objection letter in year two. Treat the customer data platform the way you would treat a new warehouse management system. It is operational infrastructure. It rewards process discipline. It punishes ambiguity. The brands getting real value out of theirs staffed it like a system, not a subscription, and they stopped expecting it to do a job it was never built to do.