Updated recently
Last updated:
Quick Answer: This dynamics 365 customer insights guide, in one pass: Dynamics 365 Customer Insights is the customer-data and analytics app in the Dynamics family. It ingests data from Dynamics 365 apps, outside systems and streaming events, maps that into a unified customer profile through entity mapping and identity resolution, and then lets you slice it with segments, measures and KPIs. Everything else — Copilot analysis, relationship graphs, audiences for campaigns — sits on top of that model, and the model is where the real work and the real failures live.
For the wider platform context — how this app fits among the Dynamics family, what a tenant costs, what sits next to what — read our Dynamics 365 complete guide for 2026 first. This post goes one level deeper into one app only.
The Pipeline, in the Order It Actually Runs
Almost every implementation problem traces back to a stage that was skipped. So it is worth being precise about the order, because it is not the order people expect.
- Sources. Where data enters: Dynamics 365 entities (Sales, Marketing, Service, Customer Service), Dataverse tables, files, Power Query connections, and streaming events for near-real-time behaviour.
- Data map. The schema you define of what exists — tables, columns, types, relationships. This is the source of truth for the model.
- Entity map. Which tables represent which business concepts, and how they relate. This is where “customer” and “contact” stop being two table names and become two roles in one model.
- Identity resolution. The rules that decide when two records are the same real-world person or organisation.
- Data model and measures. The analytical layer: relationships, measures, calculated columns, KPIs.
- Segments. Saved, reusable audiences defined over the model.
- Consumption. Relationship graph, Customer Insights – Journeys audiences, Dashboards for Apps, or a Power BI report over the model.
Note that steps 3 and 4 are separated on purpose. Lots of teams try to solve identity resolution with clever entity mapping, and then spend six weeks fighting a matching problem that was never a mapping problem. Mapping says “these two tables are about the same thing”. Resolution says “these two rows are the same customer”. Different jobs, different failure modes.
Entity Mapping vs Data Mapping: The Distinction That Saves Projects
| Aspect | Data map | Entity map |
|---|---|---|
| Question it answers | What data do we have, and what shape is it in? | What does that data mean in the business? |
| Built from | Physical sources — tables, columns, file headers | Business concepts — customer, account, opportunity, product |
| Owner | Data engineer / analytics team | Business owner or product owner, with the analyst |
| Typical failure | Silent type drift, columns renamed upstream, no primary key | Two people mean different things by “customer”; the sales team says account, the service team says contact |
| How you spot it is wrong | Row counts that do not reconcile with the source | Two segments that should overlap return zero records |
The classic failure is naming. If the business says “customer” but the CRM has accounts, contacts and leads, and the e-commerce platform has its own customer table, then deciding which of those is the “customer” entity is a business decision, not a technical one. Teams that skip that conversation end up with a model where a person can be simultaneously a contact and a customer with two different profile records, and no amount of matching rules fixes a vocabulary dispute.
Identity Resolution: The Rules That Decide Who You Are
Resolution runs as an ordered set of rules. Order matters enormously — a fuzzy email match evaluated before a deterministic loyalty-ID match will happily merge two people who share a family email address.
| Rule type | How it matches | Strength | Where it bites |
|---|---|---|---|
| Deterministic — exact key | Exact match on a stable identifier | Highest | Works when the identifier truly never changes. Make this your first rule, not your last |
| Deterministic — normalised field | Exact match after normalising case, spaces, country codes, phone formats | High | Fails quietly on unnormalised formats. Normalisation is the actual work |
| Fuzzy — field similarity | Similarity scoring on a name, email or address | Medium | Merges family members, shared business addresses, typos that are not typos |
| Manual / curated override | Human-reviewed merges and exclusions | Definitive | The only reliable way to unmerge a bad fuzzy match. Also a process you have to staff |
Three practical rules that came out of real projects. First, always keep a deterministic rule on an identifier that is genuinely stable, even if it is ugly — a loyalty number, a national ID hash, an account-plus-postcode composite. Fuzzy matching should confirm, not discover. Second, quarantine what you cannot match rather than forcing it into a profile; unmatched records are usually a data-quality problem owned by somebody else, and pretending otherwise buries it. Third, log your merges. When a marketing team asks why a customer’s lifetime value dropped by half, “the model merged them with the wrong person” is a much better answer than silence.
Measures, KPIs and the Analytical Layer
Measures are calculated values defined once and reused — lifetime spend, order count in a window, average days between orders, active-in-last-N-days. The point of defining them centrally, rather than in reports, is that a segment, a journey audience and a dashboard all need to agree on what “active” or “high value” means. When those definitions drift apart, you get the classic board-level argument where marketing reports 40,000 active customers and finance reports 26,000, and neither team is lying.
The KPI layer sits above measures and is what most dashboards are built on. In practice, the useful KPIs in a retail or BFSI estate are a short list — customer lifetime value, purchase frequency, average order value, retention, share of wallet, and time since last interaction. Everything else is a candidate measure waiting for someone to ask for it. The governance job, not the build job, is deciding who owns each definition.
Here is a conceptual illustration of what a measure definition and a segment rule look like when written down for review. It is a documentation format, not a literal export from the product, and it is deliberately boring — boring documentation is what stops two teams defining “active” differently:
MEASURE ActiveCustomer
Definition customer has >= 1 completed order in the last 90 days
Owner Head of Customer Data
Depends on Orders (status = Completed, orderDate)
Excludes test accounts, cancelled orders, wholesale channel
Effective 2026-04-01, reviewed quarterly
SEGMENT HighValueRepeatBuyer
Definition ActiveCustomer
AND LifetimeSpend >= 100000
AND OrderCountLast12M >= 4
Depends on ActiveCustomer, LifetimeSpend, OrderCountLast12M
Owner CRM Lead
Refresh near real time where streaming events are enabled
Known gaps wholesale customers not modelled (open, Aug 2026)
The “known gaps” line is the part that matters. A segment definition without a named owner and a known-gaps field is a spreadsheet with a nicer name, and it will be trusted by a campaign team for about two months before someone notices the gap.
Segments, the Relationship Graph and Where Audiences Go
Segments are saved audiences over the model, refreshable on a schedule or, where streaming events are enabled, in near real time. They are the hand-off point between the analytics app and everything downstream — a segment becomes an audience in Customer Insights – Journeys, a target for a campaign, a filter on a dashboard.
The relationship graph is the visual tool for the model itself: entities as nodes, relationships as edges, and the ability to see how many records sit between two concepts. It is genuinely useful in a first workshop with a business team, because it makes a vocabulary disagreement visible in seconds instead of through a slide deck. It is not a substitute for a data model design document, and it does not show you measures.
On the consumption side, be honest about what people actually build. The most common production pattern is a Customer Insights model feeding a Power BI report for the commercial team, plus a handful of segments pushed into Journeys for campaigns. The model itself is rarely a front end for ad-hoc exploration. That is why the reporting craft still matters more than most job ads admit, and why our Dynamics 365 Customer Insights salary guide prices this work closer to analytics pay than to product pay.
Copilot and Generative Analysis: Useful, and Smaller Than the Marketing
Copilot in Customer Insights adds generative analysis over the model — asking a question in natural language and getting an answer built from your measures and segments, plus narrative summaries of segment behaviour. It is genuinely useful for the “why did this segment spike” question and for a first-pass read on a large segment.
What it is not is a replacement for defined measures and a governed model. If the model has two conflicting definitions of a customer, Copilot will answer confidently using whichever one it finds first, and it will do so in prose that sounds more authoritative than a SQL error would. The rule I give teams is simple: fix the model first, then let Copilot summarise it. Copilot will not tell you the model is wrong; it will narrate it.
War Story: The Segment That Renamed a Quarter
A Bengaluru SaaS company in 2025 ran a churn-prevention programme built on a Customer Insights segment. In Q3 the churn number rose 4 points, and by the end of the quarter the programme was being blamed. The model had not changed. What had changed was a new rule added by the analytics team in June: to “reduce noise”, they started excluding customers who had more than three open support cases, on the theory that heavily contacted customers were being over-counted as active.
That exclusion removed exactly the population the programme existed to save. Churned customers with three support cases were no longer in the churn segment at all, so the programme stopped reaching them. The KPI had not improved — the denominator had been quietly edited, and the people who benefited from the edit were the analysts who had built the segment.
The fix had three parts, and the third is the one worth remembering. Add a mandatory “owner” and “known gaps” field to every segment definition, which would have surfaced that the exclusion was someone else’s population being removed. Add a change log with a reviewer, so a model change that moves a KPI by more than a threshold requires a second pair of eyes. And — the cultural fix — agree a reporting standard where any segment feeding a commercial target has a named business owner who signs off changes. The analytics team did not do anything wrong by an engineering standard. They did something wrong by an operating standard, and the operating standard did not exist.
The lesson generalises: in a customer-data platform, model changes are business decisions wearing a technical costume. Governance over change is not bureaucracy; it is the difference between a platform that is trusted and one that quietly becomes wrong.
Training Resources
Most of the analytical layer of Dynamics 365 Customer Insights — measures, relationships, segmentation logic, and the Power BI reports that consume the model — is Power BI work. SkilBrill Power BI Training covers data modelling, DAX, Power Query and Copilot-assisted analysis with hands-on labs, which is the fastest way to build the reporting and modelling portfolio this app is assessed on.
FAQ
What is dynamics 365 customer insights guide covering first?
Start with the data map and entity map. Those two define what your sources contain and what they mean in the business, and every later stage — identity resolution, measures, segments — inherits mistakes made there.
How does identity resolution work in Dynamics 365 Customer Insights?
As an ordered set of rules that decide when two records represent the same real person or organisation. Put a deterministic rule on a genuinely stable identifier first, use normalised exact matches next, use fuzzy matching only to confirm, and quarantine records you cannot match rather than forcing them into a profile.
Do I need Power BI to use Dynamics 365 Customer Insights?
For consumption, effectively yes — most estates feed the model into Power BI dashboards, and the model itself is not a strong ad-hoc exploration tool. For building, you also need SQL and data modelling skills. That overlap is why BI analysts move into this space more easily than pure Dynamics consultants do.
What are segments in Customer Insights used for?
They are saved, reusable audiences over the data model. The main downstream consumers are Customer Insights – Journeys campaigns, dashboards and reporting filters, so segment definitions are really business contracts about what a customer is.
Does Copilot replace the need for a governed data model?
No. It summarises and analyses whatever the model already contains, including its inconsistencies, and it does so in confident prose. Fix definitions and ownership first; use Copilot to read the model, not to define it.
