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-customer-lifetime-value.md
feature-prediction-customer-lifetime-value.mdv1 · history
CurrentApplies to InsightsUpdated 6 days agoSource Microsoft Learn ↗

What it does

The CLV model predicts how much revenue an active customer will generate over a future period you set, in months. It scores active customers only, and it also classifies who counts as high value against a threshold you either let the model calculate or set yourself.

Key facts

  • Out-of-box model, generally available, under Insights > Predictions > Create. Contributor permissions or higher.
  • Minimum 1,000 customer profiles within the prediction window, with less than 20% missing values in required fields.
  • Transaction history: at least one year, preferably two to three, and ideally two to three or more transactions per customer across multiple dates. Repeat purchase behaviour is what the model learns from.
  • Required transaction fields: customer identifier, transaction ID, transaction date, transaction amount, product ID and a return label (boolean).
  • Only one transaction history table can be configured. If purchases live in several systems, you merge them in Power Query before the model sees them. This is a hard limit, not a recommendation.
  • Transaction data maps through the SalesOrder or SalesOrderLine semantic activity types.
  • Customer activity data is optional but recommended — web activity, loyalty, service logs. Customer profile attributes can also be added, up to 18 commonly used attributes.
  • Three configuration choices: prediction period in months, the definition of an active customer (auto-calculated is the recommended option, or set the purchase interval yourself), and the high-value threshold (model-calculated on an 80/20 basis, typically landing at 30–40% of customers, or your own percentile).
  • Grades compare against a baseline of average monthly purchase × prediction months × overall retention rate. Grade A means the model identified at least 5% more high-value customers than that baseline; B is 0–5% better; C is worse than baseline.
  • Reported metrics include a success rate (share of high-value customers correctly captured) and RMSE for prediction error.
  • Results show a value-by-percentile histogram and the most influential factors alongside the grade.
  • Retraining is scheduled; monthly is the recommendation. Runs take several hours on real volumes.

When to use / skip

CLV is the model clients ask for by name and the one most likely to be misunderstood. Use it where there's a real repeat-purchase business and marketing wants to spend differently on different customers — retail, e-commerce, hospitality, direct-to-consumer. It works well as the input to a tiering exercise, and the high-value classification is often more useful operationally than the predicted currency figure.

Skip it if the client wants a lifetime figure in the accounting sense. This predicts a bounded future window, not a customer's whole economic life, and the gap between those two things has derailed more than one steering committee. Skip it too if purchases are one-off big-ticket items with no repeat pattern, or if the finance team already has a CLV model they trust — competing numbers with different definitions is a fight you won't win and shouldn't start.

If the client's real question is "who should we not spend on", the churn models usually answer it faster and with less argument about the money.

Configuration decisions

  • Prediction period in months. It must be backed by comparable historical depth, so a 12-month prediction on 14 months of data is not a serious configuration.
  • Active customer definition: accept the auto-calculated purchase interval or impose one. Imposing one is only right when the business has a defined lapse rule already.
  • High-value threshold: model-calculated 80/20 or a fixed percentile. Fixed percentiles are easier to explain to a marketing team but can cut across the natural distribution.
  • Whether transaction amount is revenue or margin. The model takes whatever you map, and the client's interpretation of the output depends entirely on this choice.
  • Which optional profile attributes and activity tables to include, weighed against ingestion effort.
  • The Power Query consolidation approach for multiple transaction sources, since only one table can be configured.

Gotchas

  • The single transaction table limit is the one that bites during build. Discover it during design, not two sprints in, or you'll be re-cutting your data model under time pressure.
  • Only active customers are scored. Anyone outside the active definition simply doesn't appear in the output, and clients read missing rows as a bug rather than a design decision.
  • Feeding gross revenue and then presenting the result as profitability is an easy and expensive misunderstanding. Fix the wording in the first workshop.
  • Returns and refunds not flagged with the return label inflate value for exactly the customers you should be worried about.
  • Changing the active-customer definition or the high-value threshold changes both the population and the tiering. Segments and campaign lists built on the previous settings move without notice.
  • Grade C here means the model didn't beat a fairly crude arithmetic baseline. That's worth saying out loud, because it means the client can keep using their existing average-based calculation.

Consultant notes

  • Agree the phrase "predicted value over the next N months" as the client-facing term from day one. Do not let "lifetime value" survive into the reporting layer unqualified.
  • Demo the percentile histogram. It answers the actual business question — how concentrated is our value — better than any individual score, and it lands well with commercial stakeholders.
  • Push back on requests to predict 24 or 36 months ahead unless the history genuinely supports it. Long windows produce confident-looking numbers with no basis.
  • Check the influential factors against the client's merchandising view. Where they disagree, it's usually a mapping error on transaction amount or an unhandled returns feed.
  • Before go-live, confirm who reconciles the model output with finance's own numbers. That conversation happens eventually; better it happens on your terms.

Worth revisiting if Microsoft lifts the single transaction table restriction, which is the main design constraint on this model today.

Was this accurate?
Related
Deciding whether the data justifies predictions10-decision-guidesSubscription churn prediction05-predictions-and-aiProduct recommendation prediction05-predictions-and-aiTransactional churn prediction05-predictions-and-aiSuggested segments from activity and measures03-segmentsMeasure types and where the results actually land04-measures-and-insights