64% better stock accuracy by forecasting the town, not the store

A retailer was persistently understocked on certain products, in certain stores, at certain times. Not uniformly — which is what made it interesting. A chain-wide forecasting problem shows up everywhere at once. This did not.

Challenges

The pattern resisted the usual explanations. It was not seasonality, which the existing forecasts already handled, and it was not a supply problem, because the stock existed elsewhere.

A quick analysis found the correlation: stockouts had a direct relationship with events taking place near the retail outlet. A concert, a match, a festival, a convention — each one changes what a nearby store sells that weekend, and none of it appears in the store's own history in a way that generalises. Last year's demand spike is not repeatable knowledge unless you know why it happened.

The information existed, but outside the business entirely.

Data engineering

Event data from outside the business. Event information was extracted from third-party aggregators — the public listings services that catalogue what is happening where. Three years of history were loaded once, then a daily batch job kept it current.

Inventory data from inside it. The same treatment for the retailer's own inventory systems: three years extracted as a baseline, then a daily job.

A common format. Both sources were cleansed and converted into a "gold" format, from which aggregations and cubes could be built. This step is the one that makes the join possible at all — event feeds and inventory systems agree on nothing, least of all how to name a location or a date.

Data science

With events and inventory in one shape, models were trained to predict inventory requirements for future events — not a general demand forecast, but the specific question of what a known upcoming event near a specific store implies for stock.

That framing matters. Forecasting demand in general is hard and the retailer already did it adequately. Forecasting the delta attributable to a known future event is a narrower question, with a much better signal-to-noise ratio, and it slots into the existing planning process rather than replacing it.

Results

Measure	Outcome
Stock accuracy with respect to events	+64%
Revenue	+10%

Both figures are as recorded in the project's own documentation.

What we would take from this

The signal was outside the company. No amount of modelling on internal history would have found it, because the causal variable was never in the data. When a pattern resists explanation, the question to ask is what the business does not record.

A daily batch job was enough. There is no streaming here, no real-time anything. Events are known days or weeks ahead; the whole value is in foresight, not latency. Reaching for a real-time architecture would have added cost and delivered nothing.

Narrow the question. "Predict demand" is a research programme. "Predict the effect of this event on this store" is a project — and it was the one that moved the number.