QR code analytics — what every scan can tell you

QR code analytics are the rows your redirect server writes every time a phone scans a tracked code. A row is small — a timestamp, an IP, a user-agent string, the slug, a UTM bundle if you tagged the link, sometimes a referrer. That's roughly nine fields, give or take, and the entire art of QR campaign measurement is reading those nine fields with enough context to tell a real campaign signal from preview-crawler noise, a Sunday spike from a billboard rotation, an iPhone-heavy audience from an Android-heavy one. This post takes each field individually and walks what it means, how accurate it is, and the specific mistakes that make a perfectly good dataset read like a Magic 8-Ball.

For the primer on how a tracked scan even reaches your server in the first place — the redirect-vs-static distinction, the four-step lifecycle — read the data primer on how to track QR code scans. This post starts where that one ends: you've got the rows, now what do they actually tell you, and what can they not tell you no matter how clever your dashboard is.

What QR code analytics actually contain — field by field#

A redirect-server row is a snapshot of one HTTP request. The fields below are what a serious QR analytics product captures by default. Nothing on this list is exotic — it's all stuff that any short-link platform writing logs already has — but plenty of dashboards surface three of them and silently swallow the rest.

Timestamp. Server-side wall clock at the moment the redirect handled the request, in UTC, to the millisecond. From this single field you derive day-of-week splits, hour-of-day curves, time-since-launch decay, and the gap between the print run going live and the first real scan landing. The thing the timestamp doesn't tell you is what time it was for the scanner — a 14:02 UTC scan could be morning coffee in San Francisco or evening commute in Frankfurt. Combine timestamp with the country to get local time before drawing any "best hour to publish" conclusions. The Saturday-morning peak on a French magazine campaign reads completely differently if you draw it on UTC time vs Paris time.

IP-derived rough geo. The IP arrives in the request envelope, gets passed through a geolocation database — MaxMind GeoIP2 is the canonical commercial one, the IP2Location and DB-IP free tiers are decent — and your platform stores the country, region, and city it returns. Accuracy is uneven and operator-dependent: country is right roughly 99% of the time, region around 80%, city is closer to 55-65%, and "city right" often means "the city the mobile carrier's regional egress point sits in" rather than the visitor's actual neighbourhood. For a mobile scan over a cellular network, treat the geo as metropolitan-area precision and stop. Drawing conclusions like "downtown vs midtown" off this field is over-reading the data.

Device class and OS from the user agent. The User-Agent header announces the browser, the OS, and (with a small set of hints) the device class. From it your dashboard derives: phone vs tablet vs desktop, iOS vs Android vs other, Safari vs Chrome vs the various in-app webviews. On iOS the model family is reliable in narrow ranges (iPhone vs iPad vs Mac) but the specific iPhone generation isn't usually distinguishable from the UA alone — Apple strips that on purpose. On Android the OS version is reliable; the exact device varies because every manufacturer customises the UA string. This is the field most operators under-read. A campaign that's 92% Android tells you something specific about the audience the magazine reaches, and that something is rarely "they want the same landing page as your iOS-heavy mailing list".

Slug as implicit campaign identifier. The path the redirect resolved — /p/spring-poster-NYC — is its own identifier even when the UTMs get stripped further down the funnel. Single-page apps occasionally eat query parameters on first paint, in-app browsers occasionally rewrite URLs, link-shorteners-of-shorteners (don't ask) occasionally remove everything after the ?. The slug stays. Generate a unique slug per surface and you've got attribution that survives every transport bug downstream.

UTM bundle when tagged. utm_source=poster, utm_medium=print, utm_campaign=spring-launch. These are the fields you write into the link yourself. Their value is purely descriptive — the poster carries a different utm_source than the magazine page, the redirect log carries both separately, the report sorts them apart. The UTM parameters that actually matter for short links post covers naming hygiene; the beginner version is in what is a UTM parameter. For QR analytics specifically the lesson is short: a QR without a UTM bundle is a campaign you can't slice. Print it tagged.

Referrer when present. Most QR scans from a printed code arrive with no Referer header at all — the phone's camera app isn't a browser, so there's nothing referring. Scans that originate from a screenshot reshared in a chat app sometimes carry the chat-app referrer; scans of a QR rendered on a web page sometimes carry the originating page. The signal is weak but occasionally tells a useful story: a spike of referrer-tagged scans usually means the QR got screenshot-shared into a Slack or a WhatsApp group, and you've been handed a free word-of-mouth amplifier you didn't budget for.

Accept-Language. The user's OS-set language preferences, like en-US,en;q=0.9,fr;q=0.8. Not perfect — plenty of people set their phone to English and read in their native language anyway — but combined with the country it's an honest signal for whether you should be serving the destination page in the local language. A row with country=DE and Accept-Language=tr-TR,tr;q=0.9 tells you the visitor is a Turkish-speaker in Germany. If your campaign assumes everyone in Germany reads German, you've just learned why your destination CVR is flat.

Click id. The UUID your redirect minted for this specific scan. It rides on the destination URL as ?lc_click=... (or whatever your platform uses), travels through to your backend as the visitor converts, and comes back via postback so the conversion gets joined to the scan. Without a click id, conversion tracking is open-loop. The conversion tracking with QR codes and short links piece walks the full chain.

Crawler / preview-bot flag. Every serious platform maintains a list of user-agent substrings (Twitterbot, Slackbot, LinkedInBot, facebookexternalhit, Discordbot, WhatsApp, TelegramBot, AhrefsBot) and flags those rows so dashboard totals can exclude them. This isn't a "captured" field in the strict sense — it's a derived flag — but it changes your reading of every other field. A 14:02:01 scan from Twitterbot/1.0 isn't a human; it's a link-preview fetch fired three seconds after your destination URL hit a tweet compose box. Counting it as engagement is the single most common analytics mistake on launch day.

A QR scan log is nine fields wide. Three tell you who, three tell you where, three tell you why — and the why fields are the only ones you wrote. Everything else came free in the request.

Country accuracy, by the numbers#

Country geo is the most reliable field on the row. Hardcoded "this scan came from Germany" claims hold up in court. The reason is that IP-to-country mapping is solved at the registry level — each IP address allocation is tied to a Regional Internet Registry (ARIN for North America, RIPE for Europe, etc.) with a known geographic block, so getting it wrong requires the carrier to be doing something genuinely weird.

City accuracy is the field that quietly disappoints. MaxMind's own published accuracy data puts country correctness at 99.8% globally and city correctness in the 50-60% range for mobile-IP traffic. The reason city is fuzzy is structural: mobile carriers route traffic through a small number of regional egress points (sometimes called Points of Presence or PoPs), so a phone scanning a QR in a suburb 30 km from a major city often shows up with the city's egress IP. Geographically that's "the carrier's gateway in the city centre", not "where the visitor actually is". Same mechanism in reverse: a visitor in central Paris on a budget carrier whose only French egress is in Lyon will geolocate to Lyon, not Paris.

Three practical reads on this.

First, country-level reads are honest. If your campaign shows 41% scans from Germany and 28% from France, those numbers will hold up in a board meeting. Second, city-level reads are directional only. "Toronto vs Vancouver" tells you something real; "downtown Toronto vs midtown Toronto" doesn't. Third, the closer the visitor is to the carrier's main egress, the more accurate the city looks — urban scans geolocate better than rural ones, by design, because the IP block boundaries cluster around population centres.

Reading the device-class field — the signal everyone leaves on the table#

The most useful single field after country is the device class. Roughly 95% of QR scans come from phones, with iOS and Android splitting the bulk of that share unevenly by market. The split tells you something specific about the audience that no demographic survey will, and it's free.

A few patterns we see often. Magazines in the US and UK skew slightly iOS-heavy; magazines in Germany and Brazil skew Android. Coffee-shop table tents trend whatever the surrounding neighbourhood trends. Outdoor billboards in business districts skew iOS; outdoor billboards in residential or transit zones skew Android. Conference QRs in tech-heavy industries skew strongly iOS; conference QRs in retail and logistics swing Android. None of these are universal laws, but every one is the kind of fact you can verify in a single afternoon of dashboard-staring on a real campaign.

What the split changes: it changes which landing-page experience you ship. iOS Safari renders some CSS differently than Android Chrome. iOS in-app browsers (Instagram, TikTok, Facebook) have their own quirks. If your destination page was tested on the operator's iPhone and the campaign is hitting an 87% Android audience, you've shipped a page nobody on this campaign has previewed. The device-class field tells you that fact within twenty minutes of the print run going live.

Tablet share is interesting in narrow contexts. Print magazines with QR codes catch a small but consistent stream of tablet scans — readers who took a photo of the page on their phone, then opened the photo on their iPad — and the tablet rows tend to convert at higher rates than the phone rows, probably because the larger screen makes the destination experience easier to read. Worth noticing if you spot a 6-8% tablet share on a campaign that "shouldn't" have tablet readers. It's almost always second-hand sharing, and second-hand sharing is reach you didn't pay for.

The desktop share is the canary. A printed QR shouldn't logically generate desktop traffic — phones scan QRs, desktops don't have cameras pointed at them. If your dashboard is showing 12% desktop, that's a tell: either someone pasted the destination URL into Slack and a preview crawler fetched it (filter for the crawler UA), or the QR ended up as a clickable image on a webpage you didn't expect, or someone's logging redirects from a browser-extension URL prefetch. Every desktop row on a print campaign is a small diagnostic prompt.

Reading time-of-day curves — and the trap of UTC#

The hour-of-day chart on a campaign feed is often the second view operators check after the country split. It's also the one most likely to mislead, because dashboards default to UTC and human attention runs in local time.

The pattern in raw UTC on a campaign with mixed European and North American audiences looks bimodal: a hump around 07:00-12:00 UTC (Europeans on lunch breaks and after-work) and a second hump around 14:00-22:00 UTC (Americans on lunch breaks and evening commute). If you read the chart without converting to local time, you'll conclude your audience "scans most around lunch and again at 6pm". If you convert to per-visitor local time, you'll see the same single curve everyone else's analytics shows — a flat morning, a real spike at lunch, a softer evening peak, almost nothing overnight. The chart looks completely different.

The fix is one line of conversion math: bucket each scan's timestamp into its country-derived local time before plotting. If your dashboard doesn't do that natively, you can do it manually by exporting the rows and recomputing. The cost is twenty minutes; the benefit is that your "best time to publish" answer is actually about your audience, not about the prime meridian.

A second time-of-day pattern worth knowing: scans of an outdoor billboard near a transit hub will spike sharply during commute hours and almost nothing else, with a tail through the evening. Scans of a coffee-shop table tent will run a steady stream through opening hours with a small lunch bump and basically nothing after close. Scans of a print magazine page will tail across days, with the highest density in the 36 hours after the issue lands at newsstands and a long flat tail for two weeks. Scans of a QR embedded in an email signature cluster in the minutes immediately after each outbound message lands — a hundred small spikes shaped by the sender's working day rather than one big curve. Each surface has a different shape, and the shape itself tells you whether the campaign is doing what you expected.

The bot-traffic asterisk on every metric#

Every analytics figure in this post needs the same caveat: filter out preview crawlers before you draw any conclusions. The mechanic is simple. When someone shares your destination URL in Slack, Twitter, LinkedIn, iMessage, WhatsApp, or any chat tool with rich previews, the platform's preview crawler fetches the URL to render a card. That fetch hits your redirect server and looks identical to a real scan to anything that's not filtering by user-agent.

The tells: the user agent contains the bot's name (Twitterbot/1.0, Slackbot 1.0, LinkedInBot/1.0, facebookexternalhit/1.1, Discordbot/2.0, WhatsApp/2.x), the request comes from a known datacentre IP range (AWS, GCP, the platform's published CIDR ranges), and the request fires within 0-2 seconds of the destination URL being posted into a chat tool. A single shared link can produce 5-15 preview-crawler hits in the first sixty seconds — every team member's Slack workspace fetching the preview, every Twitter follower's client fetching the card, every WhatsApp recipient's phone fetching the OG image.

If your dashboard counts those as engagement, the first sixty seconds of every shared link will look like a viral start. The same mechanism inflates QR campaigns the moment the destination URL gets passed around internally to discuss the launch. The bucket-them-separately filter is the same one the real-time link analytics — watching campaigns as they happen piece walks through; it's the foundational signal-vs-noise cleanup before any other QR analytics conclusion is allowed to be drawn.

What QR analytics can't tell you — and why operators keep trying#

Most of what people assume QR analytics capture isn't there. Expectations carry over from web analytics and app attribution, both of which see fundamentally different data.

The exact phone model. iOS is fuzzy by design — Apple's user agent gives you "iPhone" but rarely the generation. Android is fuzzier still because manufacturers customise the UA string in unpredictable ways. If you need the device model with precision, you need a destination-page JavaScript fingerprint that asks for navigator.userAgentData.getHighEntropyValues() and even that returns vendor-controlled data.

The scanning app. When iOS scans a QR through the Camera app, the network request comes from Safari (or the user's default browser). When iOS scans through a third-party scanner, same thing — the OS hands the URL off to the default browser before the network fires. From your server's perspective the two paths are identical. Android works the same. The only exception is in-app scanners that open the link in their own webview (Instagram, TikTok, Slack), where the in-app browser's user-agent is preserved and you can tell. For genuine camera scans of printed QRs, the originating app is invisible.

Exact GPS coordinates. Browsers don't send GPS data with HTTP requests. The only path to a real GPS fix is calling navigator.geolocation on the destination page after the visitor grants permission, and that data lives in your destination page's analytics, not in the scan log.

Whether the scan happened indoors, outdoors, in a store, on a billboard. That's not in the HTTP request. You know which surface produced the scan because you tagged it — utm_source=billboard is something you wrote, not something the camera communicated.

The visitor's identity. A scan event has no notion of "who" — only "this IP, this user agent, this timestamp". The link from anonymous scan to identified person happens on the destination side: the visitor signs in, fills a form, claims a tagged discount code. Until then, the scan is anonymous, and that's by design, not by oversight.

Whether the visitor hesitated, tried twice, or stared at the QR for a minute. The phone doesn't tell your server how the visitor behaved before the scan. The first time your server hears about a scan is the moment the redirect URL is fetched. Pre-scan everything is off-network.

The reason this list keeps catching operators by surprise is that web analytics layered on top of the destination page do see some of it. They see scroll depth, time on page, button clicks, sometimes a granted GPS fix. So operators looking at a scan dashboard subconsciously expect those same fields and feel cheated when they're missing. The honest framing: scan analytics measure the entry; web analytics measure the visit. They're two different layers, and the gap is structural, not a missing feature.

Interactive — read your own scan row#

Plug in a few realistic values from a scan you might see and the panel below explains what each field means, what you can act on, and where the false confidence usually creeps in.

The picker is built around the three columns that decide whether a row is worth counting at all — what device produced it, where it came from, and how well you tagged it. Pick combinations that match real rows in your dashboard and you'll see the same conclusions an analyst would reach in twenty minutes of cleanup.

How to read noise out of the signal#

Six patterns that show up repeatedly when operators try to read QR analytics straight off the dashboard.

Preview-crawler clusters at launch. A flurry of 8-15 scans in the first sixty seconds after you ship the link, all from datacentre IPs, all with bot user-agents, is the chat-tool preview crawlers fetching the destination. Filter by UA before you celebrate.

The "viral hour" that's actually one Slack workspace. A small spike of human scans in the first 5-10 minutes after launch concentrated in one country, one city, one referrer string — that's an internal team or beta group sharing the link in a chat. Real engagement, but not generalisable. Tag internal links differently from public ones so the launch noise doesn't contaminate the public-campaign curve.

The Saturday morning blip in a B2B campaign. A small but real cluster of scans at unusual hours from countries the campaign didn't target, often with regional rather than city-level geo. That's word-of-mouth — somebody screenshot the QR, sent it to a friend in another country, the friend scanned it the next morning. Don't filter it; track whether the trend grows. Earned reach is the cheapest reach there is.

The retroactive geo shift. A campaign that looks heavily concentrated in one city for the first few hours and broadens out over the next two days. This usually means the early scans were from a single transit hub (a station, an airport, a conference venue) and the broader spread is the audience taking the destination URL home and re-engaging from residential IPs. The early concentration isn't your real audience; the broader spread is.

The mobile/desktop ratio drift. A print campaign that starts at 99% phone and slowly drifts to 85% phone with desktop creeping in. Usually means a teammate or partner has put the destination URL on a webpage somewhere — Google indexed it, a few people clicked it, the dashboard now mixes phone scans with desktop clicks. Either separate the data sources or accept the contamination and stop reading desktop rows as "scans".

The clickthrough-rate vs conversion-rate split. Many campaigns have healthy scan counts and dead conversions. The scan log can't tell you why — it only sees the entry. Pair the scan dashboard with the destination's web analytics or your CRM. Half of all "we don't know what's wrong with our QR campaign" turns out to be a destination problem, not a QR problem.

A campaign log read without these filters is a campaign log read wrong. The same dataset read with the filters in place tells the operator's actual story — what surface, what audience, what time, what destination behaviour. Every metric in this post is more useful once the noise is buckets-aside, not blended in.

Privacy line, briefly#

Scan-side analytics in most jurisdictions count as first-party measurement of your own marketing surface, not user profiling. That's lawful basis under GDPR's legitimate-interest article and outside CCPA's "sale of personal data" definition. The one caveat: an IP address is personal data in the EU, so storing raw IPs indefinitely raises a storage-limitation question even when the basis is legitimate interest.

Three patterns that keep the privacy posture clean without changing what you can measure. Hash or truncate IPs before storage — keep the derived country/region/city, drop the raw octet after a short window. Set a retention window — 13 to 24 months is the conventional ceiling for analytics data under GDPR's storage-limitation principle. Disclose the measurement in your privacy policy — one line saying that scans of your QR codes are logged for campaign analytics covers most regimes. You don't need a cookie banner because the redirect itself sets no cookie. The line shifts the moment you tie a scan to a named person; the conversion tracking with QR codes and short links piece walks where that handoff lives. The traffic docs describe what the dashboard actually surfaces; the analytics docs cover the data-export shape. The events docs cover how custom conversion events ride alongside the scan data.

The five reads worth doing on every QR campaign#

Cut through the noise with five small queries. Run them once a week and you'll know more about your QR audience than 95% of operators ever do.

1. Scans per country, last 7 days, bot-filtered. Sort descending. Is the geography matching the print plan? Surprises here are usually distribution drift — the magazine reached a region you didn't model, or the poster ended up in a city you didn't print for.
2. Device-class split, last 7 days. What share is iOS, Android, tablet, desktop? Compare to your destination QA list. If you tested on iPhone and the campaign is 70% Android, the next print run starts with a destination-page review on a Pixel.
3. Hour-of-day curve in visitor-local time. What's the peak hour? If your social posts are firing three hours before the peak, you're under-served by your scheduling tool's default time zone.
4. Scan-to-conversion rate, per source. Out of every 100 scans from utm_source=poster, how many converted? Stack against utm_source=magazine. Different conversion rates from the same campaign tell you which surface earns the print spend.
5. First-scan-to-resharing-tail ratio. What share of scans land in the first 48 hours vs the remaining 28 days of the print run? A campaign that does 80% in 48 hours is front-loaded — fine for limited-time offers, bad for evergreen content. A campaign that tails for two weeks is doing the long-form work, which is exactly what print is for.

Five views, ten minutes each, weekly. The dashboard is doing the work; you're just asking it the right questions.

How this looks on Linked.Codes specifically#

The Linked.Codes analytics tab surfaces every field on the row above natively — country, region, city, device class, OS family, browser, referrer when present, UTM split, slug, click id, and the bot-flagged rows in a separate band you can toggle on if you want to see them. Time-of-day buckets are presented in your dashboard's time zone by default with an option to view in visitor-local time, because the UTC trap is genuinely the most common reading mistake. The analytics docs cover the date-range, filter, and top-tables UI; the traffic docs cover what each field means at the storage layer.

The conversion hook is one endpoint: when a scan resolves on the redirect, we mint a click id and pass it through to the destination as ?lc_click=.... Your landing page picks it up, your backend stores it with the order, and when the conversion completes, your code POSTs to the conversions endpoint with the click id and the value. The platform joins the conversion to the original scan, so every per-source report now shows revenue and conversion count, not just scan count. That's the loop closed; the conversion tracking with QR codes and short links piece covers the full chain.

The lifetime tier ships the live view, the geo enrichment, the bot filter, and the conversion endpoint at no extra cost. Gating these behind higher plans is the kind of thing that makes the feature feel like a checkbox instead of a tool — see the pricing page for the current figure. The free QR code generator builds a tracked dynamic QR in under a minute, which is the fastest way to verify the data lands in your dashboard the way this post describes.