Most pricing decks treat price elasticity as a single number you look up in a table. One product, one slope, done. That is the version that looks clean in a board meeting and falls apart the moment you actually change a price. Real shelves do not work like that. Drop the price on one SKU and three of its neighbors move too, sometimes in the wrong direction.
I have built pricing engines for retail, and the lesson that took the longest to internalize is that own-price elasticity is the easy part. The hard part is everything the single number hides: how a discount on the 1.5 liter bottle cannibalizes the 1 liter one, how a premium line behaves nothing like the value line, how the same percentage cut lands differently in a traffic-driving category than in a margin category. A pricing model that ignores those interactions will confidently recommend a change that loses money.
So this is what price elasticity looks like when it has to survive contact with a real product matrix and a real margin target, not a slide.
Why a single price elasticity number is not enough
If you measure elasticity per SKU in isolation, you are answering the wrong question. The question is never "what happens to this product when I move its price." The question is "what happens to the whole basket and the whole category."
Take a consumer goods example from work our team has done. A retailer with a deep matrix wanted to set prices that protect margin without quietly killing volume. The first instinct everyone has is to estimate own-price elasticity SKU by SKU and stop there. We did that, and the numbers looked fine, until you put two related products side by side. Cut the price on product A and its measured volume goes up. Good. Except a chunk of that lift is just buyers switching from product B, which sits in the same characteristic group. Net category revenue barely moves, and the margin profile gets worse because you discounted a product people were going to buy anyway.
That is cannibalization, and it is invisible to any model that looks at one SKU at a time. You need cross-elasticity in the picture from the start, not bolted on later.
The model factory: own-price, cross-elasticity, cannibalization
What we ended up building was less a single model and more a model factory. SKU-level estimation across the matrix, grouped by product characteristics and by the role each product plays. A value-line staple does not respond to price the way a premium occasional purchase does, and forcing them through one functional form gives you garbage on both ends.
The pieces that mattered:
- Own-price elasticity per SKU, estimated from real transaction history rather than assumed.
- Cross-elasticity between products that compete or substitute, so a price move on one is scored against its effect on the others.
- Characteristic groups, so estimation borrows strength across similar products instead of treating a 3,000-item matrix as 3,000 unrelated problems.
- Product roles, because a traffic builder and a margin product need different objectives even when their elasticity curves look similar.
The output is not a number. It is a structure that can answer "if I move this price, here is what happens to this product, to its substitutes, and to the category total." That is the difference between a curiosity and a pricing tool.
Why most price optimization fails in production
Here is the uncomfortable part. The modeling is rarely what kills a price optimization project. What kills it is the gap between a model that fits history and a recommendation a category manager will actually execute.
A pricing engine that spits out a theoretically optimal price for every SKU, ignoring the discount policy, the rounding conventions, the competitor reference prices, and the fact that you cannot reprice 3,000 items overnight, is a science project. It produces a list nobody runs. I have watched genuinely good elasticity models die exactly this way, because the team that built them treated price optimization as a math problem and not an operations problem.
Production price optimization has to respect constraints. Minimum and maximum price bounds, margin floors, price-ladder consistency within a family, the reality that some prices are politically untouchable. The optimizer's job is to find the best move inside those walls, not to pretend the walls are not there. When you do that, the recommendations stop being clever and start being executable, which is the only kind that matters.
What-if simulation: the part that earns trust
The feature that actually got the pricing tool used was not the elasticity estimates. It was the what-if layer.
Category managers do not trust a black box that hands them new prices. They trust a tool that lets them ask "what happens if I take 5% off this line" and shows the answer across own effect, cross effect, and category total before anything ships. Pricing ai that explains itself gets adopted. Pricing ai that just asserts an optimum gets ignored.
So we built simulation in as a first-class thing. Pick a set of price changes, see the projected volume, revenue, and margin impact for the changed SKUs and for everything they touch through cross-elasticity. The manager can poke at it, override it, learn from it. The model becomes a thinking aid rather than an oracle, and that is precisely when people start letting it drive real decisions.
| Single-number approach | Model factory approach | |
|---|---|---|
| Elasticity | One slope per SKU, in isolation | Own-price plus cross-elasticity across groups |
| Cannibalization | Invisible | Modeled explicitly between substitutes |
| Product variety | One functional form for all | Characteristic groups and product roles |
| Constraints | Ignored, then patched | Built into the optimizer from the start |
| Manager trust | Black-box price list | What-if simulation they can interrogate |
How to scope a pricing AI project so it ships
If you run pricing and any of this lands, the move that fails most reliably is commissioning a grand all-SKU optimization platform up front. Same failure mode as every other enterprise AI project: scoped as a moonshot, dies in integration.
The sequence that works:
- Start with one category where you already suspect price moves are leaving money on the table, and pull real transaction history for it. Not a sample, the real thing.
- Estimate own-price and cross-elasticity for that category, and validate cannibalization against a price change you actually ran in the past. If the model cannot retrodict a real move, it will not predict a future one.
- Wrap it in a what-if simulator before you wrap it in an optimizer. Let a category manager drive it on decisions they understand, build trust, then add the constrained optimization on top.
- Only then scale across categories, carrying the constraints and the simulation layer with you.
The team behind this has shipped pricing, demand, and assortment work across retail and consumer goods, the same group that built the retail and supply chain AI systems we run elsewhere. The pattern is always the same: model the interactions, respect the constraints, make it explainable, scale only after it earns trust on one real category. If you want the longer trail of what that looks like in practice, the case studies cover the adjacent retail and pricing work.
If you want to see what your own price matrix looks like under own-price and cross-elasticity together, book a call and we will walk through a category with you.
The single elasticity number is the easy slide. Cross-elasticity, cannibalization, and a what-if layer a category manager will actually trust are the reason the pricing tool ships.