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/05-predictions-and-ai/feature-prediction-transactional-churn.md
feature-prediction-transactional-churn.mdv1 · history
CurrentApplies to InsightsUpdated 6 days agoSource Microsoft Learn ↗

What it does

Transactional churn prediction scores every unified customer on how likely they are to stop buying within a window you define. You tell it what "churned" means for your business — a number of days with no purchase — and how far ahead to look, and it produces a churn probability per customer profile.

Key facts

  • Out-of-box model, generally available, configured under Insights > Predictions > Create. No Azure subscription or data scientist needed.
  • Contributor permissions or higher on the environment to create or edit a prediction.
  • Minimum 500 customer profiles, and Microsoft's own guidance is that 1,000+ works considerably better. Fewer than that and the model will still run, but the grade will tell you what you already suspect.
  • You need at least two transactions per customer, ideally more, spread across different dates. Single-purchase customers carry almost no signal.
  • Transaction history has to cover at least double the prediction window; two to three years is the realistic ask if you want seasonality picked up.
  • Required transaction fields: transaction ID, transaction date, transaction value, customer identifier, product ID (for line-level data) and a return indicator (boolean, or negative values you flag as returns).
  • Transaction data is mapped through the semantic activity types SalesOrder or SalesOrderLine. If your data isn't mapped semantically, you map attributes during setup.
  • Less than 20% missing values in the fields you supply. Above that, expect the input data usability report to flag it.
  • Customer activity data (web events, service interactions) is optional but is usually what moves the grade — primary key, timestamp, event name, event details.
  • Two configuration numbers drive everything: the prediction window (how far ahead, e.g. 90 days) and the churn definition (days of inactivity before someone counts as churned, e.g. 30 days).
  • Output table carries ChurnScore (0–1 probability) and IsChurn (binary, thresholded at 0.5).
  • Grades: A means at least 50% accurate predictions and churn accuracy more than 10% above the time-based baseline; B is the same accuracy floor with up to 10% above baseline; C means under 50% accuracy or below baseline. The baseline is a simple "hasn't bought in X days" business rule.
  • Retraining is scheduled — monthly is Microsoft's recommendation. Between retrains the model rescores on new data using the existing trained model.

When to use / skip

This is the model most retail, e-commerce and non-contractual B2B clients actually want, and it's the one most likely to survive contact with their data. Use it where purchases are repeat but irregular: consumables, spare parts, groceries, hospitality. If the client sells on contract or subscription, use subscription churn instead — the two are not interchangeable and transactional churn will produce nonsense on renewal data.

Skip it if the client has under a thousand profiles with transaction history, or if most customers have bought exactly once. A one-purchase-per-customer dataset has no repeat behaviour to learn from, and no amount of configuration fixes that. Also skip it, or at least defer it, if unification isn't stable — churn scores computed against a customer table that's still being remerged will move for reasons nobody can explain.

Where it genuinely earns its keep is when the client already runs a manual "hasn't ordered in 90 days" retention list. The grade tells you directly whether the model beats that rule. If it doesn't, that's a useful answer too, and cheaper than a data science engagement to find out.

Configuration decisions

  • Churn definition in days of inactivity — this is a business decision, not a technical one, and it should come from the retention team. Get it in writing.
  • Prediction window length. Ninety days is the common default, but it must match how long a retention campaign actually takes to run at that client.
  • Whether to feed line-level (SalesOrderLine) or header-level (SalesOrder) transaction data. Line level gives product signal; header level is faster and often enough.
  • Which activity tables to add beyond transactions, and whether the effort of ingesting them is justified by the grade improvement.
  • Retraining cadence and how it sits relative to the environment's data refresh schedule.
  • Whether downstream consumers use IsChurn at the default 0.5 threshold or the raw ChurnScore with their own cut-off. Most mature clients end up on the raw score.

Gotchas

  • The 500-profile floor is the floor for the model to run, not for it to be useful. Plenty of projects clear it and still land a grade C.
  • Not everyone in your customer table is an active customer. A large population that already churned under your own definition drags the training set and skews the distribution you show the client.
  • Returns matter. If refunds and cancellations aren't flagged, the model treats them as purchases and reads churning customers as loyal ones.
  • Full model creation takes hours on real data volumes. Do not schedule it in the middle of a demo, and do not assume a failed run is instant feedback.
  • Changing the churn definition or prediction window means a full retrain and a different score distribution. Any segment or campaign built on the old scores changes underneath the client without warning.
  • The input data usability report only appears after training finishes. You cannot pre-validate your mapping from it, which means the first run is effectively your data quality test.

Consultant notes

  • Run a transaction count per customer before you promise anything. Median transactions per customer and the percentage of one-time buyers tell you the outcome of this workstream more reliably than any workshop.
  • Demo the "most influential factors" panel, not the score. Business stakeholders trust the model when the drivers match what they already believe; the score alone reads as a black box.
  • Push back on churn definitions borrowed from a competitor or a blog. Thirty days is meaningless for an annual-purchase category.
  • Set expectations that grade C is a legitimate result and usually a data problem, not a modelling problem. Agree in advance what happens if you get one.
  • Before go-live, confirm someone owns the retraining schedule and knows that model output changes when it retrains. Scores are not stable identifiers.

Worth revisiting if Microsoft changes the minimum profile counts or adds tuning controls beyond the churn definition and window.

Was this accurate?
Related
Deciding whether the data justifies predictions10-decision-guidesSubscription churn prediction05-predictions-and-aiCustomer lifetime value prediction05-predictions-and-aiProduct recommendation prediction05-predictions-and-aiSuggested segments from activity and measures03-segmentsCustom models with Azure Machine Learning05-predictions-and-ai