QR code analytics without cookies: what a scan really reveals

A scan is a web request, and a web request talks

A static QR code contains the destination itself, so scanning it involves no server in between. A dynamic code contains a short URL, such as qreu.eu/x7k2, and the phone requests that URL from a redirect server, which answers with the real destination. QR code analytics live entirely in that one request. Nothing is added by the code, the paper or the camera; everything comes from what a phone sends when it asks a server for a page.

Take a flyer for a bakery in Ghent. A customer points the camera at the code, taps the notification, and for about a hundred milliseconds her phone and the redirect server exchange a handful of headers. Then she lands on the bakery's ordering page and the redirect server is out of the picture. What was in those headers decides what the bakery can learn.

What a scan sends to the redirect server

An HTTP request for a short URL carries roughly five things a redirect server can use. The IP address of the phone, or of the network it is on, arrives with the connection itself. The User-Agent header names the browser, the operating system and often the device family. The Accept-Language header lists the languages the phone is set to. The server notes the time it received the request. A Referer header is usually absent for a QR scan, because the camera app opens the URL directly rather than from a web page, which is itself a small signal that the visit came from a scan.

That is the entire raw material. There is no name, no email address, no phone number and no location beyond what the IP address implies. A dashboard that claims to know more than this either asked the visitor for it, set a cookie, or loaded a third-party script on the landing page. Those are choices, not properties of the QR code.

What that becomes in a dashboard

Each header maps to a familiar chart. The IP address is looked up in a geolocation database and becomes a country, sometimes a region or city. The User-Agent becomes device type, operating system and browser. Accept-Language becomes a language breakdown, which is often more useful than country for a tourist area: the bakery may see 40 percent of scans in French and 25 percent in English on a flyer placed in a hotel lobby. The timestamp becomes the time series that shows the Saturday market spike.

The step that matters happens before any of that: does the server keep the raw request, or only the derived counts? A server that stores every request line with its IP address holds a log of identifiable visits. A server that increments "Belgium, Android, Dutch, Saturday 11:00" and discards the request holds a table of numbers. Both produce the same charts. Only one of them holds personal data at rest.

Why an IP address is personal data

The reason the distinction matters is that the IP address is personal data in the EU, even when it is dynamic and even when the website operator cannot identify the person alone. The Court of Justice of the European Union ruled in Case C-582/14, Breyer v Germany, on 19 October 2016 that a dynamic IP address registered by a website operator constitutes personal data with respect to that operator if it has the legal means enabling it to identify the visitor with the help of additional information held by the internet service provider. That is press release 112/16, and the reasoning has shaped every European analytics discussion since.

The practical consequence: a scan log with IP addresses is a file of personal data, with everything that follows from that, including retention limits, a lawful basis and a place in your records of processing. A count table without IP addresses is not. The legal checklist for QR campaigns is covered in our GDPR guide for QR codes; this article stays on the technical side of that line. This is not legal advice.

The French regulator offers a useful benchmark for what a "counting only" tool looks like. The CNIL's page on audience measurement tools that can be exempt from consent lists the conditions: the tool is used strictly for audience measurement, produces only anonymous statistics, does not track a person across different sites or apps, and does not cross the data with other processing or pass non-anonymous data to third parties. Read those four conditions as an engineering specification and you have the design brief for cookie-free QR code analytics.

Counting versus recognising: the line that matters

Every analytics system sits on one side of a simple line. Counting answers "how many scans came from Belgium on Saturday". Recognising answers "is this the same phone that scanned the poster on Tuesday". Recognising is what a cookie is for: a small identifier stored on the device so that the second visit can be tied to the first. It is also what makes a cookie banner necessary, because storing and reading an identifier on someone's phone falls under the ePrivacy consent rules unless it is strictly necessary for the service the user asked for. A redirect does not need it.

The temptation to recognise is real, because it unlocks unique visitors, return rates and retargeting audiences. The cost is that every one of those features drags the QR campaign into consent territory and turns a table of numbers into a register of people. For a printed flyer, the question to ask is whether "unique scanners" would change any decision you make. Usually it would not; you would still move the flyer to the better spot.

How EUQR QR code analytics count without cookies

EUQR analytics are built to stay on the counting side. The redirect sets no cookie and stores no identifier on the phone, so there is nothing to consent to at the redirect. Scan data and short-link data are hosted in Amsterdam. EUQR never stores raw IP addresses: the country and the device are derived at the moment of the request and only the aggregate counts are kept. Analytics come from privacy-preserving hashes that rotate daily. In practice that means the hash cannot be reversed to an address and stops matching the same phone the next day, so the system can keep same-day counts sensible without ever being able to say who scanned.

The result on your side is a dashboard with scans per dynamic QR code and clicks per short link, as a time series and broken down by country, device, browser and language, always as aggregate counts. Because no cookie is set and no third-party tracker is loaded by the redirect, your own landing pages need no cookie banner on account of the QR code. Whether your page needs one for other reasons, such as a Google Analytics tag or an embedded video, is a separate question about your page, and the GDPR-ready generator on this page explains where the line runs.

What you give up, and why print campaigns rarely miss it

Honesty about the trade-off is part of the design. Cookie-free QR code analytics cannot show individual scan paths, cannot tell you that one person scanned three different codes, cannot build a retargeting audience and cannot attribute a purchase two weeks later to a specific scan. If your business model depends on any of those, you will need consented tracking on the landing page itself, and that is a decision to take with your privacy officer, not with a QR tool.

For most print campaigns, none of those is the question being asked. The bakery wants to know whether the hotel flyer or the market flyer works, which language to print next time, and whether the Saturday spike justifies a second batch. Placement-level counts answer all three. What the counts cannot do is make one anonymous visitor into a known customer, and for paper that is usually the right limitation to accept.

Reading QR code analytics per code and per placement

The habit that turns counts into decisions is one code per placement. The bakery prints one code for the hotel lobby, one for the market stall and one for the shop window, all pointing at the same ordering page. Now the dashboard compares placements directly: hotel 412 scans, market 1,180, window 96. Combine that with the language split and the time series and you have a printable report that took no cookies and no consent to produce.

Retention follows the plan you are on: 30 days of analytics on Starter, 90 days on Pro, 365 days on Business and 730 days on Agency, with aggregate totals always kept. CSV export is available from Pro, so a monthly extract can live in your own spreadsheet as long as you like. Plan limits and prices are on the pricing page, with unlimited scans on every plan, so a campaign that works better than expected costs nothing extra to measure.