One of the most common questions we hear is some version of “how many people scanned my QR code?” The honest answer is that a QR code itself has no memory — it’s a static pattern that encodes a fixed piece of content, and by design it doesn’t call home to report who scanned it or when. If you want to measure performance, the tracking has to live in what the code points to, not in the code itself. This guide walks through the practical ways to do that.
Why “the QR code” isn’t what gets tracked
It helps to separate two things that often get conflated: the QR code (a visual encoding of some text, usually a URL) and the destination (a web page, a file, a contact card). A generator like the one on this site converts your content into a scannable pattern; it doesn’t operate a server that logs who scanned it, because the whole point of a client-side, static QR code is that it works forever without depending on anyone’s servers staying online. Tracking has to be built into the destination side instead.
Method 1: Route through a link shortener with analytics
The simplest way to get scan data is to encode a short link from a URL shortener that provides click analytics — many services report country, device type, referring app, and timestamp for every click. Because the QR code just encodes that short URL, you can change where it redirects later without reprinting anything, and you get a running count of “clicks,” which for a QR code is a reasonable proxy for scans. The trade-off is an extra redirect hop, which adds a small amount of load time, and you’re depending on a third-party service’s dashboard and continued existence.
Method 2: Add UTM parameters to a page you already track
If your destination is already on a site running Google Analytics, Plausible, or a similar tool, you can encode a URL with UTM parameters — utm_source=qr, utm_medium=print, utm_campaign=summer-menu, for example — so scans show up clearly separated from your other traffic sources in your existing analytics. This avoids adding a third-party redirect and keeps everything in one dashboard. The downside is that a long URL with several parameters makes the QR code itself visually denser, which can hurt scan reliability at small print sizes — so if you go this route, keep the parameter values short.
Method 3: Build a dedicated landing page per placement
For campaigns where you’re placing the same QR code in several different physical locations — say, one on a storefront window and another on a delivery box — encoding a unique landing page URL for each placement (even if they otherwise show the same content) lets you distinguish scan sources just by looking at page views per URL in your existing analytics, without needing UTM parameters or a shortener at all. This works well when you control the destination pages and just want to know which physical placement is driving traffic.
What you can and can’t learn this way
All three methods above measure clicks or page views on the destination, which is a solid proxy for scans but not identical to it — someone might scan the code, see the preview, and decide not to tap through, and that intent never gets recorded. What you generally can learn: total scan volume over time, rough device and location breakdowns, and which physical placement or campaign variant performed best. What you generally can’t learn without additional infrastructure: unique scanner identity across sessions, or scans that never resulted in the destination page actually loading (for instance, a scan with no internet connection at that moment).
Setting a baseline before you launch
Before distributing a printed QR code widely, it’s worth doing a small controlled test: place the code somewhere with predictable, countable foot traffic — a single store location, an event booth — for a defined period, and compare scan-driven page views against your estimate of how many people passed by. This gives you a rough scan rate you can use to set expectations for a larger rollout, and it can surface problems (a code that’s too small, poor lighting, low contrast) before you commit to printing thousands of copies.
Reading the data without over-interpreting it
A spike in scans right after launch, tapering off over the following weeks, is a normal pattern for most static placements — it usually reflects the code being new and novel rather than a real decline in interest, and doesn’t necessarily mean the campaign is failing. Time-of-day and day-of-week patterns are often more informative than the raw total: a code on a restaurant table tent that gets scanned mostly during lunch service tells you something actionable about when your audience is engaging, in a way that a single cumulative number doesn’t.
A note on privacy
Whatever tracking method you choose, be transparent about it. If your destination page sets analytics cookies or the URL shortener logs identifying information, that activity should be reflected in your site’s privacy policy and cookie policy, the same way it would be for any other traffic source. Scanning a QR code shouldn’t come with hidden data collection that a visitor wouldn’t reasonably expect from clicking a normal link.
Putting it together
For most small businesses and one-off campaigns, a link shortener with built-in analytics is the fastest way to get useful numbers with the least setup. For teams already running detailed web analytics, UTM-tagged URLs into your existing dashboard usually give richer, better-integrated data. Either way, the QR code itself stays simple — it’s the destination that does the measuring.
Ready to build a code around a trackable link? Head to the QR code generator, paste in your tagged URL, and download it in the format you need.
Free, unlimited, and it takes about ten seconds.