Choosing between a CDP and better Dataverse modelling

What it does

Customer Insights - Data takes rows from several source tables and resolves them into one Customer table with a stable CustomerId, using four stages: select customer data, deduplicate, match across tables, then build the unified view. Dataverse on its own gives you contacts and accounts with whatever keys you maintain by hand. The decision in front of you is whether identity resolution is a real problem for this client or a modelling problem they've never sat down and solved.

Key facts

Unification runs in a fixed order — Customer data, Deduplication, Matching rules, Unified data view. You can't skip a stage, and each one constrains the next.
CustomerId stays the same between unification runs except when profiles merge or split following a data or rule change. PreviousCustomerId carries the old value so you can trace it.
Customer Insights - Data installs into a Dataverse environment, and each Dataverse environment can hold only one installation.
A Dataverse data source only shows tables with change tracking enabled. Out-of-box tables have it on; custom tables usually don't.
Dataverse keeps its Delta log for 48 hours. If a scheduled refresh doesn't run inside that window the stored version expires and downstream unification, segments, measures and exports fail until you run a full refresh.
Segment membership syncs back to Dataverse as msdynci_segmentmembership, which is how Journeys and model-driven apps see the results.
Active segments and active measures share a combined limit of 1,000, and a measure copied to Dataverse is capped at 10 million rows.
System refresh is daily or weekly with up to four times per day. Sandbox environments don't support scheduled refreshes at all.
Customer Insights roles (Viewer, Contributor, Administrator, environment owner) map onto Dataverse security roles, so access is governed in the same place as the rest of the Power Platform estate.
Licensing sits at tenant level with add-on capacity through volume licensing — it is not a per-user add-on you can quietly slip onto an existing Sales agreement.

When to use / skip

Default answer: if all the customer data lives in one Dataverse organisation and the "duplicate customer" complaint is duplicates inside that organisation, you don't need a CDP. Fix it with alternate keys, duplicate detection rules, a merge process people actually follow, and a data model where contact-to-account and contact-to-household are modelled properly. I've seen a £200k CDP business case that was really a three-week data quality piece plus somebody owning the contact table.

Bring in Customer Insights - Data when there are three or more systems that each mint their own customer identity with no shared key — a commerce platform, a loyalty database, a service desk, a finance system — and someone downstream genuinely needs them joined at the person level. The fuzzy matching, the normalisation library and the stable CustomerId are the things Dataverse won't give you, and hand-rolling them in Power Query or a Fabric notebook takes far longer than clients expect.

The other case for the CDP is organisational rather than technical: nobody owns the customer record, and every department has built its own definition. A CDP is a forcing function for that argument, because you cannot configure the matching stage without deciding which system is the primary table. That's a legitimate reason to buy it. Be honest with the client that they're buying a governance forum with software attached.

Skip it if the client wants one thing — a single marketing list, say — and the source systems already share an email address as a de facto key. Skip it too where the real need is reporting rather than activation; that's a Fabric or Power BI conversation, not a CDP.

Configuration decisions

Which Dataverse environment hosts the installation, given the one-install-per-environment rule and that this ties you to that environment's region, security groups and lifecycle.
Customer Insights managed storage or your own Azure Data Lake Storage Gen2 — the latter gives you control over where data sits but forces every environment onto the same region.
Where deduplication happens: inside each source system before ingestion, or in the CI Data Deduplication stage. Doing it upstream is usually cheaper and helps the source system too.
Which system is the primary table for matching, which is the same question as which system the business treats as the master customer record.
Whether unified profiles and measures are written back into Dataverse for use in model-driven apps, and who then answers for their accuracy on screen.
Who holds Contributor, since that role can rerun unification and change the shape of every profile downstream.

Gotchas

One Customer Insights - Data installation per Dataverse environment is a one-way door in practice. Picking the wrong environment early means an environment rebuild later.
Own-storage deployments lock all environments to one region. Multinational clients hit this when they later want an EU and a US environment.
The 48-hour Dataverse Delta log window bites during holidays and change freezes. A paused refresh schedule over Christmas turns into a full reload in January.
Rule changes can split one profile into several. The retained profile keeps the original CustomerId and the others get new ones, which quietly breaks anything downstream keyed on CustomerId.
Segments that aren't used in an export, measure, another segment or Journeys for 45 days or more get auto-deactivated. Demo segments built during UAT go stale exactly when the client goes looking for them.
Sandbox environments not supporting scheduled refreshes surprises teams who planned a like-for-like test cycle.

Consultant notes

Ask for the actual duplicate rate before quoting anything. Run a quick match on email and normalised name across the two biggest sources. If it comes out under a few percent, say so, and rescope to data quality work.
Demo the Matching rules screen, not the dashboards. The dashboards sell the idea; the matching screen is where the client realises how much of their own data they don't understand.
Push back hard on "we'll unify everything in phase one". Get agreement on the primary table in writing before build starts.
Before go-live, confirm the refresh schedule runs at least once inside every 48-hour window, and that someone is named as owner of the unified profile — not a team, a person.

Worth revisiting if Microsoft changes the one-installation-per-Dataverse-environment rule, or if the licensing model shifts away from tenant-level capacity.