India Quick Commerce Price & Availability Index — Blinkit vs Zepto vs Instamart, 10 Cities

Introduction

Category managers at FMCG brands who need to know what their SKUs actually cost on a quick-commerce app in a given pincode, and whether they are in stock there. D2C founders deciding whether to list on one platform, two or all three. Retail analysts who rely today on platform statements and want observed listing data instead.

This answers the September inquiry pattern: daily quick-commerce price and stock tracking at pincode granularity, assortment comparison across the three platforms, and verification that a brand's own MRP and discount rules are honoured at store level.

What this report measures

For a fixed basket of SKUs across a fixed pincode sample, the report measures what the three platforms displayed to a shopper: listed selling price, struck-through reference price, in-stock state, pack size and unit, delivery and handling fees and any surcharge shown at cart stage, and whether the SKU appeared in that pincode's catalogue at all.

It derives a price index by platform and city (lowest platform-city cell = 100); the within-city spread (cheapest to most expensive pincode for the same SKU, same platform, same day); an availability rate (share of attempts where the SKU was listed and in stock); and assortment overlap (how many basket SKUs each platform carries in a pincode).

What this report does and does not measure. It measures share of listings, share of assortment, availability rate and observed price levels. It does not measure market share, revenue share, order volume, GMV or units sold. A listing is not a sale; two platforms can carry identical assortment at identical prices and sell wildly different volumes. "Carries more of the basket" is a statement about catalogue coverage in our sample. A lower price is the price displayed at collection time, before any personalised coupon, membership discount or wallet offer. We publish no estimate of any platform's sales and do not model one.

Collection design

Sample at a glance

These figures are the planned scope of the design set out below — arithmetic on the sample, the basket and the cadence — not a count of what was captured. Actual volume comes in under them, because not every basket entry is listed on every platform in every pincode, and because a pass that fails is excluded rather than filled in. How much of the grid actually resolves is a published result, not an assumption: see the availability rate availability rate by platform and each edition's own successful pass and observation count as-of date and total observation count.

Sources. Consumer storefronts of Blinkit, Zepto and Swiggy Instamart, accessed as an unauthenticated shopper with delivery location set by pincode. No partner APIs, seller dashboards or licensed platform data.

Geographic sampling. Ten cities; within each, 8–15 pincodes stratified across a central commercial zone, two residential zones at different income bands proxied by public municipal ward data, a peripheral or newly-serviced zone, and where present a satellite township. The pincode list is published so readers can reproduce the sample. Pincodes are frozen for the series; additions are appended and versioned, never substituted, so the series stays comparable.

SKU selection. A frozen basket of 120 SKUs across staples, dairy, packaged food and snacks, beverages, home and laundry care, personal care, baby care and fresh produce. Each category carries national brands with wide distribution, one or two regional brands, and platform private label where it exists. Entries are specified by brand, variant, pack size and unit, so matching is by pack rather than name string. Produce is specified by commodity and unit, flagged separately, and never pooled into the packaged-goods index, because weight-graded produce is not a matched SKU.

Matching. Listings map to basket entries through a manually reviewed table keyed on brand, variant and net quantity, built at basket definition and audited monthly. Multipacks, combos and festive packs are excluded rather than force-matched. Where only a different pack size exists, the SKU counts as coverage but is excluded from price comparison.

Cadence. Daily, one pass per pincode per platform inside a fixed afternoon two-hour window, holding time-of-day effects roughly constant. A twice-weekly evening pass quantifies intra-day movement and is reported as a separate sensitivity section, never blended into the headline index. Each edition covers a calendar month and states its as-of date and successful pass count.

Fees. Delivery, handling, small-cart, rain and surge lines are captured at a standard test-cart value and a below-threshold cart value, so the report shows fee structure rather than one number.

Data schema

Report sections

Executive summary — the single-price myth. No single national price exists for this basket; within-city spread rivals or exceeds the between-platform gap.

Figure 1 — Price index by platform and city. Grouped bars; x = city, y = index, series = platform. Ten items on one measure → bars.

Figure 2 — Within-city spread. Point plus whisker; x = city, y = basket cost, point = median pincode, whisker = min–max, one panel per platform. A range is the finding; bars would hide it.

The spread explained. Darkstore-level pricing, substitution forced by differential availability, fees by distance band.

Figure 3 — Availability by platform and category. Grouped bars; x = category, y = availability rate, series = platform. Items × one measure → bars.

Figure 4 — Availability over the month. Line; x = date, y = availability rate, series = platform. Level over time → line.

Figure 5 — Assortment overlap. Stacked bars; x = city, y = share of basket SKUs, segments = on three / two / one / none. Parts of a whole that sum → stacked.

Figure 6 — Unit price, high-velocity SKUs. Horizontal bars; x = price per litre or kg, y = SKU, series = platform.

Fees and true cart cost. Fee table at both cart bands, plus a worked example of how ranking changes once fees are added.

Category deep-dives. Dairy, staples, personal care: index and availability for each alone.

How to use this. Reading low availability in one stratum; what a persistent discount gap indicates; what to escalate to a platform account manager.

Methodology and limitations.

Appendices. A: pincode sample. B: basket definition. C: collection success rates.

Data slots

Methodology and limitations

Every figure is an observation of what a platform displayed in a session at a stated time for a stated pincode. It is not a transaction record.

Sampling limits. Ten cities and 8–15 pincodes each is a sample, not a census; India has thousands of serviceable pincodes and each platform runs many darkstores per city. A spread measured across twelve pincodes is a lower bound — a wider sample would find wider extremes. City figures read throughout as "in our sample of this city."

What a listing observation cannot tell you. Not whether anyone bought, not the platform's margin, not the brand's trade terms, not who funded a discount. An out-of-stock flag does not distinguish a darkstore stockout from a delisting, a catalogue error or a serviceability pause; we report the flag as displayed and say nothing about cause.

Logged-out collection. Prices and offers vary by account, membership tier, coupon eligibility and app version. We collect in a consistent generic session state, making observations comparable to each other but not identical to what a specific logged-in customer sees. Membership-gated prices are out of scope.

Observed versus inferred. Price, availability flag, pack size, badge text and fee lines are observed. Index, availability rates, overlap shares and spreads are derived by stated arithmetic on observed values. Nothing is inferred from external models, and we publish no inferred figure. Where a reader might expect a market-size or sales number, we state that we do not measure it.

Matching risk. The main error source is matching: pack renames, festive packaging, regional variants and platform bundles create false matches. Mitigation is a frozen audited mapping table and exclusion rather than approximation, with excluded counts published.

Missing data. Failed or partial passes are reported, never backfilled. A day with insufficient coverage appears as a gap, not an interpolation.