QRStudio Builder

How to track QR code scans (and what the numbers actually mean)

What a QR code can and cannot tell you about the people scanning it, how to structure codes so the data is worth reading, and why your scan count is lower than your raw hit count.

· 6 min read

A QR code is not measurable by itself. The pattern is just text, and a phone reading text does not report back to anyone. Everything you can learn about scans comes from putting a link you control in the middle — which is exactly what a dynamic QR code does.

What you can know

  • How many times the code was scanned, and when — the trend over days and weeks is usually more useful than the total.
  • Roughly where from: country, region, and often city, derived from the network the request arrived on.
  • Which of your codes performed best, if you gave each placement its own code.
  • Which destination won, if you split scans between two landing pages.

What you cannot know

Not who scanned it. A scan is an anonymous web request; there is no identity attached unless the person later signs in or fills something out on your page. You cannot get a name, a phone number, or an email from a scan, and any service claiming otherwise is either inferring it from something else or overselling.

Location is also coarser than it looks. It comes from network routing, so a mobile scan can resolve to the city where the carrier's gateway sits rather than the street the person is standing on. Treat city-level data as a strong hint, not a fact, and be sceptical of any tool that shows you a precise pin.

Why your scan count looks low

A well-behaved analytics pipeline throws requests away, and it should. When someone pastes your tracking link into a chat app, that app fetches it to build a preview — sometimes several times. Uptime monitors, search crawlers, and security scanners all hit it too. None of those are people holding a phone.

Filtering those out means your reported number is lower than the raw hit count and much closer to the truth. Rapid repeat requests from one source are also usually collapsed, so a person who scans twice while waiting is not counted as two customers. If a provider's numbers look suspiciously high, ask what they filter.

Structure your codes so the data says something

One code across every surface gives you one number, and one number answers no questions. The fix is boring and effective: a separate code per placement, named for where it went.

  1. Create one code per physical placement — per poster site, per print run, per packaging SKU.
  2. Name each one for the place, not the campaign: "Bar window, Oct print" beats "Autumn 3".
  3. Tag them by channel so you can group print against packaging against events later.
  4. Add UTM parameters to the destination as well, so the visit shows up correctly in your web analytics too.
  5. Compare scans per placement after a fortnight and put the next print budget where the scans are.

Connect scans to what happened next

Scan counts tell you the code worked. They say nothing about whether the visit was worth anything. Because the destination is a normal URL, add campaign parameters and let your existing web analytics take over from there — that is how you find out that the code with half the scans drove twice the orders.

Privacy is not optional

Scan data is behavioural data about people, even when it is not identifiable. Keep raw IP addresses out of storage, tell visitors what you collect in your privacy policy, and only retain what you will actually look at. Reasonable providers hash or discard IPs by default; if yours stores them in the clear and shows them to you, that is a liability you have taken on, not a feature.

Keep reading