Quick commerce in the GCC has moved from a convenience experiment to a channel that brands, grocers and investors track closely. Yet comparisons between apps, cities and categories are often unreliable, because the data behind them was collected from a single location, at a single time, with baskets that do not match. This piece sets out a measurement framework rather than findings. It describes what to track, how to sample, where studies typically go wrong and how to handle bilingual catalogues.
Why quick commerce is hard to measure
Quick-commerce apps are local by design. The catalogue, price, stock and delivery promise a shopper sees depend on the dark store serving their address. Two shoppers a few kilometres apart can see different assortments and different delivery fees at the same moment. Many apps also show different prices to members, apply time-limited offers and substitute items silently when stock runs out. A benchmark that ignores these dimensions measures the sampling design, not the market.
What to track
We group metrics into four families. Not every study needs all of them, but the choice should be deliberate and documented.
| Family | Metric | Definition | Sampling note |
|---|---|---|---|
| Price | Basket price | Sum of selling prices for a fixed, matched basket | Capture member and non-member prices separately |
| Price | Promotion depth | Difference between regular and promotional price, per item | Record promotion mechanic and end date where shown |
| Price | Fees | Delivery fee, service fee, small-basket surcharge | Depends on basket value and zone; test at set basket values |
| Availability | In-stock rate | Share of basket items purchasable at capture time | Distinguish out of stock from not listed |
| Availability | Assortment breadth | Number of listed items per category | Count per zone, as dark stores differ |
| Service | Delivery promise | Estimated delivery time shown before checkout | Varies by hour and demand; capture across the day |
| Service | Minimum order value | Threshold below which ordering is blocked or surcharged | Check per zone and per app |
| Service | Zone coverage | Whether the app serves a given address | Use a fixed grid of sample addresses |
| Content | Listing completeness | Presence of images, weights, Arabic and English names | Score against a fixed checklist |
Designing the sample
Locations
Start with the cities that matter for the question, typically Dubai, Abu Dhabi, Riyadh, Jeddah, Doha and Kuwait City, then define zones within each city. A zone grid should cover central districts, established residential areas and newer suburbs, because dark store density usually falls with distance from the centre. Fix a sample address per zone and keep it constant across waves. Changing addresses between waves makes trend analysis unreliable.
Time slots
Delivery promises, fees and stock move through the day. At minimum, capture a weekday morning slot, a weekday evening peak and a weekend slot, remembering that the GCC weekend differs by country. Seasonal events deserve their own waves. Ramadan shifts demand to the hours around iftar and suhoor, and major national and regional sale periods change promotion behaviour sharply.
Baskets
A matched basket is the foundation of any price comparison. Build it from products most apps carry, at identical pack sizes, across staples, fresh, household and personal care. Define acceptable substitutes in advance, for example another brand of the same pack size, and flag any substitution in the data. Keep a core basket constant across waves and add a rotating set for category-specific questions.
- Staples: basmati rice 5kg, sunflower oil 1.5L, white sugar 2kg.
- Dairy and fresh: full-fat laban 1L, eggs 30 pack, tomatoes 1kg.
- Household: dishwashing liquid 1L, kitchen towels 2 rolls.
- Personal care: shampoo 400ml, toothpaste 100ml.
A quick-commerce benchmark is only as good as its address grid, its time slots and its matched basket. The apps are local; the measurement has to be too.
Pitfalls to avoid
- Single-location capture presented as a city or national view.
- Comparing member prices on one app with public prices on another.
- Treating a missing item as out of stock when it was never listed in that zone.
- Ignoring fees, which can outweigh item-level price differences on small baskets.
- Mixing web and app data. Some apps show different catalogues or prices on each.
- Comparing waves collected in different seasons without flagging the seasonal effect.
- Reporting delivery promises as delivery performance. The promise is what the app shows; actual delivery time is not observable from public data.
Arabic and English normalisation
GCC catalogues are bilingual, and the two languages are not always maintained in step. A product may carry a full English name and a shortened Arabic one, or the reverse. Matching across apps therefore needs normalisation in both scripts.
| Issue | Example | Treatment |
|---|---|---|
| Eastern Arabic digits | ٥ كجم for 5kg | Convert to Western digits before parsing pack size |
| Unit words in Arabic | غ, جم, كجم, مل, لتر | Map to g, kg, ml and L in a single unit table |
| Letter variants | أرز and ارز for rice | Normalise alef forms, taa marbuta and final yaa for matching only |
| Brand transliteration | One brand spelt several ways in Latin script | Maintain a brand alias table reviewed by a native speaker |
| Mixed-script titles | Arabic name with an English brand embedded | Tokenise by script and match brand and attributes separately |
Keep the original text alongside the normalised version. Normalisation is for matching and analysis, while the original is what shoppers saw and what any evidence should show.
Governance and reporting
Document the address grid, time slots, basket and substitution rules for each wave, and publish them alongside any results. Report confidence alongside averages: the number of observations behind each figure, the share of substitutions and the share of items not found. Collect only public catalogue data, respect app and site terms, and avoid personal data entirely; a quick-commerce benchmark has no need for it.
Getting started
- State the question: price positioning, availability, service levels or assortment.
- Choose cities and build a zone grid with fixed sample addresses.
- Set time slots, including a weekend and any seasonal waves.
- Build and freeze the core basket, with substitution rules.
- Agree normalisation rules for Arabic and English names, units and digits.
- Run a pilot wave, review coverage and adjust before scaling.
The value of a benchmark comes from repeating it consistently. A modest design run every month will say more about the market than an ambitious one run once.