Scan Tracking and Privacy: Consent, IPs, and Retention

A restaurant owner opens her scan dashboard on a Monday and sees a table: 412 scans, a list of cities, a column of device types, timestamps down to the second. Her first reaction is that this is useful. Her second, roughly four seconds later, is a question she has no way to answer on her own. Is any of this personal data, and did anyone agree to it?

Worth stating plainly before anything else: this is general information for people setting up scan tracking, and it is not legal advice. Privacy obligations differ by country, by state or province, by industry, and by what you actually do with the data. Nothing described here applies everywhere. Confirm your own position with your own counsel or privacy officer before relying on any of it.

What the redirect server sees before the visitor does anything

A dynamic code encodes a short redirect URL. The phone requests that URL, a server answers with a redirect, and the browser follows it to the real destination. Our explainer on what happens when you scan a code walks the whole sequence, and the choice between a 301 and a 302 decides whether the phone even asks the server again next time.

The privacy-relevant part is that this is an ordinary HTTP request. To answer it at all, the server necessarily receives the client IP address, a user agent string, often a referrer, and the exact time. Coarse location is typically derived from the IP rather than collected from the device. None of that requires a tracking script, a cookie, or any permission dialog. It is simply what a web request contains.

A static code encodes the destination directly and involves no intermediate server, so no scan record exists on anyone's system. That is a genuine privacy property, and it is also why static codes have no analytics. You cannot have both at once.

Counts and rows are different objects

"4,102 scans last week, mostly Tuesday, mostly iOS" is a summary. Nothing in it points at a person.

A row-level log is something else. One line per scan, each carrying an IP address, a timestamp to the second, and a device string, is data about individual events. Some regimes, the GDPR in Europe among them, treat an IP address as personal data in a wide range of circumstances; others frame it more narrowly, and several draw the line differently again when the address is combined with other fields. Which framing binds you depends on where you operate and where your visitors are.

The practical question is simpler than the legal one. Do you need the rows at all? Most people making decisions about signage, placement, or campaign timing need counts, trends, and rough geography. If row-level logging exists because it came switched on rather than because someone asked for it, that is exposure you are carrying for free.

The banner cannot cover the scan

This one trips up careful teams. A consent banner lives on your landing page and runs in the browser after the page loads. The scan, the request to the redirect server, and the server-side log entry all happen before that page exists. By the time anyone sees a banner, the request that produced the log line has already finished.

So a landing-page banner governs what happens next, not the hit itself:

• Cookies and client-side analytics on the destination page are exactly what a consent mechanism can control. Where local rules require a choice before non-essential storage, that means not setting those cookies until the visitor makes one.
• The server-side scan record has to be handled by other means: keeping less of it, documenting a basis for processing where one is required, and disclosing the practice in your privacy notice.
• Physical signage is the only place you can tell someone before they scan. One short line near the code, pointing at a privacy notice, costs nothing to print.

All of this concerns your own tracker on your own codes. Codes placed by someone else with bad intent are a separate topic, covered in our material on spotting fake codes.

Truncation, and why it lowers risk

Storing a full IP address gives you something close to a household-level identifier. Storing a truncated one keeps most of the analytical value and sheds much of that.

Truncation means dropping the final octet of an IPv4 address, or the trailing portion of an IPv6 address, before the value is ever written down. What survives is enough for country and usually region-level geography. What disappears is the part that makes two visits weeks apart easy to link back to one connection.

Two honest caveats. Truncation reduces risk; it does not automatically render data anonymous in every regulator's eyes, especially if you keep other identifying fields in the same row. And it has to happen at write time. Truncating a column that has held full addresses for eight months does nothing about the eight months.

Retention is a decision, and "forever" is the one nobody made

Most scan logs grow without limit because no limit was ever set. Choose windows deliberately, and choose them separately:

• Raw event rows carrying IP and user agent: the shortest window that still supports work you actually do.
• Aggregates with no individual-level fields: these can live far longer, because they describe traffic rather than people.
• Deletion, not archiving. A cold backup of the raw table is still the raw table.

Then automate it. A retention policy that depends on someone remembering to run a query is not a policy. If your vendor exposes retention settings, set them. If it does not, ask what the default is, because you are answerable for it either way.

The vendor is holding your data, not its own

If you decide which codes exist, why scans are tracked, and what happens to the numbers afterward, you are the one making the decisions about that data. A QR platform processing scans for you is acting on your instructions. Many privacy regimes attach different duties to those two roles and generally expect the arrangement to be written down.

Questions worth asking before you standardize on a platform:

• Is there a data processing agreement, and can you read it without booking a sales call?
• Which countries do scan records get stored and processed in?
• Who are the sub-processors, and how are you told when the list changes?
• What is the default retention window, and can you shorten it?
• Can you export everything, and does deletion mean deletion, backups included, on a stated timeline?

Asking those questions takes no legal training. Interpreting the answers against your own obligations does.

Pull up your scan log this week and look at a single row. Write down every field it contains, mark the ones you have used in an actual decision in the past ninety days, and switch off the rest. Then hand that field list and your vendor's processing agreement to whoever advises you on privacy, and let them tell you what your situation requires.