The math behind a price recommendation
How price elasticity, revenue projection and confidence scores are actually calculated — the formulas, their academic grounding, and where the approximation breaks.
Your screen says: "Move this product from €129 to €115. Estimated monthly revenue impact: +6.2%. Confidence: 82%."
Three numbers, three completely different kinds of thing. The first is a decision, the second a model output, and the third — in most products on the market — an illusion. This piece opens up all three.
You can only decide whether to trust a price recommendation if you can see the assumptions behind it. An assumption you cannot see is not an assumption you do not have.
It all rests on one number: elasticity
Price elasticity (ε) tells you what percentage of demand you lose for a 1% increase in price:
At ε = 1.8, raising the price 1% is expected to cost you roughly 1.8% of unit sales. This single number sits underneath every revenue estimate a pricing recommendation produces.
So where does 1.8 come from? Two large meta-analyses in the literature:
| Meta-analysis | Scope | Mean ε |
|---|---|---|
| Tellis (1988) | 367 elasticity estimates, ~220 brands | −1.76 |
| Bijmolt, van Heerde & Pieters (2005) | 1,851 elasticities, 81 studies | −2.62 |
So 1.8 is a defensible starting point — within 2% of Tellis's mean, and conservative against Bijmolt's larger and more recent one.
The problem is not the value, it is that there is only one
The common finding across this literature is that elasticity is not constant: it varies by category, by brand position, by product life stage and by promotional context. That variation is the actual subject of Bijmolt and colleagues' paper — what determines price elasticity.
Applying a single ε to an entire catalogue means modelling paint and washing machines with the same demand curve. The only thing that makes this defensible is not hiding it: if the screen states which value was used and how it drove the result, the user can apply their own judgement. If it does not, an estimate gets read as a measurement.
Proper calibration uses the customer's own data. Given a time series of price and units, the slope of a log-log regression gives ε directly:
Without that data, the next best option is category-level defaults — at minimum separating durables from fast-moving goods.
How revenue impact is calculated
Moving from price p to p′, with relative move d, new quantity q′ and revenue change ΔR:
Which gives a revenue ratio of R′/R = (1 + d)(1 − ε·d).
The grounding is standard microeconomics. Under constant-elasticity demand,
and the exact revenue ratio is R′/R = (1 + d)1−ε. The product form above is its first-order (Taylor) approximation: for small d, (1+d)−ε ≈ 1 − ε·d.
The sharp conclusion this produces
If ε > 1, then R(p) = A·p1−ε is monotonically decreasing in price. No approximation needed; the result falls straight out of the formula:
Under constant-elasticity demand with ε > 1, no price increase can raise revenue. Only a demand curve that falls more slowly than price rises will pay for an increase — and ε > 1 is precisely the case where it does not.
The practical consequence surprises most teams: the "you are the cheapest, raise your price" branch of a pricing engine never fires in a model assuming ε > 1. The engine stays quiet, and that silence is not a gap — it is the direct consequence of the assumption.
If you genuinely want to see increase recommendations, the thing to argue about is not the engine but ε. If raising the price on a product makes sense, that product's elasticity is probably below 1, and you need to tell the model so.
Where the approximation error grows
The Taylor error is second order:
For ε = 1.8, approximation against the exact model, as a revenue ratio:
| Move d | Approximation | Exact model | Difference |
|---|---|---|---|
| −15% | 1.0795 | 1.1388 | +5.93 pp |
| −10% | 1.0620 | 1.0879 | +2.59 pp |
| −5% | 1.0355 | 1.0419 | +0.64 pp |
| +5% | 0.9555 | 0.9617 | +0.62 pp |
| +10% | 0.9020 | 0.9266 | +2.46 pp |
| +15% | 0.8395 | 0.8942 | +5.47 pp |
Note that the difference has the same sign on every row. The approximation understates the effect of the move in both directions — it is systematically biased toward not moving at all.
Below 5% the error stays under 0.7 points, and most day-to-day recommendations live in that range, so the approximation is defensible in practice. At a 15% move it is the difference between "−16% revenue" and "−10.6% revenue", and that is a different decision.
A movement cap is really an outlier test
Most systems include a safety valve: if the calculated move exceeds some percentage, no recommendation is produced. The reasoning is sound — a gap that large usually means the two listings are not actually the same product.
But a fixed percentage is a poor proxy for that question, because it takes no account of how tight the price distribution is. The real question is: is this listing an outlier among this product's competitor prices?
The robust version is the Hampel identifier, built on the median and the median absolute deviation (MAD):
The 1.4826 factor scales MAD to the standard deviation under normality; listings with |z| > 3 are treated as outliers. Median and MAD are used instead of mean and standard deviation because of the breakdown point: a single absurd price drags the mean wherever it likes, and a single absurd price is exactly what you are trying to catch.
Concretely:
| Situation | Fixed 15% cap | Hampel |
|---|---|---|
| Competitors at 100, 102, 101 → we are at 118 | suppresses | suppresses — tight spread, genuine outlier |
| Competitors at 100, 140, 180 → we are at 118 | suppresses | allows — the spread is already wide, 118 is ordinary |
The second row is where a fixed cap quietly suppresses perfectly healthy recommendations.
What "Confidence: 82%" actually means
Now the third number, because it is the one most often misread.
Confidence percentages in pricing tools frequently have no statistical meaning. The typical construction is: the bigger the move, the lower the confidence — a linear expression whose only input is the size of the recommendation itself. Not a probability, not a confidence interval, not a calibrated score.
Any number shown with a percent sign and a progress bar reads as measured. Presenting something unmeasured as a percentage is a lie the interface tells the user.
Here is what actually determines whether a price recommendation deserves trust:
- Match accuracy — is this really the same product, and with what confidence was it linked.
- Data freshness — when was the competitor price last observed.
- Observation count — one competitor, or seven.
- Price agreement — are competitor prices clustered or scattered.
- Data integrity — was the last update for this product suspect.
All five are observable. A multiplicative combination, each factor in [0,1], gives a score where "why 60%?" has an answer:
This is still not a calibrated probability. But every component is explainable — and until calibration exists, the honest move is to drop the percentage and use a three-level label instead: high / medium / low. Something that does not look like a number will not be read as a measurement.
Questions to ask of any recommendation
- What elasticity was assumed for this product, and where did that number come from?
- Is the revenue estimate an approximation, and how large is the error at this move size?
- How many competitor observations are attached, and when were they last refreshed?
- With what confidence were the matches made, and were they reviewed?
- Is the "confidence" number a function of data quality, or just of the size of the move?
If those five answers are not on the screen, what you have is not a recommendation. It is a guess.
References
- Tellis, G. J. (1988). The Price Elasticity of Selective Demand: A Meta-Analysis of Econometric Models of Sales. Journal of Marketing Research, 25(4), 331–341. 367 elasticity estimates across ~220 brand-markets; unadjusted arithmetic mean −1.76.
- Bijmolt, T. H. A., van Heerde, H. J., & Pieters, R. G. M. (2005). New Empirical Generalizations on the Determinants of Price Elasticity. Journal of Marketing Research, 42(2), 141–156. 1,851 elasticities across 81 studies; mean −2.62. Its subject is what makes elasticity vary.
Frequently asked questions
What is price elasticity?
Price elasticity (ε) is the ratio showing what percentage of demand is lost for a 1% increase in price. At ε = 1.8, a 1% price rise is expected to cost roughly 1.8% of unit sales. Meta-analyses report retail averages between 1.76 (Tellis, 1988) and 2.62 (Bijmolt et al., 2005).
Does raising a price increase revenue?
Under constant-elasticity demand, if ε is greater than 1, no: revenue R = A·p^(1−ε) is monotonically decreasing in price, so no increase can raise revenue. An increase only pays on products whose elasticity is below 1.
What should a price recommendation's confidence score be based on?
On data quality rather than the size of the move: match accuracy, freshness of the competitor price, number of observations, how closely competitor prices agree, and whether the last data update was complete. A percentage that includes none of these is not a measurement.
Why cap the size of a price move?
A very large gap usually means the two listings are not actually the same product. But a fixed percentage cap ignores how tight the price distribution is, so it also suppresses healthy recommendations on products with a wide spread. The Hampel identifier, built on the median and MAD, does this job more accurately.