How to Track QR Code Scans

How scan tracking actually works

Trackable QR codes don't encode your final URL. They encode a short link — something like a redirect URL on a tracking service's domain. When someone scans the code, their phone requests that short link, the server logs the request (timestamp, rough location from IP, device type from the user agent), and then instantly redirects the phone to your real destination. The scanner sees a fraction of a second of delay, if that.

Every data point in a QR analytics dashboard comes from that one logged HTTP request. There's no app involved, no special camera permission, and nothing embedded in the code itself — the standard phone camera triggers it just by opening the link. This is also why these are called dynamic QR codes: since the printed code only contains the short link, the service can change where it redirects at any time. The code on your flyer stays the same; the destination behind it doesn't have to.

Why static QR codes can't be tracked

A static QR code encodes the destination directly — https://yoursite.com is baked into the pixels. Scans go straight from phone to your site with no intermediary, so there's nothing to log per-code. Your website analytics will see the visit, but it looks like any other direct traffic; you can't tell it came from a QR code, let alone which one.

Static codes still have real uses: they work forever with no service dependency, and they're the right choice for things like WiFi credentials or contact cards that never change. But if you need scan counts, or you might ever need to change the destination after printing, you want a dynamic code from the start. You can't convert a static code to dynamic after it's printed.

What you can know about each scan — and what you can't

From a single redirect request, a tracking service can reliably learn: when the scan happened, the country (and sometimes city-level region) from the IP address, the device class — mobile, tablet, or desktop — from the user agent string, and occasionally a referrer. Aggregated, that's enough to answer the questions that actually matter: which placements get scanned, when, from where, and on what kind of device.

Here's what you cannot know, no matter what a vendor implies: who scanned the code. No name, no phone number, no email, no precise GPS location, no browsing history. A scan is an anonymous web request, the same as any click on a link. IP-based location is approximate — it reflects the network, not the person's exact position. If a service claims to identify individual scanners without them filling out a form, be skeptical.

This cuts both ways. It limits what you can measure, but it also means putting a tracked QR code on a poster isn't surveillance. You're counting anonymous visits, which is the same thing every website on the internet already does.

UTM parameters: the complementary approach

UTM parameters are tags you append to a destination URL — for example ?utm_source=qr&utm_medium=poster&utm_campaign=spring-menu. They don't track anything by themselves, but your website analytics (Google Analytics, Plausible, Fathom, etc.) reads them and attributes each visit to that source. Point a QR code at a UTM-tagged URL and your existing analytics can separate QR traffic from everything else.

UTMs and redirect tracking answer different questions. Redirect tracking counts scans per code, including scans that bounce before your page loads, and works even if you have no site analytics at all. UTMs tell you what happened after the scan — pages visited, conversions, time on site — inside tools you may already use. The strongest setup is both: a dynamic QR code whose destination URL carries UTM parameters. The redirect logs the scan; your analytics tracks the session.

Reading the data: the metrics that matter

Once scans are being logged, a few views do most of the work. Scans per day shows whether a placement is alive or dead and whether a campaign push moved the needle. A time-of-day histogram tells you when your audience actually encounters the code — a restaurant table code and a bus-stop poster have very different curves. Country breakdown catches surprises in where scans come from. Device split matters because it tells you what to optimize the landing page for (usually overwhelmingly mobile).

This is roughly the set ScanTrail (forever-scan.com) reports for each dynamic code: scans per day, time-of-day histogram, country, device, and referrer, with redirects served from Cloudflare's edge so the hop adds negligible delay. Its free tier includes three dynamic codes with the last seven days of analytics, which is enough to test whether tracking is worth it for your use case before paying anyone anything.

One practical rule regardless of tool: use a separate code for each placement. One code on the flyer, a different one on the poster, a third in the email footer. Per-code counts are only meaningful if each code maps to exactly one location or channel — that's the whole point of tracking.

Common mistakes to avoid

Printing a static code when you needed tracking is the expensive one — there's no retrofit, only a reprint. Second: reusing one code across placements, which collapses all your data into a single unattributable number. Third: forgetting that scan counts include your own test scans; scan your code a few times before launch and mentally subtract them, or test before the campaign window starts.

Finally, check the redirect dependency before committing. With any dynamic QR service, your printed codes only work while that service's redirect servers do. That's a real trade-off, not a footnote — it's the price of editability and analytics. For anything permanent-and-unchanging, a static code with a UTM-tagged URL may honestly be the better choice.

Common questions