QR code tracking without personal data

What a scan actually is

When a phone scans a dynamic code it asks a short web address where to go, gets the answer, and goes there. The server answering that request can see three things: the time it arrived, the network address it came from, and a line of text describing the device, which is how a count knows an iPhone from an Android tablet.

That is the entire haul. There is no name attached, no phone number, no register of who owns which handset. A scan is an event, not a person. The same customer scanning your menu at lunch and again at dinner is two scans, indistinguishable from two customers, and no redirect-side count can tell you otherwise. Any dashboard offering you “unique visitors” from scans alone is keeping something that recognises a device across visits, and it is fair to ask what.

What the numbers are genuinely good for

• Which code. Put a different code on the flyer, the poster and the table tent, and the counts tell you which placement earned its printing. This is the single most useful thing scan data does, and it needs nothing about the scanner at all.
• Roughly where. The network address, at the moment of the request, resolves to a country and usually a city. Enough to see the Manchester leaflet drop outperforming the Leeds one. Nowhere near an address, and not meant to be.
• When. A takeaway menu that gets scanned at half past five, a church noticeboard that gets scanned on Sunday mornings. Timing tells you when the printed thing is actually being read, which is not always when you assumed.
• What kind of device. Phone or tablet, iOS or Android. Mostly useful as a prompt to check your landing page on whatever your readers actually carry.

What the numbers cannot do: identify anybody, count repeat visitors, tell you whether a scan became a sale, or measure the people who read the poster and never scanned. A scan count is a measure of scans. Treat it as anything more and it will flatter or frighten you for no reason.

UTM parameters or counting at the redirect

There are two places a scan can be measured, and they are often confused because both end up as a chart.

UTM parameters are labels added to the end of the destination address, in the style of ?utm_source=poster. The analytics running on your own website reads them on arrival. They work with any code, including a static one, and they can follow the visitor into whatever your site measures next. The costs: they need analytics running on the destination page, which usually means scripts and often a consent banner, and in a static code the labels are welded into the printed pattern for ever, so a renamed campaign or a changed analytics account leaves stale tags on every leaflet.

Redirect-side counting happens at the short link, in the moment before the phone is forwarded on. Nothing is added to your page, nothing runs in the visitor’s browser on your behalf, and the count survives any change of destination because it never depended on the destination. The limit is the mirror image: it counts scans and stops there. It cannot see what happened after the forward.

The two measure opposite ends of the same journey, and using both is legitimate. For most small print jobs the redirect-side count answers the question actually being asked, which is whether anyone is scanning the thing you paid to print.

The UK rules in plain English

Two pieces of law matter here, and the outline of both fits in a paragraph. The detail does not, so treat this as orientation rather than advice, and take your own advice for your own situation.

UK GDPR governs personal data, meaning information about an identifiable living person. The ICO’s guidance is clear that online identifiers, including IP addresses, can be personal data (ICO, what is personal data). So a provider storing the raw addresses of everyone who scans your poster is broadly holding personal data on your account, with the duties that follow: saying so in a privacy notice, having a lawful basis, answering requests about it. None of that is scandalous. It is homework, and it is homework a small business acquires without noticing, through a checkbox on somebody else’s dashboard.

PECR sits alongside and covers, among other things, storing information on a person’s device or reading information from it, which is why cookie banners exist (ICO, guide to PECR). A redirect-side scan count places nothing on the phone and reads nothing from it, so the consent-banner side of PECR is broadly not engaged by the count itself. Script analytics on your landing page is a separate question that depends entirely on what those scripts store and read.

One more distinction worth having: data that has been anonymised so that nobody can be identified from it is broadly no longer personal data. The catch is in the word “anonymised”, which the rules treat strictly. A scrambled value that can be unscrambled, or matched back to a person with a bit of effort, does not qualify.

How we count a scan

The raw IP address of somebody scanning is never stored. In the moment the request arrives it is salted, hashed and truncated, and the salt rotates daily. In plainer words: a random value is mixed in, the result is put through a one-way scramble, part of the scramble is thrown away, and the random value changes every day. There is no column in the database that could hold the original, because the original is gone before anything is written.

The daily rotation is the part that matters most and gets explained least. With a fixed salt, the same phone would produce the same scrambled value every day, and a patient observer could watch one value recur for months. Rotating the salt means today’s values cannot be matched to yesterday’s, so nothing accumulates about any device over time. It is also why we will never show you a unique-visitor count: telling people apart is precisely the capability we chose not to keep.

For a small business the practical meaning is blunt. A copy of our scan table would contain counts, times, coarse locations and device types, and no route back to any person. That is a much smaller thing to be responsible for than a log of raw addresses. It does not make your operation compliant, because no supplier can make that promise honestly: your landing page, your mailing list and everything else you run are still yours to get right. What it does is shrink the pile.

Getting something useful out of it

The setup that pays for itself is one code per placement. The flyers and posters guide works through the print-run arithmetic, and the print guide covers getting each of those codes onto paper at a size that scans. If a code you are watching has flatlined, check the mundane cause before the interesting one: a code that stopped resolving shows the same zero as a poster nobody reads, and that has a page of its own.