Why Your QR Scan Count Isn't the Number of People

In short: total scans counts how many times your code's link was opened, and unique scans counts how many different internet connections opened it. Neither one counts people. In our test, five people sharing one café Wi-Fi showed up as one unique scan, one person switching to mobile data showed up as two, and a single short link pasted into eight chat apps logged nine clicks from one actual human. The numbers are still useful. You just have to read them as trends, not headcounts.

When a phone opens a dynamic QR code, it doesn't go straight to your page. It asks our redirect where to go first, and that request is what gets counted. One request, one scan. The redirect never sees a face, a name or a phone number. It sees an IP address, the browser's user agent string ("iPhone, Safari") and the time.

So total scans in your ZetaQR analytics is the number of requests. Unique scans is the number of different IP addresses those requests came from in the period you're looking at. That's a reasonable stand-in for people most of the time. But an IP address belongs to a connection, not a person, and connections get shared and swapped all day.

It also means anything that opens the link counts, whether it's a person or not. We'll get to that.

We wanted real numbers rather than guesses, so we tested our own product. On a local copy of ZetaQR running the same redirect and analytics code as production, we made four test QR codes and one short link, all pointing at a page on example.com. Then we sent 20 requests to them, each with the user agent string a real phone or app sends, and each from an IP address in the ranges reserved for documentation, so no real network was involved.

Five situations, each one something that happens to printed codes every week. A customer scans the same table tent three times. Someone scans on the shop's Wi-Fi, walks out, and scans again on mobile data. Five friends at one café table scan on the same Wi-Fi. A link checker opens the link without a person anywhere near it. And someone pastes a short link into eight different chat apps, which each fetch it to build a preview, before one person taps it.

Once the analytics had been written, we read the rows back and counted them the same way the dashboard does. One limit to keep in mind: this shows how our counter treats each kind of request. It doesn't show how often real apps fetch links, which depends on the app and on caching.

The same person, more than once

Three scans from one phone on one connection came out as three scans and one unique. That's the counter doing its job. Total scans is meant to count every open, and people do rescan: the page didn't load, they want the menu again after ordering, they're showing a friend.

Switching networks is different. Our Android test phone scanned once on Wi-Fi and once on mobile data, and the report showed two unique scans. To the counter, those really are two different connections. Think of a shopper who scans in the store, then again from the car park to finish reading.

Things that aren't people

A link checker sent a single HEAD request, the kind tools use to see if a link still works without downloading the page. It was counted as a scan, from a "desktop" device with an operating system of "Other". Nobody was there.

This one matters most for short links and for any QR link that ends up pasted into a chat. When you paste a link into WhatsApp, Slack, LinkedIn or iMessage, the app usually opens it to build the little preview card with a title and picture. Slack documents its own fetcher, Slackbot-LinkExpanding, and says it fetches links that users post into channels.

We sent one fetch each with the user agents of WhatsApp, Facebook, Slack, X, Telegram, LinkedIn, Discord and iMessage previews, then one tap from a real iPhone. The report showed nine clicks and nine unique clicks. The real number of people was one.

Most of the preview fetches were easy to spot afterwards, because they showed up as "desktop" with an operating system of "Other". The iMessage one wasn't. Its user agent looks like Safari on a Mac, so it was recorded exactly like a person on a laptop. There's no way to tell it apart from the report.

Real life is a bit gentler than our test. Slack, for one, says it caches previews for about 30 minutes, so pasting the same link twice in a channel shouldn't mean two fetches. But a link shared around a few group chats can easily rack up preview "clicks" before anyone taps it.

Five different phones, an iPhone, a Pixel, a Galaxy, another iPhone and a Redmi, scanned on one café Wi-Fi. The report showed five scans but only one unique scan, because every phone left through the same router with the same public IP address.

That's normal for any shared connection: a restaurant, an office, a hotel, a school, a conference hall. Mobile networks do something similar at a much bigger scale. Many carriers use carrier-grade NAT, which the Internet Engineering Task Force describes in RFC 6888 as a way to share the same IPv4 address among several subscribers. So two strangers on the same carrier can look like one visitor.

Put the two together and the unique count can run high and low at the same time, in the same report. It isn't a precise headcount, and it can't be one. It's a rough middle ground between "every open" and "every person".

We're writing about our own counter, so here it is plainly. ZetaQR doesn't currently filter out link previews, link checkers or other bots. Every request that reaches the redirect is counted, and unique scans are based on IP address alone. Everything in the test above happens in real accounts.

Some tools do try to remove bot traffic, usually by matching known user agents. That catches the obvious ones, like most of the preview fetchers in our test, but not something like the iMessage preview that looks like an ordinary browser. No filter makes a scan count into a people count.

None of this makes scan counts useless. The errors are much the same from week to week and from one code to another, so comparisons hold up better than raw totals. A few habits help:

• Compare codes and weeks, not absolute numbers.
• Give anything you share online its own short link, so chat previews don't land in your print code's count.
• Check the device breakdown. For a printed code, a lot of "desktop" or "Other" usually means something other than phones opened the link.
• Expect the unique count to run low where people share Wi-Fi, like restaurants, offices and events.
• If you need a real headcount, count something only a person does, like a form sent from a landing page.

And when the scans don't match Google Analytics, that's a different gap with its own reasons, which we covered in our guide to UTM tags for QR codes.

Choose the count you'll report, give shared links their own short link, and compare this week with last week. If you want to see where your scans really come from, open one code's report and look at the device breakdown first. It's the quickest way to spot opens that weren't people.