Executive Summary
Ask a pricing team what a competitor's price is, and they will give you a number. Ask them where the number came from, and it will be the listed price on the product page.
That number is the top of a stack that is, on the categories studied here, typically five or six layers deep. Every layer below it moves. Most of them move more often than the listed price does. And in aggregate they determine what the customer actually pays — and, separately and more painfully, what the seller actually gives up.
This study examines Flipkart offer stack analysis across a monitored panel, and reaches three conclusions that we think are consequential enough to state up front.
The effective price sits materially below the listed price, by a margin that varies enormously by category and by the price of the item.
Naive effective-price calculations are systematically wrong, and wrong in a consistent direction — they overstate the discount, because they ignore caps, conditionality, and redemption leakage.
The most expensive layer in the stack is the one that appears free. No-cost EMI carries a real cost, that cost is typically borne by the seller or brand, and it appears in almost no competitive benchmarking exercise we have seen.
This report is published by Product Data Scrape. Figures are representative of observed patterns across our Flipkart monitoring panel and are illustrative rather than a market census.
1. Methodology
- Panel: Monitored SKUs across Mobiles, Large Appliances, and Small Appliances — categories where financing and exchange offers are central to purchase behaviour.
- Capture: Every bank offer stored as structured fields (bank, card type, offer type, percentage, flat value, cap, minimum transaction), rather than as a display string. This is the methodological decision on which the entire study rests.
- Computation: Cap-aware best-offer selection on every record; stackability captured where surfaced.
- Two effective prices computed: best-case (optimal legal offer combination, advertised ceilings) and realised (weighted for caps, conditionality, and redemption).
2. Finding One: The Stack Is Deeper Than Most Teams Assume
| Category |
Median Offer Layers per SKU |
Median Bank Offers on Listing |
Share Offering No-Cost EMI |
Share Offering Exchange |
| Mobiles |
5.4 |
3.8 |
~81% |
~76% |
| Large Appliances |
5.1 |
3.4 |
~74% |
~52% |
| Small Appliances |
3.6 |
2.9 |
~31% |
~9% |
Illustrative figures.
The stack is deepest exactly where the item is most expensive — which is also where a benchmarking error is most costly in absolute terms.
Implication: a pipeline returning a single price field is discarding, on a median mobile SKU, more than four separate pricing instruments.
3. Finding Two: Naive Effective Price Is Systematically Too Low
The most common way to compute an effective price is to sum every advertised offer and subtract the total. Across the panel, this produced numbers that were consistently and substantially below any price a real customer achieves.
Three mechanisms account for the error, and all three push in the same direction.
Caps bind, and they bind harder as price rises. A 10 percent bank discount capped at 1,500 rupees delivers 10 percent on a 15,000-rupee item and 3 percent on a 50,000-rupee item. In the panel, the cap was binding on the majority of high-ASP records — meaning the advertised percentage was, on those records, simply not the discount.
Offers do not always stack. Summing every offer on a listing produces a combination no customer can actually select.
Exchange ceilings are ceilings. The advertised maximum exchange value is achieved by a small minority. A large share of buyers have nothing to exchange at all. Subtracting the advertised maximum from every record is the single largest source of error we observe.
The consequence, illustrated on one high-ASP record:
| Calculation |
Effective Price |
| Listed price |
42,999 |
| Naive (sum all advertised offers) |
27,379 |
| Best-case (cap-aware, stackability-aware, ceilings) |
30,899 |
| Realised (weighted for participation and redemption) |
36,988 |
Illustrative figures.
A spread of nearly 10,000 rupees between the naive figure and the realised figure — on a 42,999-rupee item.
Implication: a pricing team using a naive effective price will conclude that a competitor is far cheaper than it is, and will cut a price it did not need to cut. This is not a theoretical risk. It is the most common way we see effective-price data misused, and it is more damaging than not computing effective price at all.
4. Finding Three: The Layer That Looks Free Is the Most Expensive One
No-cost EMI is presented to the customer as an absence of cost. The interest is not absent. It has been paid.
In the standard Indian merchant-funded structure, the interest that the financing partner would otherwise have charged the customer is instead borne by the seller or brand, as a discount equivalent to that interest. The customer's benefit is real. So is the seller's cost. They are the same rupee.
Which produces a result that we think is the most useful single sentence in this report:
A competitor offering no-cost EMI on a high-ASP SKU is discounting — and the discount does not appear anywhere in their listed price.
| Category |
Share Offering No-Cost EMI |
Typical Tenures Offered |
Where the Cost Lands |
| Mobiles |
~81% |
3, 6, 9, 12 months |
Typically seller/brand, via merchant-funded subvention |
| Large Appliances |
~74% |
3–24 months |
Typically seller/brand |
| Small Appliances |
~31% |
3–6 months |
Typically seller/brand |
Illustrative; specific subvention arrangements vary by seller, financing partner, and negotiation.
Across the panel, no-cost EMI availability was more predictive of who held the default seller position on high-ASP listings than listed price was. In a category where a large share of purchases are financed, the absence of a no-cost EMI option is not a missing promotion. It is a gate: the customer who intends to pay in instalments is not comparing you to the competitor at all.
Implication: benchmark no-cost EMI availability and tenure as a pricing variable, not a promotional detail. And when your finance team asks what promotional participation costs, the subvention line belongs in the answer.
5. Finding Four: Stack Composition Is a Competitive Signal
The most interesting patterns in this dataset are not in the totals. They are in the composition — and in how composition changes over time.
We observed a recurring behaviour worth naming. A seller under margin pressure who does not want to signal weakness will freeze the listed price and deepen the offer stack. The headline price does not move. The bank offer cap rises, the exchange ceiling rises, an additional EMI tenure appears, the SuperCoin earn rate ticks up.
To a competitor benchmarking on listed price, nothing has happened.
To a customer, the price has fallen.
| Seller Behaviour |
What a Listed-Price Benchmark Sees |
What It Actually Means |
| Listed price cut |
A price cut |
A price cut — public, visible, hard to reverse |
| Listed price frozen, offer stack deepened |
Nothing |
A price cut — private, granular, reversible |
| Listed price cut, offer stack thinned |
A price cut |
Often no net change; the discount has migrated between layers |
The third row is the one that costs money. Twice in our monitoring work we have seen a brand match a competitor's listed-price cut that was, on effective price, not a cut at all — the competitor had simply moved the same discount from the offer layer to the price layer. The brand matched a move that had not been made, and gave up margin for it.
Implication: track offer-stack composition as a time series, and alert on effective-price movement. A frozen listed price is not a stable competitor. It may be an escalating one.
6. What Brands Should Change
Capture offers as structured fields, not display strings. A string cannot be computed against. This is the prerequisite for everything else in this report.
Compute cap-aware. The cap frequently binds, and it binds hardest on your most valuable SKUs.
Build two effective prices. Best-case for perception; realised for margin and for competitive comparison. Never quote one when you mean the other.
Put the no-cost EMI subvention on the cost line. It is a discount. It should be visible as one.
Alert on effective-price movement, not listed-price movement. And treat a frozen listed price with a deepening stack as an escalation, not as stability.
Trade offer depth against price depth. Where a cap is binding, a rupee spent widening the cap frequently buys more competitive effect than a rupee cut from the listed price — and it is reversible, which a public price cut is not.
7. Limitations
Findings reflect a monitored panel, not a platform census. Subvention structures, offer arrangements, and cost-sharing between platform, financing partner, seller, and brand vary by negotiation and are not publicly disclosed — our statements about where the cost lands describe the standard merchant-funded structure and should be verified against your own commercial agreements. Realised effective price depends on redemption and participation weights that are specific to each seller's own transaction data. Category composition affects all figures. Figures are illustrative of observed patterns rather than audited statistics.
8. About the Data
This report was produced using Flipkart offer stack data collected by Product Data Scrape. Our Flipkart datasets capture every bank offer as structured fields — bank, card type, offer type, percentage, flat value, cap, minimum transaction — with cap-aware best-offer computation, no-cost EMI availability and tenures, exchange valuations, SuperCoin earn rates, Plus pricing, per-variant stock, and the full multi-seller array.
Delivered as JSON, CSV, via REST API, or pushed directly to cloud storage and data warehouses.
Want the stack analysed on your own category? Product Data Scrape will capture the full offer stack on your SKUs and your competitors' SKUs, apply your own realisation weights, and show you the effective-price gap your dashboard is not measuring.
Product Data Scrape — turning marketplace complexity into decision-ready data.
Singapore
EMAIL
PHONE
.webp)
.webp "thumb")
.webp "thumb")
.webp "thumb")
.webp)
