Customer Insights – Data explained

Customer Insights – Data is Microsoft's customer data platform (CDP). It exists to solve a problem nearly every mid-to-large customer-facing business has: the same customer is represented dozens of times across different systems, in different shapes, with overlapping but partial data. CI–Data ingests it all, resolves the identities, and produces a single unified customer profile downstream apps can use.

Ingestion

Connectors pull data from Dynamics 365 (Sales, Service, Finance, Commerce, Business Central), Microsoft 365, Azure Data Lake, Synapse, Snowflake, Salesforce, Adobe, and dozens of other systems — or through Dataverse for native sources. Source systems can be polled on a schedule or streamed via APIs.

Unification

The core engine. CI–Data takes multiple customer-shaped tables (each with names, addresses, emails, phone numbers) and runs identity resolution — rule-based, ML-assisted matching of records likely to be the same person or organisation. Output is a unified customer profile that links back to all the source records.

Unification runs in three configurable stages: source field mapping (declaring which columns in each source mean "email", "phone", "name"), deduplication within each source, and matching across sources with ordered rules — exact match on email first, then fuzzy match on name plus postcode, and so on. Rule order matters enormously: a greedy fuzzy rule early in the sequence merges people who merely share a common name, and unpicking bad merges after downstream systems have consumed the profiles is genuinely painful. The working practice is to start with conservative exact-match rules, measure the unification rate, and loosen deliberately, reviewing samples of borderline merges each round. Expect this tuning to take weeks, not days — it is the actual work of a CI–Data implementation, and it's why "we'll just switch on the CDP" project plans slip. Data unification, in depth walks through match-rule design and golden-record creation in more detail.

Enrichment

Once unified, profiles can be enriched with first-party derived attributes (lifetime value, engagement score, churn risk) and third-party data (Microsoft's marketplace of providers — Acxiom, Experian, LinkedIn, weather, geographic). Enrichments are scheduled refresh jobs.

Segments and measures

Segments are query-built dynamic groups of unified customers ("high-value Swedish customers active in the last 30 days"). Measures are aggregate calculations ("total revenue per customer this quarter") attached to profiles. Both update as data flows through — measures and attributes, in depth covers the calculation logic, dependencies, and refresh behaviour behind them.

AI predictions

Out-of-the-box AI models predict churn, lifetime value, and product recommendations. Custom models can be brought in from Azure ML.

Outputs

Profiles, segments, and measures export to Customer Insights – Journeys (for marketing campaigns), Sales (as opportunity insights), Customer Service (for prioritisation and routing), advertising platforms (Meta, Google), and back to Dataverse for downstream automation.

Real-time

CI–Data supports both batch unification (the original mode, scheduled daily/hourly) and real-time signals (events streaming through as they happen, with profile updates within seconds).

Relationship to Journeys, Dataverse, and Fabric

Naming first, because Microsoft made it confusing: Customer Insights is sold as one product with two capabilities — Data (this article, the CDP) and Journeys (the marketing automation app, covered in Customer Insights – Journeys explained). They share a licence but are architecturally distinct, and plenty of customers run Journeys against plain Dataverse contacts without ever implementing Data.

Under the hood, CI–Data's storage and compute have been converging with Microsoft Fabric — profiles and enriched tables can live in OneLake and be queried from Fabric workloads directly, which matters if your analytics estate is already heading that way. If your problem is analytical ("build a customer 360 for reporting"), a lakehouse plus semantic model may serve better and cheaper; CI–Data earns its licence when the unified profile must flow back into operational systems — journeys, agent desktops, routing. That boundary is explored in customer data platform vs data warehouse.

Where it fits

CI–Data shines when a business has multiple customer-facing systems whose data isn't natively joined. It is overkill for a single-system shop. Implementation is non-trivial — identity resolution rules need iteration to land cleanly — but the resulting unified profile transforms downstream segmentation and personalisation.

Three honest prerequisites before buying:

• Source data quality. Identity resolution cannot conjure matches from systems that never captured email or phone consistently. If the sources are dirty, budget a cleansing phase first — the CDP amplifies whatever it's fed.
• A named owner. Unification rules, enrichment refreshes, and segment definitions drift without a steward. CI–Data is a product someone runs, not a project someone finishes.
• A consuming use case on day one. The fastest failures are "build the 360 first, find uses later" programmes. Pick one concrete consumer — a suppression segment for Journeys, churn-risk flags on the service desktop — and implement toward it. More on the marketing-side plumbing in real-time marketing data integration.