Prescriptive Analytics

Prescriptive analytics recommends an action: which price to set, which customer to contact, how much stock to order, which claim to review. It goes beyond forecasting what will happen to proposing what to do about it, and that step requires three things a forecast does not.

An objective someone has stated

Maximizing revenue, margin, conversion, retention, or lifetime value will produce different recommendations from identical data. There is no neutral choice, and no analysis can make it — it is a business decision about what the organization is trying to do.

A system that recommends without a declared objective has one regardless, chosen implicitly by whoever implemented the scoring. That is the common case, and it surfaces later as an argument about why the model keeps suggesting discounts: it was optimizing conversion, and nobody said margin mattered.

Where several goals compete, the honest form is a stated trade-off — maximize margin subject to not letting conversion fall below a floor — rather than a weighted blend whose weights nobody can interpret.

Constraints that reflect reality

A recommendation the organization cannot execute is not an answer. Constraints worth writing down explicitly include budget and capacity, contractual and regulatory limits, fairness requirements, and the plain question of what the people receiving the recommendation are able and willing to do.

The last one is where prescriptive projects usually die. An optimizer that assigns each field engineer a route ignoring shift patterns and local knowledge produces schedules that are quietly overridden, and the override is invisible to everyone reviewing the model’s reported gains.

A causal model of the action

This is the requirement most often skipped, because a predictive model is available and looks sufficient. It is not. Recommending a discount requires knowing what a discount does, which is not the same as knowing what discounted customers did — they were selected for the discount by some process, and that process is in the data.

Hernán puts the methodological asymmetry plainly: “Automatic variable selection procedures may work for prediction, but not necessarily for causal inference.” A model can be highly accurate at predicting churn because it learned that customers who contact support three times are about to leave, and the action read out of it — reduce support contacts — is worse than doing nothing.

So a prescriptive system needs an estimate of effects, from experiments where they are feasible or from causal inference with stated assumptions where they are not. A predictive score is legitimate input to a prescriptive system — it can rank who to consider — but the decision about what to do to them is a separate question with separate evidence.

When to automate, and what automation does to your data

Automated decisions are appropriate where they are numerous, individually small, and reversible — pricing a shipping option, ordering routine stock, sequencing a review queue. Where a decision is rare, large, or hard to undo, the useful output is a recommendation with its reasoning presented to a person, and calling that “prescriptive analytics” is not a lesser achievement.

Automation also changes the data the system learns from, which is the failure mode specific to this category. Once recommendations drive actions, the record of what happened reflects the recommendations, so the system is increasingly trained on the consequences of its own choices and stops seeing what the alternatives would have done. Forecasting has a cousin of this problem — predictability depends partly on “whether the forecasts can affect the thing we are trying to forecast” — and in a recommendation loop it is not a special case but the normal condition.

Two countermeasures keep such a loop honest. Keep a share of decisions randomized or held back, so the effect of the recommendations remains measurable rather than assumed. And keep running experiments after launch, because a system that has stopped being evaluated is being trusted rather than working. Experimental knowledge is also narrower than it looks: the rules of thumb Kohavi and colleagues generalized from experiments at “Amazon, Booking.com, LinkedIn, and multiple Microsoft properties” include “Speed matters” — qualified by the observation that “certain areas of the web page are more critical” — a reminder that an effect established in one setting comes with the conditions it was established under.

Finally, measure the decisions rather than the model. Whether recommendations were followed, what happened when they were, and how outcomes compare with the held-back share are the only figures that show a prescriptive system is working. Model accuracy reported on its own says the model predicts; it says nothing about whether the organization is better off.

How prescription relates to descriptive, diagnostic, and predictive questions is worked through in What Kind of Question Is It?.

References: Hernán, The C-Word, American Journal of Public Health 108(5), 2018; Kohavi, Deng, Longbotham & Xu, Seven Rules of Thumb for Web Site Experimenters, KDD 2014; Hyndman & Athanasopoulos, Forecasting: Principles and Practice (3rd ed.), §1.1.