QR code analytics without cookies: what EU-conscious teams need to know
Most web analytics runs client-side: a script loads in the browser, sets a cookie, and reports back to a server. A QR code scan doesn't have to work that way at all, and understanding why matters for any team that has to answer for where visitor data goes.
A scan is already a server request
When someone scans a dynamic QR code, their phone makes an HTTP request to a redirect server before it ever reaches the final destination page. That request already carries useful signal — country (from the network), device type and OS (from the user agent), what time it happened, and if the code has one, a referrer. None of that requires a script running in the visitor's browser, because the measurement point is the redirect itself, not the page it sends them to.
That's a structurally different position than most analytics tools, which have to inject a script into a page they don't control in order to observe anything. A QR redirect is the point of control — the measurement is a natural side effect of the redirect happening, not an addition bolted onto it.
Why that means no cookie banner
A cookie banner exists because a tool is storing an identifier in the visitor's browser to recognize them across visits. Server-side scan logging doesn't need to do that to produce useful aggregate analytics — country, device, OS, referrer, and hour-of-day don't require persistently identifying an individual visitor, only categorizing the request that just happened.
Stelyo's analytics go a step further and never store a raw IP address at all: each scan is logged against a visitor hash that rotates daily, useful enough to deduplicate repeat scans within a day without being a durable identifier that persists across days or ties back to a real person. No tracking pixel, no cookie, no consent banner required — and no compliance debt building up in the background.
What this means practically for an EU-based team
For a team that has to think about GDPR, this removes an entire category of consent-management work for QR scan tracking specifically — there's no cookie to disclose, no consent state to check before logging a scan, no client-side script whose presence needs to be documented in a cookie policy. Combined with EU-hosted infrastructure (Ireland, in Stelyo's case) and, on paid plans, a signed Data Processing Agreement, the data residency question has a straightforward answer instead of a caveat-filled one.
What you still get, and what you don't
You get real, useful, server-verified numbers: total scans, trend over time, country and device breakdown, referrer source, hour-of-day patterns — exportable to CSV or pullable through the REST API. What you don't get is individual-visitor tracking across sessions or days, cross-site behavioral profiles, or anything that would need a consent banner in the first place. For measuring whether a QR campaign is working, that's the right trade — you rarely need to know who scanned, only how many, from where, and on what.