The problem
Markdown decisions in retail are usually made by category managers who watch sell-through rates and intuit when to discount. The intuition is informed by experience but it is not statistical — the manager guesses at the right discount level, posts it, and hopes the recovered demand offsets the margin loss. Half the time the discount is too shallow and inventory still ages out; the other half it is too deep and margin is left on the table.
The data has the answer. Historical markdown events show how demand responded to each discount level for similar SKUs. For a given SKU at a given days-in-stock with a given on-hand quantity, the conditional expected demand at each discount tier is computable from prior events. The right discount is the one where predicted recovered margin × predicted demand exceeds the alternative of holding the inventory at full price.
How it works
_estimate is the operator for "predicted quantity at a query point." For each of the largest overstocked SKUs, the demo runs _estimate of next month's units_sold with the regression model at full price and at 5, 10, 15 and 20 % off. From the units follow the weeks the excess takes to sell. The proposal is the shallowest discount that clears the excess within 13 weeks: hold if full price already does, a markdown at the level that does, and "won't clear" when no level does, instead of proposing the deepest cut.
In the PetNord data the sweep proposes no markdown: of the 15 largest overstock rows, 14 won't clear at any level and one clears at full price. A markdown is the wrong tool for that stock, and the view says so. The horizon and the deepest level are application-level settings, and a deployment can route a proposal to the category manager rather than post it automatically.
{
"from": "monthly_sales",
"where": {
"product_sku": "SKU-PT-0061",
"units_last_month": 3,
"pet_type": "dog",
"category": "dry-food",
"brand": "Acana",
"season": "spring",
"price_eur": 69.5
},
"estimate": "units_sold",
"select": [
"estimate"
],
"model": "regression"
}For the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application.
See it live
This use case runs in the 🛒 E-commerce demo today. Click through to the live application and inspect the queries that produce the result.
Frequently asked
How does this compare to dedicated markdown optimization SaaS?
Dedicated tools optimize for accuracy on a specific time-series shape (seasonal apparel, perishables, etc.). _estimate is more general — works across product categories without per-category tuning. A dedicated tool may win on margin in its target category; the general approach trades that for broad applicability across the catalog without separate model maintenance per category.
What about cross-product effects (markdown one SKU, demand for sibling SKUs shifts)?
The query can include sibling-SKU markdown state in the where clause to condition on it. The conditional probability reflects the cross-product effect to the extent that historical events show it. For deeper modeling of substitution effects, the application can run multiple _estimate queries (one per markdown scenario) and pick the joint maximum.
How does this handle promotional events (sale weekends, holidays)?
Add the event flag to the where clause; the conditional probability conditions on it. Historical Black Friday markdowns inform future Black Friday markdowns automatically. For new events without history, the prediction returns lower confidence — the system honestly says it has not seen this combination before.
Can it predict optimal markdown depth for never-discounted SKUs?
SKUs with no markdown history return low confidence. The system can infer through similarity (similar SKU, similar category, similar customer segment) but with a wider confidence band. The category manager gets a suggested range, not a single answer; the manager makes the call on first markdown.
How does this integrate with our pricing or inventory system?
Aito returns the prediction as JSON; the pricing system reads the predicted optimal discount and either applies it or surfaces for review. Most deployments wire this through the existing pricing pipeline: the inventory system queries Aito for the recommendation, the pricing system applies it (or surfaces). The integration is HTTP and JSON.
