Price elasticity testing for Indian ecommerce, done safely
Most brands guess at their price sensitivity and then defend the guess. Testing it is not hard, but doing it without damaging your ranking or your customers takes care.
- Never test by moving one SKU up and down repeatedly. That teaches the algorithm and the customer the wrong things.
- Test across matched geographies or matched SKUs rather than across time, because time confounds everything.
- Watch units and contribution together. A price rise that loses volume can still be the right answer.
- Marketplace pricing engines and competitor repricing can overwrite your test, so verify the price actually held.
Almost every consumer brand has a strong opinion about how price sensitive its customers are. Very few have tested it, and the opinion usually forms during a discount period and never gets revisited.
Testing is worth doing, because the answer is frequently not what the team believes. It is also easy to do badly on a marketplace, where a careless test can dent your ranking and train your customers to wait.
Why the obvious method fails
The instinctive test is to raise the price, watch a fortnight, compare against the previous fortnight.
The problem is everything else that changed in between. Seasonality, a competitor’s promotion, a platform event, your own ad spend, a shift in ranking, a stock-out you forgot about. Any one of those can produce the movement you then attribute to price.
Time is not a control. It is the single largest source of confounding you have, and a before-and-after on one SKU cannot separate your change from the noise.
Use matched groups instead
Two designs work without much sophistication.
The first is geographic. Change price in a set of regions and hold it in a comparable set, then compare the two over the same period. Seasonality and platform events hit both groups equally, so the difference between them is a much cleaner read. India’s regional spread makes this genuinely practical, provided the groups are matched on category demand rather than picked for convenience.
The second is by SKU. Within a group of comparable products, move some and hold others. This is easier to execute but weaker, because SKUs differ in ways that are hard to control for. Use it when geographic testing is not available.
In both cases the comparison is between groups experiencing the same week, not between weeks.
Do not flap the price
The most damaging pattern is repeatedly moving a single price up and down to observe the response.
It teaches two audiences the wrong lesson. Customers who notice learn that the price is unstable and that waiting is rational. And on platforms where pricing history contributes to visibility or buy box behaviour, frequent movement is not a neutral signal.
Make a change, hold it long enough to read, then decide. Treat price as something you set deliberately rather than a dial you spin.
Measure contribution, not units
Units will always favour the lower price. That is not a finding, it is arithmetic.
The question is whether the change made money. So measure contribution: revenue minus platform commission, fulfilment, payment costs, the realistic return rate at that price point, and the advertising required to sustain the volume.
Two results surprise brands regularly. A price rise that loses a meaningful share of units can still improve total contribution, because the units lost were the least profitable ones. And a price cut that lifts volume can reduce contribution once the higher return rate and shipping on the extra orders are counted.
Neither is visible if you stop at units or revenue.
Verify the price actually held
This step gets skipped and it invalidates more tests than any other.
Automated repricing, whether your own rules or a competitor’s, can move the realised selling price during the test. Platform funded promotions can apply without much warning. Either means the price the customer saw was not the price you set.
Capture the realised price daily for both groups. If it drifted, you have measured something other than what you intended, and the honest response is to discard the result rather than interpret it.
Start where it is safe
Run the first test on a mid-tail SKU rather than your hero product. You want to learn the mechanics of running a clean test before you point it at the line that carries your revenue.
Once one clean result exists, the same design extends easily. The hard part was never the analysis. It was resisting the urge to compare this fortnight with the last one and call it evidence.