The math behind a price recommendation

Our own 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, as we found when we audited our own engine, an illusion. This piece opens up all three, ours included.

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.

Show the math

ε = − ∂ ln q ⁄ ∂ ln p

The percentage change in quantity q per percentage change in price p.

At an elasticity of 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:

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 history of prices and units sold, elasticity can be estimated directly from how sales responded to past price changes.

Show the math

ln q = α − ε · ln p + ε_t

The slope of a log-log regression of quantity on price is the elasticity.

In Nudge, elasticity is already a per-customer setting rather than a constant in the code. Every customer currently starts at 1.8; measuring it from their own sales is the next step.

Without that data, the next best option is category-level defaults — at minimum separating durables from fast-moving goods.

How revenue impact is calculated

In plain terms: cut the price 10% at an elasticity of 1.8 and you expect to sell about 18% more units. Fewer euros per sale, more sales: revenue comes out roughly 6% higher. That is where a "+6.2%" comes from.

Show the math

Moving from price p to p′, with relative move d, new quantity q′ and revenue change ΔR:

d = ( p′ − p ) ⁄ p    q′ = q · ( 1 − ε·d )    ΔR = q′p′ − qp

Which gives a revenue ratio of R′/R = (1 + d)(1 − ε·d). Under constant-elasticity demand,

q(p) = A · p^−ε  ⟹  R(p) = A · p^1−ε

and the exact revenue ratio is R′/R = (1 + d)^1−ε. The product form is its first-order (Taylor) approximation: for small d, (1+d)^−ε ≈ 1 − ε·d.

The sharp conclusion this produces

If elasticity is above 1, every 1% price rise loses more than 1% of sales. Revenue then falls with every increase, of any size. No approximation is involved; it follows directly from the model.

With elasticity above 1, no price increase can raise revenue. Only a demand curve that falls more slowly than price rises will pay for an increase, and elasticity above 1 is precisely the case where it does not.

We learned this from our own engine: its "you are the cheapest, raise your price" branch never fired, because the model assumed an elasticity of 1.8. 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. In our tests, setting it to 0.4 makes the same product produce an increase.

Where the approximation error grows

The shortcut formula above is an approximation. For small moves it is very close; the error grows with the square of the move.

Show the math

error ≈ ε(ε+1) ⁄ 2 · d²

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

The error always points the same way. The shortcut understates the gain from a price cut and overstates the loss from a price increase. Either way, 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

Pricing engines commonly 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: it asks how far a price sits from the middle of the others, measured against how spread out they normally are.

Show the math

MAD = med( |p_i − med(p)| )    z_i = ( p_i − med(p) ) ⁄ ( 1.4826 · 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:

The second row is where a fixed cap quietly suppresses perfectly healthy recommendations. Ours is still a fixed 15% cap; the Hampel test is the replacement we have written up. Until then, every recommendation the cap blocks is recorded with its reason and shown on screen, not silently dropped.

What "Confidence: 82%" actually means

Now the third number, because it is the one most often misread.

Ours has no statistical meaning today, and confidence percentages in pricing tools often do not. The construction in our engine 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, and Nudge already records every one of them. The confidence score does not use them yet. Combined, they give a score where "why 60%?" has an answer.

Show the math

C = match × freshness × price agreement × observation sufficiency

A multiplicative combination, each factor in [0,1]. One weak factor pulls the whole score down, which is the behaviour you want.

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

1. What elasticity was assumed for this product, and where did that number come from?
2. Is the revenue estimate an approximation, and how large is the error at this move size?
3. How many competitor observations are attached, and when were they last refreshed?
4. With what confidence were the matches made, and were they reviewed?
5. 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