QR Code Tracking: Scan Analytics and CSV Export

Two mechanisms, and they answer different questions. The first is one code per placement: a scan can only ever be attributed to the code that was scanned, so if the same code goes on ten posters you get one number and no way to split it. Generate a separate dynamic code for each poster, table tent or mailer and the attribution is structural rather than inferred. Folders keep that organised: 10 on Lite, 25 on Pro, unlimited on Max. The second is UTM parameters on the destination: EZQR records all five (source, medium, campaign, content, term) against the scan and forwards them to the destination, so the same scan is attributable in your own analytics too. Each scan also carries the referrer and the final landing URL.

Both. Each scan carries an anonymous visitor ID and a session ID, so repeat scans are distinguishable from first-time ones and multiple scans inside one session are not counted as separate people. That is the honest limit of engagement measurement from a redirect: it tells you how often a code is scanned and how much of that is the same device coming back, not who the person is or what they did after they landed. Anything past the redirect (time on page, items added to a basket, a form submitted) belongs to your own analytics, which is what the UTM pass-through is for.

Up to a point, and the limits are worth knowing before you commit. Max at $20/mo adds 5 team seats, unlimited dynamic codes, unlimited folders, REST API access and scan-threshold email notifications. Pro at $10/mo is single-user but carries full scan history, CSV export, A/B testing and 100 dynamic codes. Neither tier offers SSO, audit logs, or role-based permissions beyond simple team membership, so an organisation that needs those should evaluate an enterprise platform instead. Saying otherwise would waste your procurement cycle.

Free records scan counts only, with no location data and no history. Lite at $5/mo adds 30 days of history and country-level location. Pro at $10/mo unlocks full history with no retention limit, city-level location, CSV export and A/B testing. Max at $20/mo adds region-level detail, API access, team seats and scan notifications. The redirect records the same fields on every plan; the plan decides how much of it you can see and keep.

Timestamp, country, city and region, device type, browser, operating system, referrer, the final landing URL, and all five UTM values (source, medium, campaign, content, term). Each scan also carries an anonymous visitor ID and a session ID so repeat scans are distinguishable from first-time ones, plus the variant name when A/B testing is active. No name, email, phone number or precise location is captured, because a redirect has no access to any of it.

No. The redirect responds first and the scan is written afterwards, outside the request that the visitor is waiting on. The scanner gets its redirect immediately, and the analytics write happens in the background. The redirect also carries an X-Robots-Tag noindex header so tracking URLs never enter search results.

No, and neither can anyone else. A static code encodes the destination directly in the black-and-white pattern, so the phone goes straight to your site with no intermediate step to count. There is nothing to instrument. If you need scan data, the code has to be dynamic before it goes to print. The one partial workaround is putting a UTM-tagged URL inside a static code, which gives you GA4 sessions without scan-level detail, and locks those UTM values into the printed pattern forever.

City-level and directional. Location is derived from the IP address at the edge, not from device GPS, because a web redirect cannot request location permission. Mobile carriers frequently route traffic through gateways in another city, and corporate VPNs will place a scan in whichever country the exit node sits. Country data is reliable enough to act on. City data is useful in aggregate and wrong often enough that you should not build a decision on a single row.

Yes, if you set UTM parameters. EZQR forwards them to the destination URL, so GA4 attributes the session to your campaign instead of filing it under direct traffic. The two systems count different things and will not match exactly: EZQR counts redirects, GA4 counts sessions that finished loading. Scans where someone closes the browser mid-load appear in EZQR and never reach GA4, so EZQR totals normally run slightly higher.