Pricing & Promotions
Brand & Intelligence
Digital Shelf & Search
Assortment
For Retailers
E-Commerce Dashboard
Flipkart Insights (Live) 
Grocery Intelligence.svg)
Grocery Price (U.S.).svg)
Quick Commerce (India) 
Food & Restaurant
Fashion Intelligence
Automotive
Travel & Hospitality
Real Estate
Food Delivery Intelligence 
OTT & Streaming 
By Use Case
Pricing Intelligence
Digital Shelf Analytics
MAP Monitoring 
Cross-Border Price Parity 
Share of Search
Review Sentiment
Kitchen Market Gaps 
Dynamic Pricing / AI Repricing 
Promotions & Deals Alerts 
B2B / POI & Lead Data 
By Region
Flipkart Real-Time Insights
Quick Commerce — Zepto · Blinkit
Pincode Price Tracker
GCC Q-Commerce — Talabat · Noon 
UK Grocery — Tesco, Sainsbury's, Asda
AU Grocery — Coles & Woolworths 
Marketplace Scrapers
Developer APIs
Universal APIs
Delivery & SDKs
Knowledge Center
Guides & Playbooks
Downloads & Tools
Trust & CompanyIndia festive season 2026 tracking playbook
A window that runs for weeks, not days, and where pincode-level collection stops being optional.
India's festive window is the longest and most fragmented major retail event anywhere. Marketplace sale phases, quick commerce surge, and genuinely different behaviour by city and pincode — a national daily snapshot captures almost none of it.
What this page is, and what it is not
This is a preparation playbook published in August 2026 for a window running October to November 2026. It contains no findings about the 2026 season, because it has not happened.
Publishing 2026 festive discount figures now would be a forecast presented as a measurement. The collection design below is knowable in advance; the results are not.
What it does contain is what changes in this window, why pincode-level collection is not optional here, and the measurement errors that recur every year.
Findings will be added after the window closes, with dates, cadence and the SKU and zone population stated.
What actually changes in the festive window
It is a sequence of phases, not an event
Unlike a single-day event, the Indian festive window runs through distinct phases: pre-Navratri teasers, the main marketplace sale events, the Dhanteras and Diwali peak, and a post-festive clearance run.
Each phase has different mechanics. Early phases lean on bank offers and exchange programmes; the peak leans on outright discounting and bundles; the tail is clearance.
A dataset that collects only during the headline sale events sees perhaps a third of the window. Collection should run continuously from late September through late November, at varying cadence.
Pincode-level variation is the defining feature
Quick commerce is a major channel in this window and its catalogues are selected per dark store. Assortment, price, availability, delivery promise and fees all vary by the pincode a shopper is standing in.
National figures in this window are averages across many different local markets and describe none of them. This is the single largest difference between festive tracking in India and in Western markets.
Critically, listed and in_stock must stay separate. In a window where surge demand causes genuine stock-outs, conflating them with SKUs that were never ranged in a zone produces unavailability figures that send teams chasing supply problems that do not exist.
Bank offers and exchange programmes are not price discounts
A meaningful share of festive discounting in India is delivered through bank card offers, no-cost EMI, and exchange or upgrade programmes rather than through the listed price.
Treating these as price reductions produces a wrong number in either direction depending on how you handle them. Treating them as invisible understates competitor aggression substantially.
Capture them as separate mechanics with their conditions — card issuer, minimum spend, cap, EMI tenure — rather than folding them into an effective price. Whether a bank offer is available to a given shopper depends on their card, which is not public.
Membership and zone-tier pricing add a second price layer
Several platforms run membership pricing that is displayed publicly alongside the standard price. In this window the member price is frequently the price most baskets pay.
A dataset holding only the standard price describes a market that a minority of shoppers experienced. Capture both, compute an effective price, and never backfill a member price with the standard one — that single substitution can invert a competitive index.
What to track, and at what frequency
Cadence recommendations assume a tiered design: the highest frequency on the SKUs and zones where a competitor move changes your decision, lower on the tail.
| What to track | Why it matters in this window | Frequency |
|---|---|---|
| Price by pincode, with timestamps | Quick commerce and marketplace pricing both vary by zone. A national price is an average of markets that do not exist. | Hourly on priority zones |
| Standard and membership price separately | On discounted lines the member price is often the modal transaction price. Never backfill one with the other. | Hourly |
| listed and in_stock as separate fields | Surge stock-outs and never-ranged SKUs look identical if merged, and one is a supply problem while the other is a category one. | Hourly |
| Bank offers and EMI mechanics | Card-linked discounts and no-cost EMI are a large share of festive value and are not price reductions. | Daily, with conditions captured |
| Exchange and upgrade programmes | Common in electronics and appliances, and material to effective price without appearing in it. | Daily |
| Delivery fees and promise | Surge fees and slipping delivery promises are competitive signals in this window. | Hourly on priority zones |
| Sponsored placement and shelf position | Paid placement density rises sharply and changes what shoppers see per zone. | Daily per zone |
| Event-only SKUs and bundles | Festive bundles appear and vanish. Counting them as range changes distorts assortment analysis into December. | Daily |
Five measurement mistakes specific to this window
National collection
The defining error. Quick commerce catalogues are selected per dark store, so a national figure averages markets that do not exist. Pincode is a dimension, not a setting.
Merging listed and in_stock
In a surge window this is expensive. A 40% unavailability figure that is mostly never-ranged SKUs sends supply chain after a category decision.
Folding bank offers into an effective price
Whether a card offer applies depends on the shopper's card, which is not public. Capture the mechanic and its conditions; do not compute one price from it.
Collecting only during headline sale events
The window runs six to eight weeks in phases. Collecting only during the main events sees roughly a third of it and misses the sequencing entirely.
Ignoring membership pricing
Where a platform shows a member price publicly, that is frequently what most baskets pay. Holding only the standard price describes a minority experience.
What we will publish after the window
After the window we will add findings collected across marketplace and quick commerce channels: discount depth by category and phase, pincode-level variance in price and availability, the share of festive value delivered through bank offers rather than price, and stock-out duration through the peak.
Each figure will carry its date, cadence, and the SKU and pincode population it came from, plus a note where zone coverage was thin. Aggregate festive numbers without a stated zone population are not interpretable.
If you want this on your own SKU and zone set rather than our aggregate, the design above is what we would run. Setting up in August or September gives you a clean pre-festive baseline.
Questions about this playbook
Including why there are no 2026 figures on it yet.
Because the window runs October to November 2026 and this was published in August. Publishing figures now would be a forecast dressed as a measurement.
Findings will be added after the window with dates, cadence and the SKU and pincode population stated.
Fewer than most teams assume, but chosen deliberately. Cost scales with pincodes times SKUs times frequency, so 500 SKUs across 1,800 pincodes hourly is roughly nine times the cost of the same SKUs across a well-chosen 200.
We design around revenue-weighted metros, sample one pincode per dark store cluster to remove redundancy, include income-tier variation deliberately, and add a rotating low-frequency sweep to validate the dense sample.
Yes, as separate mechanics with their conditions — card issuer, minimum spend, cap, EMI tenure — rather than as a price reduction.
We deliberately do not compute a single effective price from them, because whether an offer applies depends on the shopper's card, which is not public. Any vendor producing one confident festive effective price is inventing it.
August or September, so you have a clean pre-festive baseline before the run-up begins. Production goes live in 5 to 10 business days after scoping; a pilot returns real data in 48 hours.
Starting in October means computing every depth figure against a reference price you never observed.
Yes, and they need different designs. Marketplace collection is SKU and seller-offer shaped; quick commerce is pincode and dark-store shaped with listed versus in-stock separation.
We run them as separate collections that join on product identity, rather than forcing one schema across both — which produces a table where most fields are null on most rows.
Get this running before the window opens
A pilot on your own SKUs returns real data within 48 hours, and production goes live in 5 to 10 business days. The part teams lose by starting late is the pre-window baseline.
Free pilot, no card, no obligation.
4.8/5 Average Rating
50+ Video Testimonials
92% Client Retention
50+ Countries Served
 377-7584 (USA).svg){kind=icon}
