QR Code Menu Analytics: What to Track and How to Read It
Social posts for this article
Most restaurants treat a QR code menu as a one-way street: print the code, point it at a menu, done. But a QR code menu that lives on a hosted page generates data every time a guest scans it, and that data answers questions you would otherwise guess at. When is your real rush? Which table tents get ignored? Which section of the menu do guests never scroll to? QR code menu analytics turn a pile of table scans into a short list of decisions.
The catch is that most of the numbers on a scan dashboard do not matter, and one of the most prominent ones (total scans) is close to useless on its own. This guide covers what QR code menu analytics can actually tell you, which metrics to ignore, and how to turn the useful ones into repricing, placement, and layout moves.
TL;DR
- A static QR code (a PDF baked into the image) gives you zero data. You need a dynamic code pointing to a hosted menu to get analytics at all.
- Total scans is a vanity metric. Track the path instead: did the scan lead to browsing, and did browsing reach the parts of the menu you care about?
- The three numbers that change decisions: scans by daypart, scans per placement, and section or item views.
- Use the data to fix physical codes, re-sequence menu sections, time your specials, and measure menu changes instead of debating them.
Static vs. dynamic: why most QR menus track nothing
Analytics require a dynamic code. The difference is where the menu actually lives:
- A static QR code encodes the content directly. If it opens a PDF, the file is essentially baked into the pattern. Nothing sits between the guest and the file, so nothing can count the scan. It is also why static codes force a reprint every time a price changes.
- A dynamic QR code encodes a short URL that redirects to a hosted menu page. That redirect and that page can log every visit. You can also change the menu without ever reprinting the code.
If you are still weighing the two formats for reasons beyond analytics, the QR menu vs. PDF menu comparison covers the full trade-off. For the purposes of this article, assume a dynamic, hosted menu, because a static one has nothing to measure.
Total scans is a vanity metric
The biggest number on any scan dashboard is total scans, and it is the one to trust least. A code scanned 900 times a week sounds like a win until you learn those guests scanned, waited three seconds for a slow page, gave up, and flagged a server. High scans with no follow-through is a problem wearing a success costume.
What you want is the path after the scan:
The gap between “menu opened” and “browsed 2+ sections” is where slow pages and bad layouts live. If a big share of scans never gets past the first screen, the fix is not more scans; it is a faster page or a better first section. A menu that opens in under two seconds is doing more for your check average than a marketing campaign.
The three metrics worth watching
1. Scans by daypart
Plot scans by hour and by day of week, and your actual demand curve appears (not the one you assume). Most operators are surprised at least once: the “dead” Tuesday that is quietly busy at 1 PM, the patio that spikes at 4 PM before the dinner rush, the weekend brunch that starts an hour earlier than the schedule assumes.
Two direct uses:
- Time your specials to the scan curve, not the clock. If scans climb at 4 PM, your happy hour code needs to be live and your happy hour menu featured before then, not at 5.
- Sanity-check your labor. A daypart with steady scans and thin staffing is a service problem you can see before the reviews tell you.
2. Scans per placement
If you use a distinct code for each placement (table tents, the window decal, the register card, the to-go bag), you can compare them directly. This is where physical problems surface. A patio code that gets half the scans of an identical dining-room code usually is not a demand issue; it is glare, a flat angle, or a code hidden under a caddy. The QR code menu best practices guide covers the placement and materials fixes, but analytics are what tell you which placement to fix first.
A quick way to read it:
| Placement | Weekly scans | What a low number means |
|---|---|---|
| Dining room tents | 620 | Baseline for a full room |
| Window decal | 210 | Low = wrong height, glare, or too small for walk-by distance |
| Register card | 95 | Low = buried behind the POS or no “take the menu home” verb |
| To-go bag sticker | 40 | Low = guests toss the bag before they ever look |
You do not need a separate code per seat to get value here. Even three codes (dining room, window, register) split your scans into buckets that each map to a specific fix.
3. Section and item views
The richest metric, and the one closest to menu engineering, is which parts of the hosted menu guests actually view. If your dessert section sits at the bottom and almost nobody scrolls to it, that is not a demand signal about dessert; it is a sequencing problem. Move it up and watch the views (and often the attach rate) change.
This is the digital version of the print rule that your best items belong in the first and last slots of each section. When you can see the scroll data, you stop guessing which slots are “first.” Pair this with the menu engineering matrix: the matrix tells you which items deserve the spotlight, and section views tell you whether the spotlight is actually landing on anyone.
Turning scans into decisions
Data you never act on is just a prettier version of a hunch. Four moves the numbers actually support:
- Re-sequence sections. If a high-margin section gets few views, move it up and remeasure. This is a free change on a hosted menu.
- Fix the worst-performing placement. Rank placements by scans, take the lowest, and apply one physical fix (angle, size, glare, location). Recheck in a week.
- Time specials and staffing to the real curve. Let the daypart chart, not tradition, decide when the specials go live and when you add a server.
- Measure menu changes instead of arguing about them. Changed a description, moved an item, or raised a price? Compare views and the resulting order mix before and after. A hosted menu makes the two versions comparable because the code never changed.
That last point is the quiet superpower. Because a dynamic code stays fixed while the menu behind it changes, you can test a change on Monday and read the result on Friday without touching a single table tent. It also means a price change never leaves a stale number on the table, which matters more than most owners think; an outdated menu costs real customers whether the stale price is on Google or on the QR page behind the code.
What NOT to over-invest in
- Chasing raw scan totals. More scans is not the goal; more scans that end in a confident order is. A slow page inflates the scan count with retries.
- Per-item heatmaps at a tiny sample. With 40 scans a week, item-level data is noise. Wait for 60 to 90 days before you read anything into a single item’s numbers, the same sample-size rule the menu engineering matrix uses.
- Guest-level tracking you do not need. You do not need to identify individuals to run a good menu. Aggregate scans, placements, and section views answer every question above without collecting anything sensitive.
- A dashboard you check daily. Menu behavior moves on a monthly cadence, not an hourly one. Set a monthly review, act on one or two findings, and close the tab. This pairs naturally with a sensible menu update frequency.
Frequently asked questions
Can you track scans on a QR code menu at all? Only if the code is dynamic (it points to a hosted URL rather than embedding a file). Dynamic codes can log each visit; static codes that contain a PDF cannot, which is one more reason a hosted menu beats a printed PDF for anything beyond a single unchanging page.
Does tracking QR menu scans hurt guest privacy? Not if you keep it aggregate. Counting scans by hour, placement, and menu section requires no personal data and no login. Avoid tools that try to build individual guest profiles; you do not need them to make menu decisions.
How many scans do I need before the data means anything? For daypart and placement patterns, a week or two of normal service shows the shape. For item-level or section-level conclusions, wait 60 to 90 days so weather, holidays, and one big party do not skew the read.
Do I need a separate QR code for every table to get useful data? No. Splitting by placement type (dining room, window, register, to-go) is enough to make each number map to a specific fix. Per-seat codes help scanning convenience more than they help analytics.
What is the single most useful number? The drop-off between “menu opened” and “actually browsed.” If guests scan and bounce, no amount of menu engineering behind that first screen matters until the page is fast and the first section earns the scroll.
The short version
QR code menu analytics are not about a big scan number to brag about. They are three practical readings (when guests scan, where they scan, and how far into the menu they get) that each point at a specific, cheap fix. Use a dynamic code so there is data at all, ignore the vanity totals, and treat the monthly scan review the way you treat a monthly inventory count: a quick look that quietly saves you from decisions made on gut alone.
