Case Study · Retail
Defacto DISCO: if I give this product that price, how many units sell in 14 days?
A system that grounds the markdown decision in a forecast: an XGBoost model learning, for every product whose price changes, the units sold in the next 14 days from stock, broken sizes, sales velocity, price history and calendar effects; a pipeline that runs every day, an error measured against actuals 14 days later, and a demo interface where the planner tries five psychological prices side by side. The MVP was completed; by management decision it was not taken into the pricing process.
- Price → units
- Question
- Two-way
- Direction
- MAPE
- Measure
- 5 psychological prices
- Demo
The 14 days after a price change
Discounts and price increases
Every forecast compared with actuals 14 days later
The planner sees the prices side by side
Problem
In fast fashion, the markdown is the decision that decides the season: an early, deep discount melts margin, a late, shallow one carries stock to season end. The planner had no numerical answer to “what happens if I give this product that price”; the decision rested on experience, last year’s memory and blanket markdown rules.
The question looks simple but has two directions: the same model has to say both how much a discount will lift sales and how much a price increase will cut them. And the answer has to be per product — a T-shirt and a coat do not respond to price the same way.
Model — 14 days after a price change
DISCO’s target variable is precise: how many units an option (style × colour × season) sells in the 14 days after its price changes. That horizon was chosen deliberately — the period in which the markdown effect is clearest and the planner can get feedback for the next decision.
The model is XGBoost regression; the training data is built from historical price-change events. The pandemic split that data in two: events from 2017–2020 and from 2021 onwards were prepared separately and merged, because the price–sales relationship of the lockdown periods did not resemble what came before. The training set is refreshed every six months.
Features fall into four groups:
- Stock and availability — average store, warehouse and in-transit stock over the last 14 days; size availability and broken runs, both over the last 14 days and on the discount day. A product with broken sizes does not sell however deep the discount; the model learns that.
- Sales velocity — units and revenue over the last 14 days.
- Price — previous price, new price, initial (ticket) price and change rate. How far below the initial price, which markdown in the sequence.
- Context — life cycle, division and sub-division, season, month, special-day and pre/post-holiday flags, shelf life, cost.
Having cost as a feature gives a side benefit: the forecast units for each price can be turned into revenue and margin.
Daily pipeline
The model was built not as a one-off analysis but as a pipeline that runs every day:
- SQL procedures detect the products whose price changed that day and prepare test data from stock, sales and price history. A run log holds the day’s state — not started, data ready, forecast done.
- The Python pipeline starts once the data is ready (retrying every half hour for three hours); it produces forecasts with the pre-trained encoder, scaler and model and writes the results to the database.
- Fourteen days later, actual sales are compared with the forecast; MAPE is calculated for every forecast and accumulates. If the model starts to drift, it shows.
- The Discount Elasticity Dashboard in Power BI shows both the forecasts and the error trail.
Every step writes to the DSO’s shared log structure.
Planner demo — Markdown Forecast
For the model to be useful, the planner had to be able to ask it questions. In the demo interface built with Streamlit, the planner enters the style, colour and season code and types the price they have in mind. The system picks, from a psychological price list derived from historical price transitions (x9.99 / x4.99 and the like), the five closest to the entered price and produces a 14-day forecast of units, revenue and change rate for each. The planner sees the five scenarios side by side and chooses — the model does not decide, it makes the decision concrete.
Why it did not go live
The model, the daily pipeline, error tracking and the demo were ready; what was missing was the decision. Pricing is one of a company’s most sensitive decisions, and bringing an algorithm’s proposal into the process requires an organisational choice, not just a technical one. Management did not make that choice; DISCO stayed an MVP.
We see this as the project stopped at the right point: the MVP’s job was to answer “can it be done, can it be trusted”, and it did. The structure built here — a model learning from price-change events, a daily forecast with an error loop closing 14 days later, psychological price scenarios — became the foundation of Lumtify’s DISCO product.