Almanac
Microsoft/d365ci-dataDynamics 365

Consultant-focused KB for Microsoft Dynamics 365 Customer Insights – Data: implementation notes, gotchas, and configuration decisions beyond the official docs — across data unification, customer profiles, segments, measures and insights, predictions and AI, Dataverse integration, Copilot, and administration.

d365ci-data/10-decision-guides/feature-deciding-on-predictions.md
feature-deciding-on-predictions.mdv1 · history
CurrentApplies to InsightsUpdated 6 days agoSource Microsoft Learn ↗

What it does

Customer Insights - Data ships five out-of-box models — customer lifetime value, product recommendation, subscription churn, transaction churn and sentiment analysis — that train on unified profiles plus transaction or subscription history and write a score back onto each profile. You configure them rather than build them, which makes them easy to sell and easy to sell too early.

Key facts

  • The five out-of-box models are Customer lifetime value, Product recommendation, Subscription churn, Transaction churn and Sentiment analysis. Custom models can come from Azure Machine Learning or Azure Synapse.
  • General guidance is a minimum of 1,000 unified customer profiles; transaction churn will run from 500, though it also says preferably more than 1,000 unique customers.
  • At least 12 months of history is the stated floor, with two to three years preferred. Transaction churn wants history covering at least double the time window you select.
  • Transaction churn also expects ideally at least two transactions per customer.
  • Fields need less than 20% missing values.
  • Transaction data needs a transaction ID, transaction date, transaction value, a product ID where data is at line-item level, a returns flag (or negative values it can be inferred from) and a customer identifier that matches the unified profile Customer ID.
  • Churn definition window and prediction window are both numbers you enter — for example no purchase in 30 days counts as churned, predicted over the next 90 days.
  • Optional customer activity data needs a customer identifier, primary key, timestamp, event name and details.
  • Contributor role or higher is needed to create a prediction.
  • Models refresh manually or on a schedule; the guidance is that most businesses retrain monthly and get good accuracy.
  • The input data usability report gives errors, warnings and recommendations before you run — read it rather than clicking past it.
  • Prediction outputs can be used to build segments, which is where they actually earn their keep.

When to use / skip

Say no more often than you say yes. The out-of-box models are cheap to configure and expensive to live with when the underlying data doesn't support them, because a churn score that's wrong is worse than no churn score — the business acts on it and then stops trusting the whole platform.

My test is three questions. Does the client have two to three years of transaction history at customer level, not aggregated? Do most customers have more than one transaction? And is there a decision that changes based on the score — a retention offer, a call list, a budget allocation? If any answer is no, don't build the model. A client with 18 months of history, a single purchase per customer and no retention programme is not a prediction client, however keen they are.

Transaction churn is the one I'd usually start with for retail and B2C subscription businesses that clear those bars: the definition of churn is under your control, the required fields are ones a commerce system already has, and the output maps cleanly onto a segment and a campaign. Customer lifetime value is the one most often asked for and most often disappointing, because clients already have a CLV definition in a spreadsheet that the model won't reproduce, and the argument that follows is about the spreadsheet, not the model.

The opposite case: a client sitting just under the volume floor but with excellent, long history and a genuine retention programme. I'd still run it, treat the first quarter as a pilot against a holdout group, and tell them explicitly that the score is directional. Bad data with lots of rows is worse than good data with fewer.

Configuration decisions

  • Which model, and whether one is enough for phase one. It usually is.
  • The churn definition window and the prediction window, which are business definitions — how long silence means a lost customer — not technical settings.
  • Which transaction table feeds the model, and whether it's at line-item or order level, since that changes whether product ID is needed.
  • Whether returns are held as a flag or inferred from negative values, and whether refunds are currently netted off in a way that hides them.
  • Retraining cadence and who reviews the result, given monthly is the usual starting point.
  • Whether prediction output drives a segment and an export, or just sits on the profile as a number nobody uses.

Gotchas

  • The customer identifier in transaction data has to match the unified profile Customer ID. If unification changes and profiles split, historical transactions can drift away from the profile they trained on.
  • The 20% missing values threshold applies per field. One sparse but required column is enough to make the model unreliable while everything still runs.
  • Choosing a long prediction window without enough history quietly breaks the double-the-window rule for transaction churn, and the usability report is the only warning you get.
  • Sandbox environments don't run scheduled refreshes, so you can't rehearse the monthly retrain cycle like for like.
  • Predictions built on a segment that later gets auto-deactivated, or on a measure that gets rebuilt, produce scores whose lineage nobody can reconstruct six months on.
  • Clients read a probability as a certainty. A 70% churn score on a named customer will be shown to that customer's account manager, and you need an answer ready for that meeting.

Consultant notes

  • Run the input data usability report before you promise anything, and share it with the client as-is. It's the most persuasive document you'll have for pushing back on scope.
  • Demo the segment built from the prediction, not the score. The score is a number; the segment is a campaign, and that's what gets signed off.
  • Insist on a holdout group for the first campaign. Without it, nobody can tell you whether the model was worth the licence.
  • Agree up front who explains the model to the business, and make sure it isn't a slide that claims accuracy figures nobody measured.
  • Before go-live, confirm the retrain schedule exists and someone is named to look at the output each month. Unmonitored models age badly and quietly.

Worth another look if the minimum profile counts or history requirements change, or if new out-of-box models land in a release wave.

Was this accurate?
Related
Transactional churn prediction05-predictions-and-aiCustomer lifetime value prediction05-predictions-and-aiSubscription churn prediction05-predictions-and-aiProduct recommendation prediction05-predictions-and-aiCustom models with Azure Machine Learning05-predictions-and-aiSuggested segments from activity and measures03-segments