Menu & item pricing
The core dataset, with structure preserved.
- Item name, category and description
- Base price and configured price
- Combo and meal-deal pricing
- Item availability and sold-out state
- Menu section hierarchy
Menu-item level, because that is where the pricing actually happens.
A restaurant does not have one price. It has a menu price, an aggregator price, a modifier price, a combo price and a delivery fee stacked on top — and all five differ by store and by platform. Flattening that into one number destroys the analysis.
Free pilot on your own sources, returned in 48 hours. No card, no trial clock — and you keep the sample data either way.
Last verified 5 August 2026 by the Actowiz Solutions Data Engineering team.
Food data scraping is the automated collection of structured data from restaurant and food delivery sources: menu items with their prices, modifier and option pricing, store-level availability, delivery and service fees, promotional offers, ratings, review counts and preparation time estimates.
What makes this category distinct from general retail extraction is that the unit of analysis is not a product — it is a store-platform-item combination, and every part of that triple changes the price.
Any dataset that reports a single price for that dish has made an undeclared choice about which of the four it means. We capture all of them as separate fields, because pricing teams and investors need different ones.
A national chain does not price nationally on delivery platforms. Franchisees set their own prices within limits, platform markups vary by market, and promotional participation is often store-by-store. A brand-average price hides variance that is frequently 15–25% across a single chain's estate.
We treat the individual store as the record, geocoded, with a stable identifier so its history stays continuous. That is what allows trade-area analysis, franchisee price compliance checks and coverage-gap identification — none of which is possible from a brand-level feed.
For many concepts, modifiers carry most of the margin. Pizza toppings, protein upgrades, size options and add-ons are where average order value is built. Extracting the item and discarding the modifier tree removes the commercially interesting part of the menu. We preserve the hierarchy, including which option groups are required, which are exclusive, and what each option costs.
Most engagements begin with competitor menu pricing and expand into fees, coverage and ratings once the store keys are in place.
The core dataset, with structure preserved.
Where average order value is actually built.
The gap between menu price and what a customer pays.
Which locations are actually live, where.
Customer signal at store level.
Where a store appears when someone is hungry.
A managed engagement, not a tool licence. We own the pipeline and everything that breaks in it.
Every engagement delivers a documented schema. These are the core fields; the full dictionary runs to 120+ and is agreed during scoping.
| Field | Type | What it captures | Refresh |
|---|---|---|---|
store_id |
string | Stable store identity persistent across runs, so store history stays continuous | Every run |
brand / store_name |
string | Chain brand and the store's own listed name, which often differ | Weekly |
platform |
enum | Delivery aggregator or the brand's own channel, since pricing differs by platform | Every run |
lat / lon / city |
decimal / string | Geocoded store location, enabling trade-area and coverage analysis | Weekly |
item_name / category |
string | Menu item and its section within the menu hierarchy | Daily |
base_price / configured_price |
decimal | Listed price and price once required modifiers are selected | Daily to hourly |
modifiers |
array | Option groups with per-option pricing and required or exclusive flags | Daily |
platform_markup_pct |
decimal | Aggregator price versus the brand's own-channel reference price | Daily |
delivery_fee / service_fee_pct |
decimal | Fees applied on top of item pricing, captured separately | Daily |
available / paused_reason |
boolean / string | Item and store availability with reason where the platform states one | Hourly tier |
rating / review_count / prep_min |
decimal / int | Store rating, review volume and stated preparation time | Daily |
Configured price is computed from the required modifier tree, not estimated. Where a platform hides pricing until a location is set, we collect per delivery zone rather than reporting a national placeholder.
Aggregator coverage varies sharply by country. We build to your market list and state per-platform limits before contracting.
Some aggregators expose pricing only after a delivery address is set, which means collection must run per delivery zone. That multiplies volume, so we scope zones deliberately rather than defaulting to national coverage. Request a source we don't list →
We deliver into 40+ countries. These are the markets where this particular service is requested most, and the reason demand concentrates there.
| Market | Why demand concentrates here |
|---|---|
| United States | The most mature aggregator market with the highest platform markups, which makes channel margin analysis the primary buying reason. |
| India | Enormous store density with two dominant aggregators and heavy discounting, so competitive menu tracking runs at high frequency. |
| United Kingdom & Germany | Three-way aggregator competition where the same store prices differently on each platform, making cross-platform capture essential. |
| United Arab Emirates & Saudi Arabia | Fast-growing delivery penetration with aggressive fee promotions and a crowded chain landscape. |
We run production collection across 40+ countries. Coverage depth varies by market and by source, so we confirm what is actually available for your specific markets during scoping rather than claiming uniform global coverage. Ask about a market we don't list →
Restaurant groups and delivery platforms dominate, with CPG and investment teams close behind.
Franchisee and platform pricing drifts across hundreds of stores, and nobody can see where menu price architecture has broken.
Store-level item and modifier pricing across every platform you sell on, with platform markup computed against your own-channel reference price.
Menu price compliance
Aggregator markups, fee structures and promotional participation vary store by store with no consolidated view.
Per-store, per-platform pricing and fee capture with promotional participation tracked, so channel economics become visible by location.
Delivery channel margin
Competitor menu changes, new item launches and price moves are discovered by staff ordering food, not by data.
Daily competitor menu monitoring with item launch and price change detection at store level across your trade areas.
Response time to competitor moves
You need to know how restaurant pricing and coverage compares against competing platforms in each city.
Cross-platform store coverage, pricing and fee benchmarking by city, revealing markup gaps and coverage holes against rivals.
Basket price competitiveness
Foodservice channel pricing and menu presence for your products is invisible compared with retail data.
Menu presence and pricing wherever your products or category appear across chains and independents, tracked over time.
Foodservice distribution
Restaurant theses need observable pricing, unit coverage and rating trajectories rather than quarterly disclosure.
Longitudinal store-count, pricing and review-velocity panels by brand and market, delivered modelling-ready.
Signal lead time
Four patterns, with the outcome each is judged on.
Item and modifier pricing is collected per store per platform and compared against your intended architecture, revealing where franchisees or platform markups have pushed prices outside agreed bands. Because modifier pricing is captured, configured-price drift is visible rather than hidden behind a base price.
Outcome: Price compliance measured across the estate instead of sampled by field visits.
Aggregator pricing, delivery fee, service fee and promotional waivers are captured separately, so the full customer-paid price is reconstructable per store per platform and comparable to your own-channel economics.
Outcome: Channel decisions made on delivered-price economics rather than menu price alone.
Geocoded store data lets competitor menus, prices and ratings be analysed within a defined radius of each of your sites, which is the level at which customers actually choose.
Outcome: Competitive response planned per trade area rather than per national brand.
Store coverage per platform per city is tracked with new-store and delisting detection, showing where competitors are expanding and which areas remain underserved by a cuisine or price tier.
Outcome: Site and platform expansion informed by observed coverage rather than by intuition.
Clients rarely permit naming. These are real engagement shapes with identifying detail removed, so you can judge whether the work resembles your situation.
The group set recommended delivery prices centrally but had no way to verify what several hundred franchised stores were actually charging on each aggregator.
Daily item and modifier pricing per store per platform, compared against the intended architecture with out-of-band stores flagged.
Price compliance became measurable across the estate instead of sampled by area managers.
Competitors piloted new items in a handful of markets before national rollout, and the chain learned about them from employees ordering food.
Store-level menu monitoring with new-item detection across competitor estates in overlapping trade areas.
Competitor item tests surfaced weeks earlier, with the specific markets identified.
Examples are anonymised at client request. Named references are available on request under NDA. See published case studies →
Before you commit to anything, we run this service against your own sources and send you the output. If the coverage isn't there, the sample will show you that too — which is the point. We would rather lose the deal at the pilot than at month three.
Same collection pipeline and same QA underneath. The difference is who holds the schedule and how the data reaches you.
We own the collection, the QA and the delivery. You receive clean data on a schedule and never touch a scraper.
Best fit: Teams who need the data, not the infrastructure.
The same collection pipeline exposed as an authenticated REST endpoint your systems query directly.
Best fit: Product and engineering teams building on live data.
A defined pull for a specific question — market sizing, diligence, a pitch, a one-off audit.
Best fit: Research, strategy and diligence work with a deadline.
Every engagement is quoted individually, because the honest answer depends on your scope: how many sources, how many records, how often, and how the data reaches you. We scope it with you, run a free pilot on your own sources, and then quote a fixed monthly figure — no per-request metering and no overage billing when volumes move. Request a quote and you will have a number after one call.
Zone-based collection and modifier trees are what make this category expensive to build correctly.
| Consideration | In-house scraping team | Generic proxy / DIY tool | Actowiz managed feed |
|---|---|---|---|
| Time to first usable data | 6–12 weeks of engineering before anything is trustworthy | Days, but output needs manual cleanup before use | Free pilot in 48 hours, production in 5–10 business days |
| Who fixes it when a source changes | Your engineers, at the cost of their roadmap | You do — tools report failures, they don't resolve them | We do, same business day, inside the retainer |
| Data quality assurance | Whatever your team has time to build | None beyond HTTP success | Schema validation plus sampled human QA on every run |
| Compliance documentation | Rarely produced, then requested urgently by legal | Not provided; terms risk sits with you | Sources, method and lawful basis documented for review |
| Accountability | Distributed across a team with other priorities | A support ticket queue | A named engineer and an account owner |
| True annual cost | Engineer salaries, proxies, hosting, ongoing maintenance | Low licence fee plus significant hidden analyst time | One fixed monthly retainer, quoted after scoping |
The most common mistake in food data is aggregating too early. A brand-level average price for a menu item feels like a useful summary. In practice it hides exactly the variance that decisions depend on.
The record is the store-platform-item combination, geocoded, with a stable store ID. You aggregate afterwards, at whatever level your question needs — trade area, city, franchisee group, platform or brand. Aggregation is reversible; premature aggregation is not.
For teams that also track retail, this pairs naturally with grocery data and retail pricing data, since foodservice and retail pricing increasingly influence each other on the same categories.
Menu price is the least interesting number in food delivery. What determines whether an order converts is the total at checkout, and that total is assembled from components which platforms present inconsistently and change frequently.
Two stores with identical menu prices can present customer totals 20% apart once this stack is applied. Any competitive analysis that stops at item price is comparing the wrong number.
We could deliver one computed customer-paid total, and some vendors do. We deliver the components instead, because the correct total depends on assumptions only you can make: basket size, distance band, subscription status, promotional eligibility. A single total bakes in someone else's assumptions and cannot be unbaked.
With components separated, you can model the total for your own scenarios — a typical basket in a typical zone for a typical customer — and change those assumptions later without recollecting anything.
Store lists, platforms and delivery zones are scoped first, since zone-based collection drives volume and therefore cost.
You send us target sites, regions, SKUs or keywords. We return a field-level schema proposal, coverage estimate and refresh recommendation — usually within two working days.
We extract a real sample from your actual targets so you can inspect field fill rates, edge cases and match quality before any commitment.
Our engineers build extractors, then wire validation rules: type checks, range checks, duplicate detection and golden-record comparison against a manually verified subset.
Feeds run at your chosen cadence and land in the warehouse or bucket you already use. Schema changes are versioned and announced before they ship.
We watch coverage drift, fill rates and source changes daily. A named engineer owns your account, and layout breaks are fixed by us — not queued for you.
JSON, JSONL, CSV, Parquet or XLSX, delivered to Amazon S3, Google Cloud Storage, Azure Blob, SFTP, Snowflake, BigQuery, Databricks or a REST/GraphQL endpoint. Webhooks fire on completion, and every batch ships with a manifest containing row counts, schema version and QA results so your pipeline can fail loudly instead of silently ingesting a bad file. Geocoded store records load directly into PostGIS or BigQuery GIS for trade-area work.
We collect publicly accessible menu, store and pricing pages. Where a platform requires a delivery address to display pricing, we collect per zone using generic location input — we do not create accounts, use customer credentials or place orders. Courier and customer personal data is never part of the deliverable. Methodology is documented per platform and market.
These are contractual, not marketing copy. They appear in the engagement document.
| Commitment | What we hold ourselves to |
|---|---|
| Pilot turnaround | A real sample from your own sources within 48 hours of scoping, at no cost. |
| Go-live | Production collection running within 5–10 business days of sign-off. |
| Delivery punctuality | 99.5% on-schedule delivery, measured monthly and reported to you. |
| Breakage response | Source layout changes triaged same business day; critical sources inside 4 hours. |
| Data quality | Schema validation on every run plus sampled human QA before any delivery leaves us. |
| Escalation | A named engineer and an account owner, not a shared ticket queue. |
| Change requests | Field additions and source changes handled inside the retainer, not re-quoted. |
| Exit | Your historical data exported in full on request. No lock-in, no export fee. |
Plain definitions of the terms used on this page, so procurement and legal reviewers are working from the same vocabulary as your data team.
What buyers ask during evaluation.
Yes, by collecting per delivery zone using generic location input rather than customer accounts or credentials. This is how several major aggregators work, so it is not an edge case — it is the normal mode of collection in this category.
The practical consequence is volume: one store across twelve zones is twelve times the collection. We scope zones deliberately with you rather than defaulting to blanket coverage, because zone selection is usually where cost is won or lost.
Both, and the modifier tree is preserved as a hierarchy rather than flattened. Option groups arrive with required and exclusive flags, per-option pricing and size or portion tiers.
This matters more than buyers usually expect. For pizza, burrito and build-your-own concepts, modifiers carry much of the margin, and the base price on its own is close to meaningless — a bowl with a mandatory protein choice has no price until that choice is made. We deliver a configured price computed from the required tree alongside the base price.
By making the store the record rather than the brand. Every store carries a stable ID and coordinates, and its pricing history stays continuous across runs.
Within a single chain, the same item routinely varies 15–25% across the estate because franchisees set prices within bands and platform markups differ by market. A brand-level average conceals exactly the outliers a compliance or pricing team needs to see, so we never aggregate before delivery.
We deliver the components — item price, delivery fee by distance band, service fee percentage and cap, small-order fee and promotional waivers — rather than one computed total.
That is deliberate. The correct total depends on basket size, distance, subscription status and promotional eligibility, and any single figure bakes in assumptions you cannot later remove. With components separated you model your own scenarios and change the assumptions without recollecting data.
Platform terms typically restrict automated access, and we are direct about that rather than pretending otherwise. Our position is that we collect only publicly accessible menu and pricing pages, at low request rates, without creating accounts, using customer credentials or placing orders.
We do not claim this eliminates every consideration — it does not, and your counsel should review it. What we provide is a written methodology document per platform describing exactly what we access and how, so that review is possible. Vendors who present this as entirely risk-free are the ones to be careful with.
Yes. Because menus are collected as structured hierarchies with stable store IDs, a new item appearing in a menu section is detected as an event with a first-seen date, per store. Removals are detected the same way.
Launch patterns are informative in this category: chains frequently test items in a handful of markets before national rollout, and store-level collection surfaces those tests weeks or months before any announcement.
Menu prices move on a scale of weeks to months. Fees and promotions move constantly — delivery fees can be dynamic by demand, and promotional offers change daily or intra-day. Availability changes hour to hour as stores pause and items sell out.
We recommend daily for menu and pricing, with an hourly tier for availability and fee monitoring on priority store sets. Full-estate hourly collection is rarely worth its cost, since most of what changes hourly is availability rather than price.
Yes, and for trade-area analysis independents usually matter more than chains, since they are the actual competitive set for most locations. Coverage is broad on aggregators because independents are listed there.
The honest limitation is matching. Independents have inconsistent naming, frequently appear under slightly different names across platforms, and open and close often. We attach match confidence at store level and flag ambiguous cases rather than silently merging two restaurants that may not be the same business.
We quote individually. The dominant cost driver in this category is not store count — it is zones multiplied by refresh frequency, because zone-based collection multiplies volume before any store is added.
A defined competitor set in a handful of cities at daily refresh sits at the lighter end. National multi-platform coverage with zone-level pricing and hourly availability sits considerably higher. The process: one scoping call, a free pilot on your own store list within 48 hours, then a fixed monthly quote with sources and zones added inside the retainer. Request a quote.
Send us a brand, a city or a store list. We return item and modifier level pricing across platforms within 48 hours, with delivery fees captured separately.
Free pilot, no card, no obligation. We'll tell you which platforms need zone-level collection in your markets.Our web scraping expertise is relied on by 4,000+ global enterprises including Zomato, Tata Consumer, Subway, and Expedia — helping them turn web data into growth.
Watch how businesses like yours are using Actowiz data to drive growth.
From Zomato to Expedia — see why global leaders trust us with their data.
Backed by automation, data volume, and enterprise-grade scale — we help businesses from startups to Fortune 500s extract competitive insights across the USA, UK, UAE, and beyond.
We partner with agencies, system integrators, and technology platforms to deliver end-to-end solutions across the retail and digital shelf ecosystem.
Learn how UK supermarket price comparison works in 2026. Track prices, promotions, product availability, assortments, and competitor activity across leading grocery retailers to optimize pricing and retail strategies.
How Actowiz Solutions built a daily Top-200 medicines price & availability tracker across Indian epharmacies architecture, effective pricing, alerts & outcomes.
Extract Superdrug Products Data to analyze pricing, product trends, promotions, and inventory for smarter retail market intelligence.
Whether you're a startup or a Fortune 500 — we have the right plan for your data needs.