QR Code Tracking: Which Tables Actually Scan
Every table has its own code, so every scan carries a table number and a date. That is the entire scope of the tracking: counts, per table, per day — enough to learn which table tents get noticed, and deliberately not enough to learn anything about the guest.
What the numbers can tell you
- Which tables scan, and how often. Table-by-table counts per day, so a table tent in the window can be compared with one in the back corner.
- When service moments happen. Deltas between days show whether a placement change moved the needle — new tent position on Monday, counts from Monday onward.
- Whether the codes work at all. A table whose count sits at zero for a week is either badly placed or its sheet fell behind something — both are physical fixes.
- An honest, unique-ish estimate. Repeated scans of the same code within a few seconds are collapsed, so a curious guest refreshing the page doesn't inflate their table.
What it cannot tell you — the honest list
- Not a headcount. Scans are phone reads, not diners. A table of four might scan once or four times.
- Not a person. No names, no phone numbers, no logins — guests are never asked to identify themselves.
- Not a profile. Menu pages run no analytics scripts and set no tracking cookies; there is no visitor history to build, on this site or anywhere else.
- Not precise location. The system knows Table 7, not where in the restaurant a phone physically was.
IP addresses that pass through the scanning endpoint are one-way hashed and never stored raw; the daily counts are all that remains. The full wording lives in the privacy policy.
Free plan vs paid: aggregate vs per-table
The free plan shows one number — total scans for the restaurant — because that is enough to confirm the codes are alive. The per-table breakdown, which is the whole point of table-level tracking, is part of the paid plan alongside the watermark removal and print-ready sheets. See pricing for what each tier includes; codes are unlimited on both.
Good uses and bad uses of the data
Good: compare two table-tent placements, verify a new table's code was installed, spot a week where nobody scanned the patio and investigate the patio — physical questions with physical answers.
Bad: treating the count as revenue or covers (it isn't), ranking individual guests (there are none in the data), or cross-referencing the numbers with security cameras to identify people — that would defeat the point of collecting so little.
If you have not seen the guest-side experience yet, the sample menu is what opens after a scan, and the table code sheets explain how each table gets its own code.
Where a daily number comes from
The chain is short on purpose. A phone opens a table's code; the redirect endpoint notes the table and the day, then hands over the menu page. Repeats of the same table within a short window are folded together so one curious guest can't double their table's count. What lands in the report is a row per table per day: how many scans, and when the last one happened. There is no session, no cookie, and no profile behind that row — if the report says Table 3 scanned eleven times yesterday, there is nothing further stored about any of the eleven.
Reading a week of data without over-reading it
A useful weekly look is three questions deep. Which table never scans? Zero for seven days usually means placement — move the tent into the line of sight, then watch the next week. Did a change move a number? If a tent moved from the bar rail to the center of a table on Wednesday, compare Wednesday–Sunday against the days before. Does traffic look like service? Counts that rise on weekends and sit quiet on Mondays match a restaurant's actual rhythm; a flat line every single day is the anomaly worth investigating. Anything beyond those three — per-guest behaviour, dwell time, conversion — is not in the data and cannot be reconstructed from it.