Menus A/B testing

Menu performance is not only what you sell — it is how it is named, pictured, ordered, and offered on each surface. A hero burger might convert on your app but need a shorter title on an aggregator; a combo might belong above the fold on kiosk only.

​

Why testing matters commercially

Fire spark’s intelligence layer sits on top of synced operational data. You are not forking the catalog in Excel; you are experimenting on how the same items show up where customers actually order.

​

What you can test

• Titles and descriptions — Clarity vs appetite appeal per channel.
• Images and placement — Which category order lifts attachment rate on web vs app.
• Assortment — Subset on Uber Eats, full menu on owned channels (menu composition).
• Modifiers and groups — Drink choice framing, upsell order, default selections.
• Schedule — Breakfast block vs all-day on selected surfaces.

Tests respect store, channel, fulfillment, and hours — the same dimensions you already use to compose menus.

​

How teams work in practice

1. Hypothesis — “Kiosk converts better when combos are the first category.”
2. Compose — Apply variant on kiosk channel only; POS master unchanged.
3. Measure — Compare mix and ticket against control via consolidated analytics.
4. Scale or revert — Roll winning layout to more stores; no re-integration.

​

What you stop worrying about

Kitchen tickets still map to real products and modifiers. When you 86 an item in the POS, it disappears from test and control alike. Operations does not learn a second menu language for experiments.