Case Study · Retail
Defacto DISCO: if I give this product that price, how many units sell in 14 days?
A system that bases the markdown decision on a forecast. For every product whose price changes, we built an XGBoost model that learns the units sold in the next 14 days from stock, broken sizes, sales velocity, price history and calendar effects. The pipeline runs every day, the error is measured against actuals 14 days later, and in a demo interface the planner can try 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 decision largely determines how a season ends. An early, deep discount eats into 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 has two directions. The same model has to say how much a discount will lift sales and also how much a price increase will cut them. The answer also has to be per product, because a T-shirt and a coat do not respond to price the same way.
Model: the 14 days after a price change
DISCO’s target variable is how many units an option (style × colour × season) sells in the 14 days after its price changes. We chose 14 days because that is when the markdown effect is clearest and the planner can still get feedback in time 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 even at a deep discount, and the model learns that from the data.
- 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.
Because cost is one of the features, the forecast units for each price can also be turned into revenue and margin.
Daily pipeline
We built the model 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 picks one; the decision stays with the planner.
Why it did not go live
The model, the daily pipeline, error tracking and the demo were ready. What was missing was a decision to put them into the process. Pricing is one of a company’s most sensitive decisions, and bringing an algorithm’s proposal into it is as much an organisational choice as a technical one. Management did not make that choice, and DISCO stayed an MVP.
In our view the project stopped at the right point. The MVP’s job was to answer “can it be done, can it be trusted”, and it answered that. The structure built here (a model learning from price-change events, a daily forecast, an error loop closing 14 days later and psychological price scenarios) became the foundation of Lumtify’s DISCO product.