Six things retailers actually run on their data: demand forecasting, replenishment and allocation, markdown and pricing, personalisation and recommendation, returns and fraud, and availability analysis. For each this sets out the data it needs before it can work, how you would prove it worked, and the conditions under which it fails.
Scroll
The use cases
01
Demand forecasting
Forecast what will sell, by product and location, far enough ahead to act.
Sales history, seasonality, price, promotions and calendar effects project demand per SKU and store. It matters only where it changes a commitment — what you buy, what you make, what you move, how you staff.
What it needs
History at the grain you plan at. A chain total does not help a store manager order.
Out-of-stock periods marked, or the model learns your shortages as low demand and reorders the shortage.
Promotions and price changes as a dated record, not reconstructed from memory.
Calendar effects that matter locally — festivals, school terms, paydays — which in India move against the Gregorian calendar and wreck a model that assumes otherwise.
How you would know it worked
Against your current method on the same SKUs and stores over the same window, using an error measure agreed before you start. Published comparisons favour tree-based ensembles over deep learning on real supermarket data, so start with the simpler thing and make the complicated one earn its place.
Where it fails
On short life-cycles and new products, where there is no history to learn from and the model is confidently extrapolating from something else. It also fails when it is scored on forecast error while the business is judged on availability, so the two never agree about whether it worked.
02
Replenishment and allocation
Send the right quantity to the right place before it sells out.
Forecast, current stock, lead times and shelf capacity decide order quantities and how a delivery is split between stores. This is arithmetic on top of a forecast rather than a model in its own right, and it is where forecasting either pays or does not.
What it needs
Stock accuracy at store level. Where the book says three and the shelf has none, every downstream decision is wrong and no forecast fixes it.
Real lead times including the variance, not the agreed service level.
Shelf capacity and case sizes, or the system will order what will not fit.
How you would know it worked
Availability and stock cover together, plus waste for anything perishable. Availability alone is trivially improved by holding more of everything.
Where it fails
On inventory record accuracy, almost always. This is a counting and process problem rather than an analytical one, and it defeats more replenishment projects than every modelling issue combined.
03
Markdown and pricing
Decide when to cut, and by how much, while it still sells.
Sell-through rate, remaining stock, time left in the season and price elasticity where it can be estimated decide markdown depth and timing. The prize is not a lower markdown but a smaller residual.
What it needs
Clean price history, including what was actually charged after every promotion rather than the list price.
Enough price variation to estimate elasticity. If a line has never moved in price, the data cannot tell you what would happen if it did.
Season end dates and residual disposal costs, or the model has no deadline to optimise against.
How you would know it worked
Gross margin after markdown and residual units, against a comparable prior season. Reporting one without the other is how a markdown programme claims success while the stockroom fills.
Where it fails
When elasticity is estimated from promotional periods and applied to base pricing. The two behave differently, and a model that conflates them will recommend cuts that buy volume you already had.
04
Personalisation and recommendation
Show a customer something they would not have found on their own.
Browse and purchase behaviour rank what to show. The commercial question is not whether it lifts click-through but whether it lifts basket value — recommending what somebody was going to buy anyway is easy and worth nothing.
What it needs
Behaviour joined to a persistent customer identifier across sessions and devices.
A cold-start answer for new customers and new products, which is most of the catalogue in most retailers.
A consent position that matches what you actually do with the data, because the privacy policy is part of the system.
How you would know it worked
A holdout that sees no recommendations, measured on incremental basket value rather than click-through. Attribution without a holdout will credit the recommender with sales it did not cause.
Where it fails
By collapsing onto the popular. A recommender optimised on click-through learns to show bestsellers, which raises the metric and adds nothing a category page would not have done.
05
Returns and refund abuse
Separate a genuine return from a pattern of abuse.
Return rates by customer, product and reason code identify both the products that are failing customers and the small number of accounts systematically abusing the policy.
What it needs
Reason codes that staff actually use, which means few enough to be picked honestly under time pressure.
Returns joined to the original order and the customer, including guest checkouts.
Product-level return history, because a high rate is often a sizing or description problem rather than a customer problem.
How you would know it worked
Return rate by cohort against the change made, and abuse recovered. Watch the false-positive cost carefully: accusing a good customer of fraud is expensive in a way no dashboard shows.
Where it fails
When it is treated as a fraud problem first. Most excess returns are caused by inaccurate product information, and a model pointed at customers will never find that.
06
Availability and phantom stock
Find the lines the system thinks are in stock and the shelf does not.
Sales patterns that stop abruptly while stock-on-hand stays positive identify likely phantom inventory — the book says you have it, the shelf disagrees. No machine learning required, and frequently the highest-value thing on this list.
What it needs
Sales at a daily grain per store and SKU.
Stock-on-hand snapshots on the same clock as the sales.
A process for someone to check a flagged line, which is the part that gets forgotten.
How you would know it worked
The share of flagged lines confirmed as wrong when somebody physically checks. If most flags are correct, this pays for itself immediately; if not, the rule needs tuning before anyone is sent to look.
Where it fails
When nobody is assigned to check. A phantom stock report that nobody walks the aisle for is a list of known problems, which is worse than not knowing because it removes the excuse.
Before any of it works
Every use case above assumes these. Where one is missing, it is the project — not a prerequisite to be waved through in a kick-off meeting.
Replenishment, allocation, availability and forecasting all inherit inventory accuracy. Where the book and the shelf disagree, every one of them is optimising against a fiction — and this is a counting and process problem, not an analytical one.
Sales history with unmarked stock-outs understates demand exactly where demand was highest. A forecast trained on it reorders the shortage, and the error compounds every cycle it is not corrected.
Personalisation, returns analysis and lifetime value all need behaviour joined to a person rather than to a session. Where guest checkout and app and web produce three unlinked identities, none of them can be built honestly.
Festivals, school terms and paydays move demand more than most seasonality, and in India they move against the Gregorian calendar. A model that has only seen month numbers cannot learn them, and will be wrong in the same weeks every year.
Questions people ask
The published evidence says start simpler. A study using six years of daily demand from an Austrian supermarket — over 330 products and 5.2 million records across fruit, fresh meat and soft drinks — found tree-based ensembles outperforming LSTM deep learning on every metric reported, with the widest gap on fresh meat. That is one retailer in one country, so treat the direction rather than the margin as transferable. But it is a good reason to make the complicated model beat the simple one on your own data before buying it.
Inventory accuracy, and unmarked stock-outs. If the book says three and the shelf has none, every replenishment decision downstream is wrong regardless of forecast quality. And a sales history that does not record when you had nothing to sell teaches the model that demand was low exactly when it was highest.
By holding out a group who see no recommendations, and measuring incremental basket value rather than click-through. Click-through rewards showing people what they were already going to buy. Without the holdout, attribution credits the recommender with sales that would have happened anyway, which is why almost every reported uplift figure is larger than the real one.
Because that is what optimising click-through selects for. Popular items get clicked, the model learns to show them, the metric improves and the recommender ends up doing the job a category page already did. If the output looks like your top-sellers list, the objective is wrong rather than the algorithm.
With phantom stock: finding lines the system believes are in stock while sales have stopped dead. It needs no machine learning, only daily sales and stock snapshots on the same clock, and it usually surfaces available sales nobody knew were being lost. It also proves whether anyone will act on a report, which is worth knowing before commissioning a forecasting programme.
A Data Health Check runs these questions against your systems rather than your sector: what you have, what it would support today, and what the first useful thing would take.