How to Track QR Code Scans (and What the Numbers Cannot Tell You)

A static code cannot be tracked at all — it sends the phone straight to your address and nothing counts the trip. Tracking begins with a dynamic code, where the scan passes through a redirect that can count it.

After that, almost everything useful is decided before you print.

One code per placement — the decision that matters

The instinct is one code for the campaign, printed on everything. It is easier to manage and it answers nothing: at the end you have a number and no idea which poster earned it.

Give each placement its own code — the window, the flyer, the table tent, the delivery bag — all pointing at the same page. Now the counts are a comparison rather than a total, and the cost of that is a few minutes at creation time.

This matters more here than elsewhere, because there is no geolocation in our analytics at all: not coordinates, not city, not country. Many services infer a country from the IP address; we do not collect it, which also means we cannot report it. Separate codes are how you learn where scanning happened — and they are more reliable than an IP guess anyway, because they tell you about the placement rather than about the phone's network.

What a single scan records

One row, written before the redirect:

• the time of the scan;
• which code;
• device type — mobile, tablet, desktop;
• operating system and browser, as reported by the request;
• the referrer, if the browser sent one — a camera scan usually sends none;
• a salted SHA-256 hash of the IP address, used to count unique visitors.

No name, no email, no advertising identifier, and nothing that ties one code's scans to another site's activity.

Adding UTM parameters

Scan counts tell you the code was scanned. They do not follow the visitor into your own analytics, so if you want to see what those people did after arriving — read the page, filled the form, bought something — put UTM parameters on the destination:

?utm_source=poster&utm_medium=qr&utm_campaign=spring

Two practical notes. Keep utm_medium=qr consistent across every code, so your web analytics can separate scan traffic from everything else in one filter. And put the parameters on the destination of a dynamic code, never inside a printed static code — parameters are exactly the sort of thing that changes, and in a static code they are set in ink.

Reading the first week

The timeline is the most useful view, and it answers different questions at different scales:

• Day one, zero scans on a busy placement. Not a slow start. Either the code cannot be read — rescan the printed piece yourself before anything else — or nobody noticed it, which usually means there is no reason to scan printed next to it.
• A spike then nothing. Curiosity, not demand. The destination did not reward the scan.
• A steady low line. The placement works; the question is whether the traffic converts, and that is your web analytics, not the scan count.
• Repeat visitors. Unique visitors versus total scans separates "many people once" from "a few people often" — a menu shows the second pattern, a poster the first.

Two things scan counts will never tell you

Who scanned. The counter is anonymous by construction. If you need to know who, the destination has to ask — and then it is your form and your privacy notice, not ours.

Whether it worked. A scan is an intention, not an outcome. Ten thousand scans and no sales means the code did its job and the page did not. Judge the code by scans, judge the campaign by what happens after.

A workable setup, start to finish

1. One dynamic code per placement, named so you will recognise it in six months — "window Feb", not "code 4".
2. UTM parameters on the destination, with a consistent utm_medium=qr.
3. Print one proof and scan it before the run.
4. Check day one against what the placement should produce, and rescan the print yourself if it is zero.
5. Export the history when you need it outside the dashboard — CSV export is on the paid plans; free reads the last 30 days.

Quick answers

• Can I track a static QR code? No. Nothing sits between the phone and your address to count it.
• How do I tell which poster worked? Give each placement its own code. There is no location data, so that is the only way.
• Do you record where a scan happened? No — no coordinates, no city, not even country.
• Do I still need UTM parameters? If you want to follow the visitor past the arrival, yes.
• Can I see who scanned? No. Times, devices and counts only.
• What does zero on day one mean? Rescan the printed piece first. A working code with no scans is a placement or a missing reason.