What QR scan analytics actually measure

"Scan analytics" sounds like it might know who scanned your code. It does not. What it knows is that a phone asked the redirect service where a short link goes, and roughly when and from what kind of device. This article walks through what that request contains, what it does not, how to read the resulting numbers without over-reading them, and how to describe the whole thing honestly to the people scanning.

What is counted: the redirect request

A static QR code cannot be counted, because the phone reads the address out of the pattern and goes straight to the destination; nobody in between ever hears about it. A dynamic code can be counted for one reason only: the pattern encodes a short link on the redirect service, so every scan begins with the phone asking that service for the real destination. That single web request is the unit of measurement. It arrives with a timestamp, with the browser's self-description (a string that says, in general terms, which kind of phone and browser is asking), and from a network address. The service records that a scan happened, forwards the phone, and moves on. Nothing about the scan is stored on the paper, in the pattern or on the phone; the count lives entirely on the server. Note what this implies: the count is of requests to the redirect, not of people who read the destination page. A scan that is forwarded and then abandoned still counts as one, and a person who opens the destination from a saved link, without scanning again, does not.

What is not known

The redirect request does not carry the person's name, email address, phone number or any account. The camera is not involved from the service's side at all — the phone's own camera app decoded the pattern before any request was made, and the service never sees an image. There is no access to the phone's contacts, location sensors or files; a web request cannot reach them. The network address can be resolved to a rough country or region, and it is rough: mobile networks route traffic through shared gateways, and a scan from one town can resolve to another. The device information is general — a phone versus a tablet or desktop, a browser family — not a serial number. Whether two scans came from the same phone is not knowable with any confidence, and this app does not try to fingerprint devices to guess. If your destination page runs its own analytics, that is a separate matter and governed by whatever that page does; the redirect itself sees only the request described above. This is a good thing to be able to say to customers, and it is worth being able to say it accurately.

How to read the numbers

SWAPQR's statistics panel shows the total scans for a code, the count for today and for this month, a day-by-day view of the last 30 days, and a breakdown by device type. Read them as trends, not as a census. Time of day and day of week are the most useful signal a code gives: a menu code that peaks at 12:30 and 19:30 is telling you something true, and a poster code that scans on the day of the event and never again is too. A jump after you moved a sign, changed its size or re-pointed the destination is real evidence about placement. Comparisons between codes are more reliable than absolute numbers — two identical codes in two windows, and one gets three times the scans, is a finding. Unique versus repeat scans is approximate at best, because the service does not identify devices; a burst of five scans in a minute is more likely one person retrying than five people, but that is an inference, not a fact. Small counts are noisy: three scans against one is not a pattern. Give a placement a few weeks before drawing conclusions from it.

Where the count can mislead

Some scans are not people. A staff member testing the sign counts. A phone that pre-fetches a link before showing it to the user may count. Someone who scans, is forwarded, and closes the page in a second counts exactly the same as someone who reads the whole menu. Conversely, someone who photographed the code and scanned the photo later at home counts once, in the wrong place and at the wrong time. Codes that are also shared as a link — pasted into a message, say — will pick up opens that never involved a camera, because the short link works either way. None of this makes the numbers useless; it makes them a floor and a shape rather than a precise figure. On the free tier, this app includes one dynamic code with a monthly scan allowance, and a paid plan removes the cap; if a code approaches the allowance, that is itself a rough signal that it is being used, and a reason to move it to a plan before it goes on hold.

Privacy: how to describe it honestly

You can say to the people scanning: the code opens a short link, the service counts that the link was opened and notes the time, the type of device and a rough region, and nothing about you personally is collected by the code itself. You cannot honestly say "no data is collected", because a request was made and counted; and you should not say more than the truth in the other direction either — the code does not know who you are, and that is the accurate claim. If your destination page collects anything, say so on that page. On the operator's side, this app does not ask for an email or a password; you get a licence code, and the statistics belong to the codes under that licence. Whether a scan count is personal data, and what notice is required, varies by country and by what your destination page does; this guide explains the mechanism so that you can make that judgement with the facts in hand, and it is not legal advice.