Multi-City Quick Commerce Price & Availability Tracking, Three Times a Day

The Problem: Q-Commerce Prices Don't Hold Still

Quick commerce broke the assumption that a price is a property of a product. On Blinkit, Zepto and Instamart, the same SKU can carry a different price, a different discount and a different availability state depending on which dark store serves the customer — and all three can change between morning and evening.

This client's category managers were working from a spreadsheet that a field team filled in once a week by opening apps on their phones. By the time the sheet was consolidated:

• Competitor promotions that ran for 48 hours had already ended
• Out-of-stock events in specific cities were invisible unless someone happened to check that city that day
• There was no way to answer "were we cheaper than the competitor last Tuesday?" because nothing was stored
• Pack-size and MRP mismatches between platforms went unnoticed, causing channel conflict complaints from distributors

The brief that reached us was simple to state and hard to execute: give us the same data the field team collects, but for every city, every SKU, three times a day, in a format our BI tool can read.

Why This Is Harder Than Standard E-Commerce Scraping

On a conventional marketplace, one product URL returns one price. Q-commerce platforms are location-resolved: the catalogue you see is a function of the serviceable dark store, which is resolved from a pincode or a lat/long. Four specific complications shaped the build:

• Location dependency. Every request has to carry a valid location context, and the same SKU must be requested once per city to produce a comparable row.
• Catalogue volatility. Products appear and disappear from category listings as dark-store inventory shifts, so a pure SKU-list approach silently loses coverage. Category traversal has to run alongside it.
• Three collection windows per day means the pipeline has roughly a two-hour envelope to finish, validate and deliver — there is no room for slow retries.
• Cross-platform normalization. Pack sizes, unit descriptors and brand strings differ by platform. Without normalization, "500 g" and "0.5 kg" become two different products and every comparison breaks.

What Made It Work

• Hybrid scope beats either approach alone. SKU-only tracking is cheap and blind to new competition. Category-only tracking is comprehensive and unreliable for the specific rows the client cares about. Running both is the only configuration that survives a volatile catalogue.
• Normalization is the actual product. Five platforms describing the same 500 g pack five different ways is the difference between a dashboard and a data-cleaning project. That mapping layer, maintained over time, is where the recurring value sits.
• Fail loudly, not quietly. A pipeline that delivers a suspiciously small file is worse than one that delivers nothing and says so. Coverage thresholds mean the client trusts the number in front of them.

Is This Replicable for Your Brand?

The pattern transfers directly to any category sold through Indian quick commerce — FMCG, beverages, personal care, home care, packaged foods, pet care. The variables are which platforms, which cities, how many SKUs and how often.

A typical starting point is a single-city, single-platform, two-week pilot against a defined SKU list. It proves schema fit and refresh reliability against your own BI stack before scale-up.

Actowiz Solutions has 17 delivered quick-commerce projects and 290+ active feed configurations across Blinkit, Zepto, Swiggy Instamart, BigBasket, Flipkart Minutes and related platforms, at frequencies from once-off to four times daily.

FAQ

How often can quick-commerce data be collected?

From once-off snapshots to four times a day. Three times daily is common for pricing and promotion tracking; daily suits availability monitoring; hourly is feasible for narrow SKU sets during high-volatility periods like festive sales.

Can you track prices for a specific city or pincode?

Yes. Quick-commerce catalogues resolve by serviceable location, so city and pincode-level collection is the native way to work with these platforms. Coverage is configured per city or per pincode list.

Which quick-commerce platforms do you cover in India?

Blinkit, Zepto, Swiggy Instamart, BigBasket, Flipkart Minutes and Flipkart Wholesale, plus JioMart, DMart and Udaan for adjacent retail. Additional platforms are added on request.

What format is the data delivered in?

Structured CSV, Excel, JSON or direct API, in your schema. Delivery via email, Google Drive, SFTP, cloud bucket or push API. Most pricing clients take scheduled file drops into an existing BI pipeline.

Do you handle pack-size normalization across platforms?

Yes. Unit and pack-size normalization is part of the pipeline, not a client-side task. Without it, cross-platform price comparison produces false mismatches.

Can we start small?

Yes. Single-city, single-platform pilots against a defined SKU list are the standard entry point.