Mapping Quick Commerce Coverage by Pincode: Why Store Counts Mislead

Introduction

Ask three sources how many dark stores a quick commerce platform operates in India and you will get three answers. None of them is necessarily wrong. They are counting different things.

One source counts leased facilities. Another counts facilities that are live and picking orders. A third counts "fulfilment nodes," which may include partner-operated micro-warehouses that the platform does not call stores at all. A store that opened last week and a store that closed last month both sit in somebody's number. And a single large dark store in a dense urban block serves a radius that four small stores in a sprawling suburb cannot match.

The deeper problem is that store count answers a question nobody in a category team actually has. A brand manager does not need to know how many buildings a platform leases. They need to know whether a consumer standing in a specific pincode can order their product in ten minutes, and what else that consumer is shown alongside it.

That is a measurable thing. Store count is not.

A claim versus an observation

Every dark store number in circulation originates from the platform: an investor deck, an earnings call, a press statement, a recruitment page. It is a claim. It is unverifiable from outside, it is stated at a moment of the company's choosing, and its definition can shift between quarters without anyone announcing the shift.

Serviceability is different. You can observe it. Submit a location to the platform the way a consumer would, and the platform tells you whether it serves that location. It tells you what catalogue it will show. It tells you what delivery promise it makes. It tells you what is in stock right now.

That response is the ground truth of coverage. It is what the consumer experiences. It does not depend on anyone's definition of a store, and it cannot be quietly restated later.

How to measure serviceability from outside

The mechanism is the platform's own location gate. Quick commerce apps and sites ask for a delivery location before showing a catalogue, because the catalogue is store-specific. That gate is the measurement instrument.

The collection sequence for one observation:

• Submit a target location — a pincode, or a coordinate pair inside that pincode.
• Record whether the platform accepts it, rejects it, or accepts it and then shows an unserviceable state.
• If served, record the delivery promise shown and any store or node identifier the response exposes.
• Retrieve the catalogue available at that location: category tree, listing counts, and the status of a defined watchlist of products.
• Record the timestamp and the collection method used.

Two details matter more than they look. First, submit a coordinate inside the pincode rather than the pincode string alone where the platform accepts both, because platforms resolve pincodes inconsistently and coordinates are unambiguous. Second, always capture the catalogue alongside the yes/no. A serviceability flag without an assortment reading is half a measurement, for reasons covered below.

The collection mechanics — location gate handling, coordinate resolution, and catalogue capture — are covered in our quick commerce data collection service.

Designing a pincode sample

India has roughly count of active delivery pincodes, sourced and stated pincodes. Querying all of them across several platforms on a monthly cadence is possible but usually unnecessary, and the cost buys precision you will not use.

Stratified sampling gives national coverage figures with a stated confidence interval at a fraction of the volume. Build the frame like this:

• Stratify by urban tier. Metro, tier 1, tier 2, tier 3, and rural pincodes behave differently, and the interesting movement is at the tier 2 and tier 3 boundary. Oversample there.
• Stratify by state. Coverage expands state by state, and a national figure that hides state variance is not actionable for a regional brand.
• Census the metros. In the top cities, query every pincode. The population is small, the density of commercial interest is high, and edge effects within a city are exactly what a trade team needs.
• Sample the long tail. Draw a random sample within each remaining stratum, sized to your target margin of error, and hold the sample fixed across periods.

Holding the sample fixed is the single most important design decision. A coverage series built on a changing sample measures your sampling, not the platform. Add new pincodes as a separate cohort and report both the like-for-like series and the expanded one. The hyperlocal serviceability insights service implements fixed frames with cohort-based reporting.

What coverage means at the edges

Binary coverage is a convenient fiction. Real serviceability is ragged, and the raggedness carries the signal.

Partial pincodes. A pincode can span a serviced block and an unserviced one. Querying a single centroid coordinate will call the whole pincode served or unserved, and both answers will be wrong somewhere. For large-area pincodes, query multiple coordinates and record the proportion served.

Time-bounded serviceability. A location served at 7pm may be unserved at 7am, or served with a longer promise. Any coverage number carries an implicit time-of-day. State it, and for key pincodes measure at two or three daily slots.

Serviced but empty. The platform accepts the location and returns a catalogue with almost nothing in it. Technically served. Commercially irrelevant.

Promise tiers. Ten minutes, thirty minutes, and next-day scheduled are three different products. Collapsing them into "served" destroys the distinction a category manager cares about most.

Soft launch states. New areas sometimes appear with a restricted catalogue before full launch. These are the leading indicator of expansion, and only repeat measurement reveals them.

Location resolution and geography-master maintenance — state, district, city, urban tier — are covered in our location and geo data services.

Field schema for a coverage record

One row per platform × location × observation window.

The assortment_depth_index is the field that makes the dataset useful rather than merely accurate.

Why monthly re-measurement is the minimum

Coverage is not a stable attribute. Platforms open nodes, close nodes, re-draw delivery polygons, and change the assortment a node carries. A coverage map collected once is a photograph of a moving object.

Monthly is the practical floor for a national panel. It catches expansion into new cities within a reporting cycle and it produces enough points to distinguish a trend from noise. Weekly is appropriate for a metro census, where polygon changes are frequent and competitive response windows are short.

Report changes as cohorts, not as a net figure. Newly served pincodes, newly unserved pincodes, and promise-tier upgrades or downgrades each mean something different. A net change of zero can hide substantial churn.

Store and node identifiers exposed by the platform are recorded in our store locator intelligence service so that node-level coverage patterns can be analysed alongside pincode serviceability.

Coverage and assortment are one metric

A pincode where a platform is live but carries observed listing count in thin-assortment pincodes listings against a national maximum of observed maximum listing count is not covered in any sense a brand should accept. The consumer can order, but not your product, and often not the pack size that matters.

So report coverage as a two-dimensional distribution, not a percentage. For each platform, cross serviceability against assortment depth bands. The resulting table shows where the platform is genuinely operating, where it is nominally present, and where your own products are absent from otherwise deep catalogues — which is a distribution gap, not a coverage gap, and needs a different conversation with a different team.

Product-level availability within served pincodes is tracked in our product availability tracking service, and category-level depth in our assortment depth analysis service. Both join to the same coverage records on pincode and platform.

Actowiz Solutions builds pincode-level serviceability and assortment panels across Indian quick commerce platforms, with fixed sampling frames, documented collection methods, and audit fields on every record. Coverage, promise tier, and catalogue depth arrive as one dataset rather than three.

You can also reach us for all your mobile app scraping, data collection, web scraping, and instant data scraper service requirements!