Design a restaurant menu dataset around stores and modifiers
Preserve restaurant locations, menu hierarchy, item options and order context so menu prices remain meaningful.
In this article
THE KEY IDEA
A menu is not just a list of names and prices. Store, channel, size and required modifiers can change what the customer is actually buying.
01Start with the location, not only the brand
A brand can have many stores with different menus, hours and prices. Give each location a stable identity and preserve the source's location identifier where available. Address normalisation helps matching, but a similar address alone should not merge two stores automatically.
Store the channel as well. A brand's own website and a delivery platform can expose different item names, availability and prices. Those differences are part of the dataset, not necessarily extraction errors to be normalised away.
02Keep the menu hierarchy
Represent categories, items, sizes, modifier groups and options as related entities. A required choice can determine the minimum purchasable configuration. An optional topping should not be folded into every item's base price.
Record selection rules such as required versus optional and minimum or maximum choices when they are published. Preserve option-level price adjustments separately. If the source does not expose a rule, leave it unknown rather than inferring it from a single selected order.
store -> menu -> category -> item
item -> modifier_group -> option
observation -> channel + order_mode + timestamp03Define the price you are comparing
Choose whether the analysis concerns base item price, the cheapest valid configuration or a standardised basket. These are different metrics. A meal with a required size choice cannot always be compared with a single-item listing by reading the first visible number.
Keep delivery fees, service fees, taxes and minimum-order conditions separate from menu item prices. Some amounts depend on a basket or destination and may not be visible on a public menu. Do not manufacture a delivered total from incomplete components.
04Capture availability with its scope
An item may be absent because of a daypart, location selection, temporary unavailability or collection failure. Preserve an explicit status and the observation context. Missing from this menu is a narrower statement than unavailable everywhere.
For recurring feeds, compare the same store, channel and order mode across runs. Keep additions, removals and price changes as dated observations. A menu redesign that moves an item between categories should not necessarily create a new item identity.
05Validate the relationships, not just the rows
Check that every item belongs to a known location and every modifier option has a parent group. Review duplicate item names and impossible price adjustments. Manually compare a sample containing required choices, optional extras and temporarily unavailable items.
Deliver a data dictionary with the hierarchy and null meanings. For flat CSV consumers, use separate files or stable join keys rather than squeezing every option into one unstructured cell. The receiving team should be able to reconstruct a valid item configuration without guessing.
References & further reading
Put it into practice.
Try a public-page workflow, or scope a maintained dataset with our team.