Zomato Data Scraping Services

Menu-item level is where the price lives

Restaurant-level data tells you a restaurant exists and what its rating is. It cannot tell you what anything costs, because pricing on a delivery platform is set per menu item and frequently per modifier.

• Base item price is only the start. Size variants, add-ons and combo options each carry their own price.
• Modifier pricing is where margin often sits. A base price matched to a competitor with more expensive add-ons is not price parity.
• Item availability changes through the day as kitchens run out, which restaurant-level data cannot show.
• Menu structure changes — items added, removed, repriced — are the actual competitive activity.

We collect at item and modifier level with the full option tree, so a comparison is between comparable configurations rather than between headline prices. For chains, this is also how menu consistency across outlets becomes measurable.

Platform markup is the signal most clients come for

The same dish from the same restaurant is frequently priced differently on Zomato than on a competing platform, and differently again for dine-in. Those gaps are commercial decisions — sometimes the restaurant's, sometimes shaped by platform commission structures.

Measuring it requires collecting the same restaurant's menu across channels within the same window and matching items across them. Item names differ slightly between platforms, portion descriptions vary, and modifiers are structured differently, so matching needs confidence scoring rather than exact string comparison.

We deliver match_confidence on cross-platform item matches and flag uncertain ones rather than asserting equivalence. An unmatched item is reported as unmatched, because a false match produces a markup figure that is simply wrong and looks entirely plausible.

What we cannot see is commission rates or restaurant economics. We report the price gap; the reason for it is not published by anyone.

The fee stack is not the item price

What a customer pays is the item price plus delivery fee, platform fee, surge and taxes, minus whatever promotion applies. Those components move independently and are displayed separately.

A price comparison using item price alone can be directionally wrong on total basket cost, particularly on small orders where fees dominate. And fee structures change more often than menu prices do, so a stale fee assumption ages faster than the item data it sits beside.

We capture each fee component separately as displayed at observation time, along with the delivery promise in minutes. We deliberately do not collapse them into a single figure — you can construct whatever total-cost view your analysis needs, and keeping them separate makes fee-structure changes visible as their own signal.