A QR code is just a pattern. It has no memory and no way to phone home. The code itself can never tell you who scanned it or how many times. What you actually track is the destination behind it, the link the code points to. Whether that link is trackable is a decision you make before you generate the code, not something you can bolt on afterward.
What "tracking a QR code" actually means
Every QR code encodes a string of text. Most of the time that string is a URL. When a phone camera reads the pattern, it decodes that string and opens it like any other link. So tracking a QR code scan is really tracking a click on that URL, the same way you would track a click from an Instagram bio link or an email. The QR code is just the delivery mechanism that got someone to tap it.
This matters because it means the question is not "can QR codes be tracked", it is "did you point this QR code at something that tracks clicks". A code that encodes a bare address, a phone number, or a raw destination URL with no tracking layer behind it will never produce a scan count, no matter how many times it gets scanned. If you want the fuller picture of what the format itself can and cannot do before you start tracking it, see what a QR code actually is.
Two ways to make a QR code trackable
There are two practical routes, and they behave differently once the code is printed.
A dedicated dynamic QR code service
These tools generate a short redirect URL, encode that in the QR pattern, and log every hit on the redirect before forwarding the visitor to your real destination. Because the redirect is what is printed, you can repoint it to a different URL later without touching the physical code. This is the classic dynamic QR code setup. Understand the tradeoff before you commit a large print run to it.
A link-in-bio page with a built-in QR code
The other route is simpler if the destination is already a page you control, like a link-in-bio profile. The QR code just encodes the page's own URL. Raydar generates one of these automatically for every profile, so a business card, table tent, or storefront sticker can point straight at a page that already has click tracking, UTM capture, and referrer data built in, without adding a separate redirect service to manage.
What QR scan data can and cannot tell you
Even with a fully trackable code, be realistic about what a scan record contains. You get a timestamp, a device type, a browser, and country and city level location in most tools. You do not get a name, an email address, or proof of who physically held the phone.
| Method | Scan count | Device and geo | Edit destination after printing | Typical cost |
|---|---|---|---|---|
| Bare URL baked into the code, no service | No | No | No, must reprint | Free |
| Dynamic QR platform (redirect URL) | Yes | Yes | Yes | Free to paid, limits vary |
| Link-in-bio page with a built-in QR code | Yes, as a page visit | Yes, country and city | Yes, edit the page itself | Free tier available |
| Your phone's own camera app | No, it just opens the link | No | Not applicable | Free |
How to track QR code scans for free
Choose a trackable destination first
Decide what the code should point to before you generate anything. A raw phone number, a Wi-Fi password, or a plain text string cannot be tracked at all, because there is no click involved. If you want scan data, the destination has to be a URL that lives behind an analytics layer, whether that is a dynamic QR redirect or a page like a link-in-bio profile.
Generate the code against that URL
Once you have a trackable link, generating the actual QR image is the easy part. Most link-in-bio tools and QR generators do this in one step from the page's own URL, so you are not managing a separate short link and a separate code.
Add UTM parameters before you generate it
If you are running the same destination through several placements, a flyer, a storefront window, and a conference badge, add a distinct utm_source or utm_medium to each version before you generate the code, using a tool like the UTM builder. Otherwise every scan lands in analytics as one undifferentiated bucket and you lose the ability to say which placement actually worked. See what UTM parameters are for the naming conventions worth sticking to.
Print or publish the code, then test it yourself
Scan it with your own phone before it goes out. This confirms the code decodes cleanly at the size and contrast you printed it at, and it lets you see exactly what a real visit looks like in your analytics so you recognize the pattern later.
Check your click analytics once scans start
After the code is live, the data shows up wherever the destination link's analytics live: scan count, rough timing, device type, and geography. There is no separate "QR dashboard" to check if the destination is a link-in-bio page or dynamic redirect you already track clicks through.
Watch for undercounting from preview crawlers
Messaging apps and some phone camera apps send a request to a URL to build a link preview card before the person actually taps through. If your tracking counts every request as a scan, you inflate the number. If it only counts full page loads, a preview fetch will not register at all. Either way, treat small scan counts skeptically for the first day or two after a code goes live, since preview traffic and real traffic are easy to conflate.
Reading QR results without over-trusting the numbers
Scan counts on printed material are always a floor. Not a ceiling. Someone can screenshot a code and scan it later. They can forward the photo to a friend who scans it from their own screen. Or they can scan it once and revisit the saved link directly without scanning again. Use QR data to compare placements against each other, this flyer versus that one, rather than treating the absolute number as a precise count of unique people reached.
The comparison matters more than the raw number. If a code on the front counter produces four times the scans of the identical code taped to the window, that tells you something actionable about foot traffic and eye level, even if neither number is a perfect census. Run the same code in two locations, or two versions of a flyer with different UTM tags, and let the relative gap do the talking rather than chasing an exact headcount.
What you cannot get from QR scan data, even with a good setup
It is worth being blunt about the ceiling here, because a lot of QR marketing implies more than it delivers. You will not get a name, an email address, or a phone number just from a scan, regardless of which tool you use. What you get is signal about the click itself, device, rough location, timing, and whichever campaign tag you attached before printing. If you need to capture identity, that has to happen on the landing page itself, through a form or an account login, not through the QR layer. Anyone promising you can identify individual scanners from the code alone is overselling what the technology does.
A QR code also cannot see what happens after someone lands on your page and leaves. If your destination is a link-in-bio page that then sends the visitor onward to your shop or your Instagram, the QR tool can tell you the scan happened and which link they tapped next, but it cannot follow them once they are on a third-party site you do not control. That is a different category of tracking, closer to a site-wide analytics setup than anything a QR code or a link click can provide on its own.
Common mistakes that break QR tracking
- Printing a bare URL instead of a tracked one. Once it is printed, there is no way to retrofit tracking onto that specific physical code.
- Reusing one QR code across unrelated campaigns. Without separate UTM tags or separate codes, you cannot tell a trade show scan from a storefront scan.
- Assuming the destination page's own analytics fire from the QR scan. If the code redirects through a service before landing on your site, check that service's tracking too, not just your website's.
- Ignoring device and geo signals. A spike in scans from a country nowhere near where the code was printed usually means a bot or a preview crawler, not a genuine visitor.
- Making the code too small or too low contrast to scan reliably. A code that fails half the time on the first try produces undercounted data that looks like poor performance when the real problem is print quality.
- Forgetting to check analytics until the campaign is already over. Check a few days in so you can catch a broken link or a mislabeled UTM tag while there is still time to fix it and reprint.