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

What it does

The product recommendation model produces a ranked list of products per unified customer, based on their own purchase history, what similar customers bought, and which products get bought together. Output is product IDs with a score, written to a table you can query or use downstream.

Key facts

  • Out-of-box model, generally available, created from Insights > Predictions > Create. Contributor permissions or higher.
  • Minimum 1,000 customer profiles within the prediction window; at least one year of transaction history, two to three years preferred so seasonality is picked up.
  • Ideally three or more transactions per customer ID. This is the highest repeat-purchase requirement of the out-of-box models, and it's the usual reason a client doesn't qualify.
  • A single transaction history table only. Multiple purchase sources need combining in Power Query first.
  • Required transaction fields: transaction ID, transaction date, transaction value, product ID, and a purchase/return flag (boolean, or inferred from negative values).
  • Purchase history maps through the SalesOrderLine semantic activity type — line level, not header level, because the model needs the product on each row.
  • Product catalogue: keep it under 50,000 products. Above that, effectiveness drops and processing time rises. The fix is to prune dead SKUs or roll up to a higher level of the product hierarchy.
  • Configuration includes the number of products to recommend, whether previously purchased items can be recommended again, and a look-back window (for example two years) that stops the model re-recommending something just bought.
  • Optional product filters restrict what appears in the output, using AND/OR logic. Filters apply to the output only — the model still learns from the full catalogue.
  • Grading uses a "Success @ K" metric against a baseline: A is 10% or more above baseline, B is 0–10% above, C is below baseline.
  • Results include top recommended products with counts, sample recommendations with confidence scores, data statistics, and the recommendation factors used (past transactions, customer similarity, product similarity).
  • Microsoft explicitly asks you to review recommendations before they reach customers, for legal, regulatory and appropriateness reasons.

When to use / skip

This model fits retail and e-commerce clients with a broad catalogue and customers who buy repeatedly across categories. It's a decent fit for merchandising-led email programmes and for populating a "you might also like" block where nothing better exists.

Be careful about scoping it as a replacement for a real recommendation engine. It's a batch model that scores on a schedule against unified profiles. It doesn't respond to session behaviour, it doesn't personalise on the fly, and it has no concept of what's in the basket right now. If the client is comparing it to their storefront's real-time recommender, you're going to lose that comparison and you should frame the difference up front.

Skip it entirely where the catalogue is tiny, where purchases are one-off, or where the products are regulated in a way that makes automated suggestion risky — financial products, medicines, age-restricted goods. The docs' review requirement is not boilerplate in those sectors.

Configuration decisions

  • How many products to recommend per customer, matched to where the output is actually rendered. Five recommendations for a template with three slots is wasted computation.
  • Whether previously purchased products are eligible. For consumables the answer is usually yes; for durables, no.
  • The look-back window that suppresses recently bought items. This is a category-level judgement and one number has to serve the whole catalogue.
  • Product hierarchy level to model at, especially if the SKU count is anywhere near 50,000. Modelling at style or category level often gives a better grade and more usable output.
  • Which product filters to apply to the output — excluding discontinued lines, out-of-stock items, or products the client can't fulfil in a given market.
  • How product IDs get resolved to names, images and localised content downstream, because the model returns IDs only.

Gotchas

  • The output is product IDs and scores, nothing else. Every project needs a mapping layer to turn that into something a customer can see, and it's rarely in the original estimate.
  • Filters constrain output but not learning. Consultants assume filtering to a category trains a category-specific model. It doesn't.
  • Stock and availability are not model inputs. Recommending sold-out or discontinued products is entirely possible, and needs handling in the filter or downstream.
  • SalesOrderLine mapping is mandatory in effect. Clients who only have header-level order data cannot run this model without reworking their ingestion.
  • Long catalogues quietly degrade the result rather than failing. You get a run, a grade and a set of recommendations that are simply worse, with no error to point at.
  • Recommendations refresh on the retrain schedule. Between retrains, a customer's list can go stale relative to what they just bought, depending on how rescoring lands against your look-back window.

Consultant notes

  • Get the SKU count and the distribution of transactions per customer before committing. Under three transactions per customer for most of the base, say so early rather than discovering it at grade C.
  • Demo the sample recommendations with confidence scores to merchandisers. They'll spot nonsense immediately, which is exactly what you want during build rather than after launch.
  • Push back on real-time expectations in writing. The phrase to use is batch scored on a schedule, not live personalisation.
  • Agree a human review step for the first few runs, and keep the client's brand and compliance people in it. Microsoft's own guidance asks for review, so it's an easy point to make.
  • Before go-live, check the ID-to-content mapping handles retired products, otherwise the campaign build will break on a recommendation for something that no longer exists.

Worth another look if the 50,000-product ceiling moves, or if Microsoft adds real-time or basket-aware scoring.

Was this accurate?
Related
Customer lifetime value prediction05-predictions-and-aiDeciding whether the data justifies predictions10-decision-guidesTransactional churn prediction05-predictions-and-aiSubscription churn prediction05-predictions-and-aiSuggested segments from activity and measures03-segmentsCustomer sentiment analysis05-predictions-and-ai