What QR Menu Analytics Can and Cannot Tell You

What a scan actually records

Start with the mechanism, because most bad conclusions come from imagining a richer one.

A dynamic code points at a short URL owned by the platform, which records the request and redirects to your menu. That request is the entire raw material. From it, a platform can honestly derive roughly this much:

That is the honest list. There is no name, no email, no phone number, no order, no spend, and no way to connect two visits on different days.

The four numbers worth watching

Most menu dashboards show a dozen figures. Four of them change decisions.

Language mix

The share of guests reading in each language you publish. For a tourist venue this is the highest-value number on the page, because it is the only one that tells you which translation to pay a human to fix. If a fifth of your guests read the German menu, the German dish names are worth an hour of a German speaker's time — see restaurant menu translation.

It also tells you which language to add. A steady trickle of guests reading English in a room where you expected none is a demand signal you did not have to commission research to get.

Scans per service, over weeks

Not per day. Restaurant demand is weekly and seasonal, so a Tuesday is only comparable to other Tuesdays. What you are watching for is the trend line across a month, and the step changes that follow something you did.

Peak hours

When scanning actually clusters, in your own timezone. Useful mainly as a check on assumptions: kitchens are often confident about when the rush starts and occasionally wrong by half an hour.

Item views, as shares rather than counts

How often an item is opened, expressed as a share of menu opens or of its own category. Raw counts mostly measure how busy the week was. Shares measure attention, which is the thing you can act on.

What these numbers cannot tell you

This is the half the category does not write about, and it is the half that prevents expensive mistakes.

• Whether anyone ordered. The menu is a document, not a till. Unless the platform is also your POS, it has no idea what left the kitchen.
• How many people ate. One scan frequently serves a table of four, and one guest sometimes scans three times because the page reloaded.
• Whether a guest enjoyed anything. Views measure consideration and nothing else.
• Who anyone is. No identity is collected, so no figure here can be attached to a person or a booking.
• Whether a returning visitor is a returning guest. The visitor hash is rebuilt daily, so yesterday's visitor and today's are unrelated as far as the data is concerned.
• Whether a scan happened at the table. A code photographed in a window at 11pm and opened on the bus home is indistinguishable from a seated guest.

That last one has a corollary worth stating: a window sticker and a table tent measure different behaviours, and averaging them together produces a number that describes neither. Print them as separate codes.

Scans versus covers: the mistake that ruins every conclusion

The most common error is treating a scan as a guest, then dividing something by it.

A four-top where one person scans and reads the menu aloud is one scan and four covers. A couple who both scan, and one of whom reloads after losing signal, is three scans and two covers. Neither is unusual, and the ratio between them is not stable across services — parties are larger at the weekend.

So the ratio moves for reasons that have nothing to do with your menu, which makes "scans per cover" a poor headline metric and a decent anomaly detector. Track it if you like, but only react to a sustained move, and check party size before concluding anything about the menu.

Covers come from your own POS or your reservation book. Bring that number to the scan data yourself; no menu platform can supply it for you.

Reading item-view data without over-fitting

Item views are the genuinely new information — a paper menu cannot tell you what a guest considered and rejected. They are also the easiest data to over-read.

Three cautions before you draw anything from them:

1. 1Position is a confound. The first item in the first category collects views because it is first. Comparing it to the last item in the last category compares two positions, not two dishes.
2. 2Photos pull taps. An item with an image will out-view an identical item without one, so a view comparison across items that differ in presentation is not measuring appetite.
3. 3Small numbers lie. A dish with nine views in a month has told you nothing. Wait for a few hundred menu opens before treating a share as real.

What survives all three is the interesting case: an item with a high view share that you know sells badly. That gap — considered often, ordered rarely — is a diagnosis a paper menu could never hand you, and it is the subject of menu engineering.

Privacy: what you are collecting, and what you should not

Guests do not consent to a menu the way they consent to signing up for something. That raises the standard rather than lowering it.

The defensible design counts events without building profiles. In myQRMenu, a visitor is identified by a hash of the requesting address combined with the venue, the date, and a server-side secret. Because the date is inside the hash, it changes every night — the same phone is a different visitor tomorrow, and cannot be followed across days or between two venues. That is deliberately a weaker identifier than the industry norm, and it is why unique-visitor figures here should be read as directional.

Things worth refusing regardless of what a platform offers:

• Requiring an email address or a phone number before the menu appears. It converts a menu into a lead form and produces data you now have to protect.
• Advertising trackers on a menu page. A guest reading the specials has not opted into an ad network.
• Retaining raw addresses. If you can reconstruct who scanned, so can anyone who obtains the database.
• Table-level identifiers combined with timestamps, which get close enough to identifying individuals to be worth avoiding.

If you operate in the EU or UK, the safe position is that scan data is analytics on a public page rather than personal data you have permission to build a profile from. Keep it that way and the question stays simple.

Turning one month of data into one menu change

The failure mode is checking the dashboard daily and changing nothing. A month, once, with one decision at the end of it, beats thirty glances.

1. 1Leave it alone for four weeks. Change nothing about the menu during the window, or you will not know what moved anything.
2. 2Read the language mix first. If a language you publish has meaningful share, that translation goes to a human. If a language you do not publish keeps appearing in your dining room, add it.
3. 3Take the top ten items by view share and mark the ones you know sell poorly. That short list is your candidate set.
4. 4Pick one item from it. Change exactly one thing: the description, the photo, or the position.
5. 5Wait another four weeks, then compare the same four weeks of the following month rather than the days either side of the change.
6. 6Write down what you changed and when. Six months on, a dashboard with no changelog is a chart nobody can interpret.

Step six is the one that gets skipped and the one that makes the other five compound. The data is thin enough that its main value is telling you where to look — the decision still comes from you, and from the sales numbers only your own system holds.

For what the same menu does for search visibility rather than for the dining room, see restaurant menu seo.