What QR scan analytics actually tell you — and what they don't

Most QR analytics dashboards over-promise. They show scan counts, devices, geography, and time-of-day, then leave you to draw conclusions. The dashboards aren’t lying — they’re just measuring less than you think.

Here’s a working guide to what scan analytics actually tell you, what they fundamentally can’t, and how to instrument the conversion path so the numbers stop being decorative.

What scan analytics genuinely do tell you

Five things, all of them load-bearing for campaign decisions:

Geographic distribution

You see where the scan happened, accurate to roughly city level. This is the single most underused data point because most teams report on it once and never use it again. The pattern that matters: unexpected geographic clusters. A QR code on a New York subway poster getting scans in Chicago means somebody photographed your poster and shared it — that’s a virality signal worth chasing, not a noise spike to filter out.

Device and OS

iOS vs. Android, native camera vs. third-party scanner. Useful when:

• You’re routing to an app and need to know which app store to deep-link to
• You’re debugging “the QR code doesn’t scan” — different scanners have different tolerance for QR error correction
• You’re segmenting downstream conversion analytics by platform

Time-of-day patterns

The most useful flavour of this is day-part — does the QR get scanned during commute hours (it’s working as out-of-home advertising), during lunch (it’s working as point-of-sale), or evenings (it’s working as packaging-at-home)? This tells you whether your channel hypothesis matches reality.

Returning vs. new scanners

Same device coming back to scan the same QR multiple times is a strong engagement signal — usually because the user shared it with someone in person who scanned it, or because the destination didn’t deliver and they tried again. Both are interesting.

Per-link campaign attribution

If you generated separate QR codes for which placement (poster A vs. poster B, NYC vs. LA, end-cap vs. shelf), per-link scan data turns the campaign into a real experiment.

What scan analytics fundamentally can’t tell you

Three honest gaps — be aware of these before you over-claim in a deck:

1. The scanned-but-didn’t-convert gap

A scan is the moment the camera reads the QR. The conversion is whatever happens 3–10 seconds later on the destination page. They’re decoupled.

A scan with no follow-on landing page view means one of:

• The user scanned to test the QR but never tapped through (especially common in iOS, where the URL preview shows above the camera and users decide then whether to tap)
• The destination is slow to load
• The destination errored
• The user got distracted

You can’t tell which from scan data alone. You can tell from scan-to-landing-page-view ratio, which we instrument in Qurly automatically — but it requires that the destination is also under measurement.

2. Scanner identity is not user identity

Scan analytics see device fingerprints, not authenticated users. So:

• One person scanning from their phone, then their iPad, then their friend’s phone reads as 3 unique scans
• Three people sharing one phone reads as 1 unique scan
• Resetting an advertising ID resets the unique-scanner count

For aggregate trend tracking this is fine. For “did this specific customer scan our QR?” — scan analytics is the wrong tool. That’s what authenticated post-scan flows are for.

3. Privacy filters distort iOS data

iOS Camera and Apple’s privacy framework strip a lot of telemetry that Android scanners don’t. Practical implications:

• iOS scanners often appear without referrer information
• Browser-fingerprint-based deduplication is less accurate on iOS
• Some QR scanning apps proxy through a redirect that changes the User-Agent string

Don’t trust device-share charts to one decimal place. Treat them as approximate.

How to close the gap with conversion-side measurement

The fix is straightforward: pair every QR with a measurable destination. Three patterns, in order of value:

Pattern 1: UTM-tagged landing page

Every QR’s destination URL gets a unique utm_source=qr&utm_campaign=...&utm_content=.... The QR analytics tell you scans; your web analytics (or in-Qurly landing page analytics if you’re using ours) tell you conversions. Joining the two by utm_content gives you scan-to-conversion rate per placement.

Pattern 2: A custom landing page on Qurly

If you don’t have a fast destination of your own, host a Qurly landing page. Every block click on it is tracked, so you don’t lose the conversion event in the gap between “scanned” and “did anything.” The block editor takes about 10 minutes; per-element click data is on by default.

Pattern 3: App deep links with attribution

For app installs, route the QR through a deep-link service (Branch, AppsFlyer, Adjust) so the install event ties back to the QR. Pure scan counts won’t tell you about installs; deep-link attribution will.

The 60-second campaign instrumentation checklist

Before you ship a QR campaign:

1. Each placement gets its own QR code. Same destination is fine; the QR codes themselves should differ so you can tell them apart in analytics.
2. Each QR’s destination has a unique UTM utm_content. Even if the destination is the same page.
3. The destination is itself instrumented. GA, in-app analytics, or Qurly landing page analytics — pick one, but pick one.
4. You define what “conversion” means before launch. Email signup? Add to cart? Scroll past 50%? Whatever it is, write it down.
5. You set a review date. A QR campaign with no scheduled “what did we learn” is a campaign that becomes folklore.

A useful mental reframe

Scan analytics are a leading indicator of attention. Conversion analytics are a lagging indicator of value. Don’t confuse the two, and don’t report only on the first. The CMO doesn’t care how many scans you got; they care whether the campaign worked. Make sure you have the data to answer that.