Advanced Topics
QR Code Analytics & Tracking Explained
Scan analytics are the first measurement most printed material has ever had, which makes them genuinely valuable and easy to over-read. The data is real but coarse: it describes requests, not people. Knowing precisely which questions it answers — and which four it structurally cannot — is what separates useful reporting from confident nonsense.
The short version
- Only dynamic codes produce analytics. A static code has no hop to count.
- You get: counts over time, device/OS/browser, coarse location, sometimes a unique-ish count.
- You don't get: identity, what happened next, repeat visits, or why.
- The design decision that matters is your code scheme — one code per placement, not one per campaign.
- Bots inflate counts on anything shared digitally.
- Relative comparisons are trustworthy; absolute numbers are soft.
Where the data comes from
Every scan statistic in existence comes from one place: the HTTP request a dynamic code's redirect receives. There is no other source. The phone doesn't report anything, the printed code has no state, and a static code produces nothing at all.
Which means scan analytics are exactly as rich as a web server log, and no richer. That framing prevents most of the over-reading.
What each field is actually worth
| Field | Reliability | What it's good for |
|---|---|---|
| Scan count | High | Comparing placements and periods. The most useful number you get. |
| Timestamp | High | Time-of-day and day-of-week patterns; confirming a campaign started. |
| Device type | High | Sanity-checking that your landing page is mobile-first. |
| OS / browser | High | Debugging a "some people can't open it" report. |
| Country | Good | Confirming distribution reached where you expected. |
| City / region | Soft | Directional only — mobile networks routinely geolocate badly. |
| "Unique" scans | Soft | Depends entirely on how the provider defines it. Ask. |
City-level location from mobile IPs is frequently wrong — carrier NAT can place a scanner a hundred miles away, and traffic through a VPN or a privacy relay is meaningless. Use country-level data confidently and city-level data as a hint, never as evidence.
"Unique scans" is not a standard measure. Some providers count distinct IPs indefinitely, some hash per day, some per session. Those produce very different numbers from the same traffic. A privacy-preserving scheme — a daily-rotating hash, for instance — gives you honest within-day uniqueness and deliberately cannot recognise the same person tomorrow, which is the correct trade but means the number isn't "unique people."
The four questions it cannot answer
These are structural, not limitations of a particular provider:
- Who scanned. There's no identity in an HTTP request. Scan data is anonymous by construction, and any provider suggesting otherwise is either combining it with something else or overselling.
- What happened next. The redirect's involvement ends the moment it responds. Whether someone bought, bounced or read for ten minutes is your website's analytics problem — see connecting scans to Google Analytics.
- Whether the same person returned. Only with cross-day identifiers, which is exactly the tracking most privacy-conscious implementations deliberately prevent.
- Why. No analytics answers this, but it's worth saying because scan data invites the assumption. A drop in scans might be worse placement, worse weather, a damaged sign or a competitor's promotion. The data tells you that, never why.
The decision that actually determines value
Not which provider — how you carve up your codes. This is decided before printing and cannot be changed afterwards.
One code across an entire campaign gives you a single number: total scans. Interesting once. A code per placement gives you a comparison, which is the thing you can act on.
| Scheme | Tells you |
|---|---|
| One code, whole campaign | Whether anyone scanned at all |
| One per placement type | Whether posters beat table tents |
| One per location | Which venue, street or store performs |
| One per print run | Whether the reprint was worth it |
| One per recipient | Individual response — and a much heavier privacy obligation |
The sweet spot for most people is one code per placement type per campaign — enough to compare, few enough to manage by hand. Past a few dozen, generating and tracking them needs an API.
A unique code per person in a mailing converts aggregate measurement into individual behaviour tracking. That's a materially different processing activity with heavier obligations, and it should be a deliberate decision with a lawful basis — not a side effect of wanting better numbers. See privacy and GDPR.
Reading the numbers without fooling yourself
- Trust relative, distrust absolute. "The window code got three times the table tent" is solid. "We reached 1,412 people" is not — that number includes bots, duplicate scans and people who cancelled at the preview.
- Expect a launch spike and a long tail. Most scans arrive in the first days. Judging a placement on week one over-weights novelty.
- Bots are real. Link-preview fetchers, security scanners and crawlers all hit redirects. A code shared in a group chat can accumulate scans nobody made.
- Zero scans is information. Usually placement or missing call-to-action rather than a broken code — but scan it yourself first to rule out the boring explanation.
- Compare like with like. Foot traffic, weather and day of week move these numbers more than most design changes do.
- Watch the scan-to-outcome gap. High scans with no conversions is the most actionable pattern there is: the code works and the landing page doesn't.
Frequently asked questions
Can you track who scanned a QR code?
No. Scan data comes from an HTTP request, which contains no identity — you get timing, device type and approximate location, and nothing that names a person. Tracking an individual would require combining scan data with something identifying, such as issuing a unique code per named recipient, which is a deliberate choice with much heavier privacy obligations rather than a default capability.
Can static QR codes be tracked?
Not by themselves — there's no server involved, so there's nothing to count. The only workaround is encoding a URL with tracking parameters and reading your website analytics, but that measures page visits rather than scans and can't distinguish a scan from a typed URL. If you need scan measurement, you need a dynamic code, and that decision has to be made before printing.
How accurate is QR code location data?
Country level is reliable. City level is soft and often wrong — mobile carrier NAT can place a scanner in a different region entirely, and VPNs or privacy relays make it meaningless. Treat country data as evidence and city data as a hint. If you need to know where scanning happened, use a separate code per physical location rather than inferring it from IP geolocation.
What does "unique scans" actually mean?
It depends entirely on the provider, and it's worth asking. Some count distinct IPs indefinitely, which is genuinely person-level tracking. Some hash the IP with a daily-rotating salt, which gives honest within-day uniqueness and deliberately cannot recognise the same visitor tomorrow. Those produce very different numbers from identical traffic, so the metric isn't comparable across providers.
My QR code shows scans but I got no customers. What went wrong?
That's the most actionable pattern in scan analytics: the code works, and the landing page doesn't. People scanned, arrived, and left. Check what the code opens on an actual phone — the usual causes are a homepage instead of the promised content, a slow or desktop-oriented page, or an unexpected form standing between the visitor and what they wanted. It's rarely a QR problem at that point.