Price Elasticity Studio
From sales history to better prices: estimate elasticity, see how sure it is, simulate, optimize within guardrails, export the plan.
- Free
- Runs in your browser
- No sign-up
- Synthetic example included
One row per product per week (or per day): a date, a product ID, units sold, the price customers paid and the unit cost.
At least about 26 weeks per product, and prices that actually changed. Two years of weekly data is ideal.
- date
- Week start or day, e.g. 2025-03-03
- product
- SKU or product ID
- units
- Units sold that week (0 is fine)
- price
- Average price customers actually paid, after discounts
- cost
- Unit cost, for profit
- promo
- Optional: 1 in promotion weeks
- in_stock
- Optional: 0 when the item sold out that week
- competitor_price
- Optional: a rival's price for the same item
The whole analytics pipeline behind every number in the studio. Everything runs in your browser; nothing is sent to a server.
- Your CSVunits, price, cost per product per week
- Checksblockers stop, warnings travel with results
- Demand modelPPML per product, promo, season, trend
- Bias checksdemand-led pricing, season, streaks, hold-out
- Poolingnoisy products borrow from their category
- Evidence labelGreen, Amber or Red with reasons
- Optimiserbest allowed price within guardrails
- Raise or Lowergains across the whole range, Green
- Test firstAmber, or the range straddles the answer
- Keeptoday's price is already the best allowed
- No callRed: too little evidence
Step by step
- 01Upload and validateRead the CSV in your browser, map columns, run data checks.
- Blockers: missing required columns, mixed currencies, nothing usable left.
- Warnings: negative or zero prices, returns, duplicates, cost above price, flat prices, sales spikes, cost jumps, short histories, ambiguous dates.
- Day/month or month/day dates and decimal commas are detected. Daily rows are summed to Monday weeks; the weekly price is the average daily price.
- No cost column? You can assume cost as a share of price, and every profit number says so.
Output: One weekly series per product: units, price, cost, promo, stock, competitor price.
- 02Prepare the sampleSet aside the weeks that would mislead the model.
- Stockout weeks are kept as censored: demand was at least what sold. Their likely demand is filled in from the model and refitted until it settles.
- A launch ramp (first weeks while a new product finds buyers) is left out.
- Zero-sales weeks are kept; no log of zero is ever taken.
- Measure the evidence: distinct regular prices and how much they moved.
Output: The weeks the model may learn from, and how much the regular price actually moved.
- 03Fit a demand model per productPoisson regression with a log link (PPML).
- E[units] = exp(a + b·log price + promo + promo depth + post-promo dip + trend + season + category index + category prices + c·log competitor price)
- b is the elasticity of the REGULAR price: promotion depth gets its own term, because shoppers react to a temporary deal differently.
- The category index (other products' sales that week, after their own estimated price effects) absorbs shared shocks such as a holiday peak; the other products' average price captures substitution.
- Errors are Newey-West with about √n lags, widened ×1.45: chosen on simulated base and stress data, then confirmed on fresh seeds it never saw (92% and 87% coverage).
Output: Elasticity b with a standard error, promotion lift, competitor effect.
- 04Did price follow demand?Three checks for prices that were set because of demand.
- Stage 1: log price on log cost and the same controls, with robust strength F ≥ 10 required.
- Cost-shift: add the stage 1 residual to the demand model; beyond t = 2, the corrected estimate replaces the plain one.
- Feedback: do price changes follow weeks of stronger sales than expected? Frequent repricing: does price change in most weeks?
- These only partly protect against demand-led pricing; failing any of them keeps a product out of Green.
Output: An estimate checked, where the data allows, for prices that chased demand.
- 05Other checksHold-out forecast and pattern checks.
- Refit without the last 20% of weeks and forecast them; compare with a naive recent average.
- Seasonal pricing: do the same calendar weeks a year apart match better than any other alignment? Category repricing: did the other products' shelf prices move with this one (regular weeks, trend removed)?
- Streaks: do sales run above or below the model for weeks at a time? Stockouts in strong weeks?
Output: Reasons that cap a product at Amber or Red.
- 06Borrow strength within categoryRandom-effects pooling (empirical Bayes shrinkage).
- Category mean μ and spread τ (at least 0.5) from products with real price movement; cost-corrected products stay out.
- Pooled b = w·own + (1 − w)·μ, with w = τ² / (τ² + se²): precise products keep their own number, noisy ones lean on the category.
- Products whose price never moved get the category estimate for reference only.
Output: Final elasticity with a 90% range for every product.
- 07Label the evidenceGreen, Amber or Red, with the reasons spelled out.
- Red: under 26 weeks, under 3 distinct prices or under 2% movement, an estimate at or above zero, or price following the calendar.
- Amber: range includes zero or is wider than 1.2, mostly borrowed, any demand-led pricing sign, category repriced together, launch, streaky sales, biased stockouts, failed hold-out.
- Green: none of the above.
Output: A reliability label that gates every recommendation.
- 08Demand, revenue and profit curvesConstant-elasticity curve around today's regular price.
- units(P) = Q_ref × (P / P_ref)^b, with P_ref and Q_ref from the last 13 normal weeks, moved to an average season.
- revenue = P × units; profit = (P × (1 − rebate share) − unit cost) × units.
- Every outcome is computed at b and at both ends of its 90% range.
Output: What any price would do to units, revenue and profit, with ranges.
- 09Optimise within guardrailsCheck every allowed price; keep the best one.
- Guardrails: max move, margin floor, price endings, tried-price range, competitor cap, floors, ceilings, locks.
- Raise or Lower only if the move gains at BOTH ends of the elasticity range and the label is Green.
- Otherwise Test first (with a test plan: price, pass line and length), Keep (including tests too close to settle), or No call (Red).
Output: A price call per product, its expected impact, the limits that bound it and a test plan where needed.
- 10Scenarios and reportAdd products up, with joint uncertainty.
- 600 draws of every product's elasticity give a 90% range and a chance of losing profit; changes are paired so shared noise cancels.
- Each product's draws are independent and each price is optimised on its own; a move on one product does not feed into another's demand. The report says so.
Output: Report, scenario comparison, CSV exports with engine version and data hash.
Against the publicly documented features of two commercial pricing platforms (public product pages and docs, read 10 Nov 2026). Not a review of their software.
| Capability | Competera (documented) | Pricefx (documented) | This studio |
|---|---|---|---|
| Own-price elasticity per product | Yes (deep learning, 20+ factors) | Optional, per segment | Yes: PPML per product, pooled by category |
| Promotion, season and competitor controls | Yes | Not in the docs we read | Yes, as model terms |
| Tells you when not to trust a number | Mentions a model confidence level | Not documented | Yes: Green / Amber / Red with reasons, ranges on everything |
| Checks whether prices chased demand | Not documented | Not documented | Partly: cost-shift correction where cost moved, plus feedback and repricing checks |
| Optimise profit or revenue under guardrails | Yes (margin floors, rules, price ladders) | Yes (bounds, max change, alignment) | Yes: max move, margin floor, endings, competitor cap, floors, ceilings, locks |
| Recommendation survives the uncertainty | Not documented | Not documented | Yes: gain required at both ends of the range |
| What-if simulation | Yes | Yes, volume held fixed by default | Yes, and the static (volume fixed) answer side by side |
| Price waterfall and leakage | Blog material | Yes, detailed | Yes: list, invoice, pocket price, pocket margin |
| Cross-product cannibalisation | Yes (method undocumented) | Tier alignment | Partly: each product's demand includes the category's average price, but prices are optimised one product at a time |
| Competitor price scraping, live A/B tests, approvals | Yes | Approvals with audit trail | No: bring your own competitor prices |
- Price elasticity
- The % change in units for a 1% change in price. -2 means a 1% rise loses about 2% of units.
- Elastic vs inelastic
- Below -1, a price rise loses more units than it gains in price, so revenue falls. Between -1 and 0, revenue rises with price.
- Profit-maximising price
- With a constant elasticity e below -1, the best price is cost × e / (1 + e). At e = -2 that is twice the cost.
- Endogeneity
- When price is set in response to demand (raised in busy weeks), sales and price move together for a reason other than shoppers reacting to price, which biases the estimate toward zero.
- Instrument
- Something that moves price but not demand directly, such as a supplier cost change. It lets the model isolate the shoppers' reaction.
- Shrinkage
- Pulling a noisy estimate toward its category average, in proportion to how noisy it is.
- Censored demand
- In a stockout week, sales are capped by stock, so they understate what people wanted.
- WAPE
- Weighted absolute percentage error: total forecast miss divided by total actual units.
- Historical data shows association. Unless prices moved for reasons unrelated to demand (cost changes, planned tests), an elasticity is not proof of what a change will cause.
- The model allows for the category's average price, but not for one specific product cannibalising another, and each price is optimised on its own.
- The curve has the same % response at every price. Far from prices you have tried, real demand may bend; those prices are flagged.
- Weekly figures are for an average week like the last 13 normal ones. Seasonal peaks, promotions and competitor moves change them.
- The accuracy figures come from simulated data: 24 datasets drawn from the model's own assumptions and nine stress scenarios built to break them, plus fresh seeds of both. The widening of the ranges was tuned on those simulations. Real data can break the model in ways none of them covers. One stress case, prices raised only in a holiday peak, defeats it: most of those products are labelled Red.
- A 90% range is about 95% one-sided, and it is only right if the model is. Pooling also uses each product's own data twice (in its estimate and in its category's).
- The best confirmation is a price test: change price for some stores or weeks, keep others as control. The Optimizer gives a plan for each Test first product.
How it works
What the studio does
For each product it fits a demand model to weekly sales: units depend on the regular price, promotions, their depth and the dip after them, season, trend, the other products' prices and demand in the same category and, if you have it, a competitor's price. The coefficient on the regular price is the elasticity. It uses Poisson regression with a log link, which keeps weeks with zero sales, and treats stockout weeks as censored: demand was at least what sold, so those weeks are neither dropped nor taken at face value.
Why most elasticity numbers are wrong, and what it does about it
Prices are not set at random. If a manager raises prices in busy weeks, price and sales rise together and a naive regression reports that shoppers barely care about price. When unit costs moved, the studio uses those cost changes as an outside driver of price (a control function) and corrects the estimate when prices chased demand. It also checks whether price changes followed strong sales, whether prices changed almost every week, whether the regular price follows the calendar, and whether the whole category was repriced together. Any of those keeps a product out of Green. These checks reduce the risk; they cannot remove it.
How sure is it?
Every elasticity has a 90% range, and products with thin data borrow strength from their category. The accuracy was measured on simulated data with known answers: 24 datasets drawn from the model's own assumptions, and nine stress scenarios built to break them (persistent demand shocks, prices reset from recent sales, holiday pricing, launches, low volume, promotion-led sales, inflation, stockouts in peak weeks). The ranges are widened by a factor chosen on those runs, so they were checked again on data the factor never saw: the range held the true elasticity for 92% of usable products on fresh base data and 87% on fresh stress data. A price change is recommended only when it gains profit at both ends of the range and the evidence is Green: across all of these runs, 3 of 102 such calls would have lost profit under the true elasticity, the worst by 0.8%. One stress case, prices raised only in a holiday peak, defeats the model, and it labels most of those products Red; prices reset from recent sales are also hard (about 61% of ranges hold the truth), so those stay out of Green.
What it cannot do
It accounts for the average price of the other products in a category, but not for one specific sister product cannibalising another, and the Optimizer still sets each price on its own. Its curve has the same percentage response at every price, which is a fair approximation near prices you have tried and is flagged beyond them. Historical data shows association; a price test on part of your stores or weeks is how you confirm a change, and the Optimizer writes a test plan with a pass line for each product that needs one. Commercial platforms such as Competera and Pricefx add competitor scraping, approval workflows and cross-product models; this studio is a free, transparent way to learn the method and get a first answer.
Learn the pieces first
The regression and confidence interval ideas behind it are in the free Analytics from Scratch course. For marketing budgets rather than prices, try the marketing mix modeling lab. The full method, with a flowchart, is in the methodology note.
Pricing analytics is an analyst job
Pricing, data and business analyst roles, scraped daily from company career pages.
