How to Run a 30-Day Menu Experiment Using Real Data

Changing your menu based on a hunch and changing it based on a structured, time-boxed experiment produce very different levels of confidence in the result. A month is long enough to see a real pattern and short enough that you're not stuck with a bad change for a whole season.

Before you start: pick one thing to test

The most common mistake in a menu experiment is changing five things at once and then having no idea which change actually mattered. Pick one clear variable: a rewritten description on a specific dish, a repositioning of an underperforming item, a new dish added to fill a gap. Write down what you expect to happen before you start, so you're not tempted to reinterpret the results afterward to match whatever happened.

What to track during the 30 days

• Order frequency for the specific dish or dishes involved
• Reorder rate among guests who tried it
• Verdict or feedback trend, not just raw order counts
• Any change in average order value for tables that ordered the item
• Whether the change affected anything unexpected, like a related dish's orders

Give it the full window before judging

The first week of any change is noisy, driven by whichever regulars happen to visit and whatever else is going on that week. Resist the urge to call it a win or a failure in the first few days. By around day 20 to 30, patterns tend to settle into something you can actually trust, especially if your restaurant sees a reasonable volume of guests.

What a clean result actually looks like

A useful outcome isn't just "orders went up." It's being able to say, specifically, that a rewritten description moved a dish's order rate, or that repositioning a dish on the menu changed how often it got seen and chosen. That specificity is what makes the next experiment easier to run, because you're building a working understanding of your own menu instead of a pile of one-off anecdotes.

A sample week-by-week structure

• Days 1 to 3: make the single change, note the exact date, and resist the urge to check results yet
• Days 4 to 10: watch for any early signal, but treat it as too early to be reliable on its own
• Days 11 to 20: patterns usually start becoming visible here, particularly for dishes with steady order volume
• Days 21 to 30: confirm the pattern holds across a mix of weekday and weekend traffic before calling it a result
• Day 30 and after: document what happened in plain language, so the next experiment builds on this one instead of starting cold

What to do if 30 days isn't enough signal

Some dishes just don't get ordered often enough for a month to produce a clean read, a rarely-ordered specialty item might need six or eight weeks to accumulate a meaningful sample. If that happens, don't force a conclusion from thin data. Extend the window for that specific dish rather than applying a blanket 30-day rule to every item on the menu regardless of its normal order volume. The goal is a trustworthy result, not a result that happens to arrive on schedule.

Running more than one experiment over time

Once you've run a single 30-day experiment successfully, it's tempting to try testing several changes back to back across different dishes at once. That's fine as long as the changes don't touch related dishes that might affect each other's order rate, a rewritten description for one curry and a repositioning of a similar curry nearby can genuinely muddy each other's results. Stagger experiments that might interact, and run genuinely independent ones, on unrelated parts of the menu, in parallel without much concern.

TasteGraph's dashboard is built to support exactly this kind of structured testing, giving you dish-level data over time so a 30-day change is something you can actually measure, rather than something you just have a feeling about afterward, and flexible enough to extend the window when a dish's natural order volume calls for it.