QR Code Analytics: What Your Scan Data Tells You

The short answer

QR code analytics is the data a dynamic QR code produces as people scan it. Because a dynamic code stores a short redirect link on a server you control rather than the destination itself, every scan passes through that server before it reaches the landing page — and the server records something about each request. The standard analytics stack is the scan count, an approximate count of unique scanners, a coarse location (country and city), the device and operating system, the time of day, and the repeat-scan rate. Read together, those numbers tell you whether the code is being seen, who by, where, on what, and when.

A static QR code produces zero analytics by construction. The data is baked into the printed pattern and the phone reads it straight off the image with no server in the loop, so there is literally nothing to record. The only signal a static URL code can give you is a normal page hit in the destination site’s own web analytics — and even that tells you the page loaded, not that a particular QR was scanned. The jump from zero analytics to a full dashboard is the whole reason a dynamic tier exists. Our qr code tracking guide introduces the concept; this page goes one level deeper into what the data actually is and what it tells you.

The full analytics stack

A mature dynamic-QR dashboard reports a consistent set of metrics because they all come from the same source: the HTTP request that hits the redirect server each time someone scans. The total scan count is the headline — how many times the printed code was activated, ever. The unique-scan count is an approximate number of distinct scanners, derived by hashing something stable about the request (IP plus user agent, or a cookie) rather than counting raw hits, so one person scanning five times does not inflate the figure to five. Location is reported as country and city, never a precise pin, because it comes from IP geolocation resolved on the server side.

Beyond the basics, the device and operating system come from the User-Agent header (iPhone versus Android, Safari versus Chrome, the model family). The time of day is the server timestamp of each request, which is what powers the scans-over-time trend line. The referrer, when the camera app sends one, tells you how the scanner arrived — though for a camera scan it is usually empty, which is normal. And the repeat-scan rate, the share of scans that come from scanners who have scanned before, is a derived metric that separates a one-shot campaign from a code people return to. Our qr code redirect guide explains the redirect mechanic that makes every one of these metrics possible.

How each metric is derived — the redirect server vs the static code

The cleanest way to understand QR analytics is to trace where each number comes from. When a dynamic code is scanned, the phone opens a short URL like r.yourdomain.com/abc; the browser issues an HTTP request to that URL; the redirect server reads the request, logs it, and replies with a 301 or 302 redirect to the real destination. Every metric in the dashboard is a function of that one logged request: the timestamp gives time of day, the source IP gives coarse location, the User-Agent string gives device and OS, and counting the requests gives the total scan count. Unique scans and repeat-scan rate are computed by grouping those requests with a hash or a cookie.

A static code never makes that request. The phone decodes the destination directly from the printed image and opens it, so there is no server in the path and no request to log — which is why the analytics are exactly zero. This is not a missing feature; it is the defining property of a static code, and it is the same property that makes static codes free, private, and immortal. The choice between static and dynamic is, in analytics terms, the choice between zero data and a full dashboard. Our static vs dynamic QR guide lays out the full trade-off, and the qr code tracking guide covers what the dynamic tier can and cannot measure.

The metrics, what each means, and what it is good for

The table below maps the standard QR analytics stack to the question each metric answers and the decision it informs. Treat it as a reading guide for a real dashboard: the numbers are only useful insofar as they change a decision you would otherwise guess at.

Repeat-scan rate — the metric that separates loyalty from one-shot

Repeat-scan rate deserves a moment because it changes how you read the other numbers. A restaurant menu printed on a table tent should have a high repeat-scan rate — the same local customers scan it every visit, and a low repeat rate there would mean something is wrong (the code broke, the menu moved, regulars left). A campaign poster for a one-week event should have a low repeat-scan rate — most people scan it once, act, and move on — and a high repeat rate there might mean the destination is confusing enough that people keep trying.

Read against total scans, repeat rate tells you the shape of engagement. A thousand scans with a 5% repeat rate is a wide one-shot audience; a thousand scans with a 40% repeat rate is a smaller, returning audience. Neither is better on its own — it depends on what the code is for. The number that closes the loop on outcomes is still conversion on the destination page, which you attribute by appending a campaign parameter to the destination URL so the destination’s own analytics can join the scan to the result. That loop-closing step is covered in our qr code tracking guide.

The privacy line — counts and coarse geo, not personal identity

QR analytics is server-side and aggregated, and a responsible dynamic tier keeps it that way. The dashboard shows a scan count, a coarse location (country and city), a device family, and a time — never a name, an email, a phone number, or a persistent profile across codes. Identifying an individual scanner would require them to log in or otherwise self-identify, which a plain dynamic code does not ask for.

That matters legally as well as ethically. The source IP address and the user agent are personal data under GDPR and similar regimes, so the redirect server should minimise what it keeps: store coarse geolocation instead of the full IP, hash the identifiers used for unique-scan counting rather than retaining the raw values, keep the data only as long as the campaign needs it, and never join scan logs to other datasets to re-identify a person. Surface a short note on the redirect interstitial that scans are counted, and keep the data you collect proportional to the question you are answering. The same guardrails apply to the qr code tracking stack this page builds on.

Reading a real dashboard

A usable QR analytics dashboard turns the raw request log into a handful of views you can act on. The top of the page is the total scan count and the scans-over-time trend line — the first tells you the code is alive, the second tells you whether it is growing, plateauing, or dying. Below that, a location breakdown (a coarse country/city table or a shaded map) shows where the scans concentrate, which is how you tell a poster that landed in one city from one that travelled. A device and OS split tells you the audience’s phones, which matters when the destination is an app-store link that should route iOS and Android differently.

A time-of-day histogram shows when scans happen — a lunch spike for a menu, an evening spike for an event poster — and that informs both the destination (a lunch menu vs a dinner menu) and the physical placement (a code scanned mostly at night belongs somewhere lit). A repeat-scan rate figure and a top-referrers list round it out. The discipline is to read the dashboard against a decision, not as a vanity number: every metric should answer “so what do I change?” — repoint the destination, move the code, resize it, or retire the campaign. Our qr code tracking guide covers what each view can and cannot tell you, and the qr code redirect guide covers the redirect that produces the data in the first place.

How QRForge delivers it

QRForge’s free generator produces static codes by default — and that means zero analytics by design, which is the right default for a one-shot print where the destination is permanent and there is nothing to measure beyond the destination’s own page hits. The planned paid dynamic tier replaces the static destination with a short redirect link on a server you control, so every scan is logged and the full stack above — total and unique scans, coarse location, device and OS, time of day, repeat-scan rate, and the scans-over-time trend — is surfaced in a dashboard you can edit and repoint without reprinting.

Because every scan passes through that one redirect, the analytics, the editable destination, and the redirect mechanics are the same feature viewed from three angles: the server logs each request (analytics), the mapping from short link to destination lives on that server (editable redirect), and the static-vs-dynamic choice is whether you opt into the server at all. Start with a static code to prove the placement and the scan distance, then step up to the dynamic tier when tracking, repointing, or A/B routing is the lever that moves the result. Our static vs dynamic QR guide, qr code redirect guide, and qr code tracking guide cover each angle in depth.