Price elasticity of demand is the single most consequential number in a pricing programme, and the familiar way of estimating it, regressing quantity on price, is almost always wrong. Because price reacts to demand, ordinary least squares mixes the true demand curve with a confound and biases the answer towards zero. Instrumental variables, estimated through two-stage least squares, recover the causal elasticity the pricing optimiser actually needs.
The number everything hangs on
Price elasticity of demand, the percentage change in quantity sold for a one-percent change in price, sets the profit-maximising price, decides whether a promotion pays for itself, shapes markdown schedules, and feeds every downstream optimiser. Get it right and the optimiser prices near the true optimum. Get it wrong and the optimiser is confidently, precisely wrong, which is worse than being obviously wrong, because nobody double-checks a number that came out of a model.
So the temptation is to reach for the most familiar tool in the box: regress log quantity on log price, read off the slope, and call it the elasticity. It is a single, easy step, and it is almost always biased, usually towards zero, which makes demand look far less price-sensitive than it really is.
Why the obvious regression fails
The problem is endogeneity, and specifically simultaneity. In any real dataset, price is not set at random. It is set by people, or by an earlier pricing system, who react to conditions the analyst cannot see. When demand is running hot, managers raise prices; when a category is soft, they discount. That unobserved demand shock drives price up and quantity up at the same time, stamping a spurious positive association on top of the true negative causal relationship.
Ordinary least squares cannot tell the two apart. It sees the net of the true downward-sloping demand curve and the upward confound, and it splits the difference, so the estimated slope is attenuated towards zero. On our synthetic market, where the true elasticity is exactly minus one and a half by construction, OLS recovers only about minus four-tenths, reporting demand as roughly a third as sensitive to price as it actually is. A pricing engine handed that figure concludes it can raise prices almost for free.
The instrument idea
Instrumental variables solve this by finding a source of price variation that has nothing to do with demand. The classic choice is a cost shifter: something that moves the price a seller charges for reasons on the supply side, such as an input-cost change, a logistics or supply shock, or a tax, and that does not itself move customer demand except through the price it induces.
Two-stage least squares then does exactly what its name says. In the first stage it isolates the part of price movement that is driven only by cost; in the second it relates quantity to that predicted, cost-driven price. Because the predicted price no longer carries the demand-shock contamination, the second-stage slope estimates the causal elasticity rather than the confounded correlation.
Two conditions make this valid, and both deserve scrutiny rather than faith. Relevance means the instrument must genuinely move price, which shows up as a strong first stage; a weak instrument produces a high-variance, unreliable estimate. Exclusion means the instrument must affect quantity only through price, and that is an assumption about the world rather than something the data can prove, so it has to be argued from domain knowledge. In our simulation it holds by construction; in practice it is where the real work of a causal study lives.
What we found, and why it is worth the trouble
With a valid cost instrument on this synthetic data, two-stage least squares recovers a value essentially equal to the true minus one and a half, while OLS on the same data returns the attenuated figure near minus four-tenths. The two estimators are not two opinions about the same quantity; one answers a different question, how price and quantity move together, than the one pricing actually needs, how quantity responds when we deliberately move price. In pricing, the causal estimate is the product, and everything downstream is only as good as the elasticity it is built on.
The payoff is margin, not academic tidiness. Hold the optimiser completely fixed and feed it each estimate in turn. Fed the naive figure, it believes demand barely reacts to price, pushes the price up until it hits the guardrail ceiling, and captures a small improvement over the current rule. Fed the causal figure, it lands on an interior optimum and captures several times as much margin, from the very same engine, purely because the input was estimated correctly. That gap is the whole argument for treating elasticity as a causal problem, and it is why, in the wider programme, no pricing optimiser is allowed to run until the elasticity has been validated.