How to Track QR Code Scans, and What Analytics Miss

Tracking needs something in the middle that sees the scan. A dynamic QR code provides that: the printed pattern holds a short link, the phone opens it, and the QR service’s server records the request before redirecting the browser to your page.

A static code has no middle. The destination is inside the pattern, and the phone goes straight there. The code maker never hears about the scan. You still have two options:

• Tag the URL. If the static code points to your own website, add UTM parameters (for example ?utm_source=poster&utm_medium=print). Your web analytics will then show those visits as coming from the code. See UTM tracking for print campaigns.
• Use a page only the code links to. Views of yoursite.com/spring-poster came from the poster, as long as the address appears nowhere else.

Either way you count page loads, not scans. And a static WiFi or contact card code can’t be tracked at all, because the phone never opens a web page.

When the phone opens the short link, it sends an ordinary web request. Everything a scan record contains comes from that request:

• Time of the request.
• Approximate location, looked up from the IP address. Country is usually right. City is a best guess. MaxMind estimates 99.8% accuracy at country level, about 80% at US state level and about 66% for US cities within a 50 km radius (as of October 2026). Mobile carriers often route traffic through gateways in another city, and a VPN or a relay such as iCloud Private Relay shows the relay’s address, not the phone’s.
• Device, operating system and browser, read from the browser’s user agent string.
• Language, from the phone’s preferred language setting.
• Referrer, which is usually empty for camera scans. It fills in when someone taps the link on a web page instead.

A scan is a web request, not a person. Tracking cannot tell you:

• Who scanned. No name, email or phone number, unless the person types them into a form.
• Age or gender. Nothing in the request reveals them.
• Whether they read the page. The scan is logged at the redirect, whether or not the page ever loads.
• Whether they bought anything, unless you track that separately with an offer code, a form or checkout analytics.
• Where the code was. A photo of your poster shared in a group chat scans the same as the poster.

Some of what scan records do hold, such as IP-derived data, counts as personal data under privacy laws. See QR code tracking under GDPR and CCPA.

Total scans counts every request. Unique scans tries to count people, but a server can only see network addresses, so it counts distinct IP addresses (or hashes of them). That makes it an estimate that errs both ways:

• Undercounting. Everyone on one office or café WiFi shares one public IP address, so ten colleagues count as one. Mobile carriers also put many customers behind shared addresses.
• Overcounting. One person who scans on WiFi, then again on cellular, has two addresses and counts twice.

Bots inflate both numbers if nobody filters them. When someone pastes a short link into WhatsApp, Slack or a social post, the platform fetches it to build a preview. Search crawlers follow links too. Filtering by user agent catches the ones that identify themselves; some security scanners imitate ordinary browsers, so no filter is perfect.

The scan is counted on the redirect server. A session in Google Analytics is counted only if the page loads, the analytics script runs, and the visitor allows it. Fewer sessions than scans is normal, for several reasons:

• The tab closes first. Someone scans, sees the page is slow, and leaves before the script loads.
• The script is blocked. Content blockers stop many analytics scripts.
• Consent is refused. With a consent banner in Google’s basic consent mode, Google says no data is collected while tags are blocked (as of October 2026).

Sessions can also exceed scans. A tagged URL that gets bookmarked or shared keeps its campaign tags, so later visits are credited to the campaign without any scan. If sessions fall to half your unique scans, check the landing page: it may be slow, broken or missing its analytics tag.

Treat scan counts as a consistent measuring stick rather than an exact headcount. The errors stay roughly the same from week to week, so comparisons work even when absolute numbers are fuzzy. Compare placements, weeks and times of day.

A hypothetical example: a bike shop runs a spring service offer with a separate dynamic code in each of three places. After 28 days:

What the owner can learn:

• The poster works after hours. The shop closes at 6 pm, and about a third of poster scans come after that. The landing page should let people book online, not just list opening hours.
• The poster gets repeat scans. 412 total against 298 unique is about 1.4 scans per address, against 1.1 for the counter card. People walking past daily, or a page that didn’t answer their question, can both cause that.
• Sessions roughly agree. Google Analytics shows 452 sessions for the campaign, 47 fewer than the 499 unique scans (about 9%). That gap fits the reasons above.
• Scans aren’t sales. The flyer’s 60 scans could still bring the most bookings. Only conversion tracking answers that.

Every CirculateQR dynamic code logs each scan with the time; country, region, city and approximate coordinates (from the IP address); time zone; device type, operating system, browser and language; the referrer and user agent; which routing rule or destination was used; the code’s UTM tags; and a bot flag. The IP address itself is not stored in the scan record. It is kept as a salted one-way hash, and unique scans are counted as distinct hashes.

Link previewers and crawlers are flagged by user agent and left out of dashboards and exports. History covers 7 days on the free plan, 90 on Studio, 365 on Artisan and unlimited on Stealth, and you can export scans as CSV on every plan within that window. An AI Insights report summarizes your scan data and uses AI credits.