How to track QR code scans (and what you can actually measure)

To track QR code scans you need a dynamic code, not a static one. A dynamic code points the phone at a short link you control (for example scanburst.com/q/abc123), and that link records the scan before forwarding the person to your real destination. Because every scan passes through that middle step, you can see how many people scanned, roughly where they were, what device they used, and whether they had scanned before. A static code has no middle step, so there is nothing to record. This guide explains exactly what you can measure, what you cannot, and how the tracking works under the hood.

Why only dynamic codes can be tracked

A static QR code stores your destination directly inside the pattern. When someone scans it, their phone reads that URL and opens it. Your server never hears about the scan, and neither do you. There is no counter, no timestamp, no way to know it happened. The code is a printed shortcut, nothing more.

A dynamic QR code works differently. Instead of encoding your final URL, it encodes a short link that belongs to your QR tool. The scan hits that link first. The link logs a small, privacy-safe event, then instantly redirects the phone to wherever you actually want it to go. The person notices nothing except your page loading. You get a data point.

This is the whole reason tracking exists. If a tool claims to track scans on a static code, it cannot, because the code physically routes around any server that would count it. Tracking and dynamic codes are the same feature described two ways.

What you can measure

A dynamic code turns each scan into a lightweight event. From those events you get:

Metric	What it tells you
Scans over time	How many scans per hour, day, or month, so you can see trends and spikes
Location by country and city	Approximate area of the scan, derived from the network the phone is on
Device type	iPhone or Android, mobile or desktop
Repeat vs new	Whether a scan came from someone who scanned before or a first-time visitor

A few notes that matter for reading these numbers honestly. Location is approximate. It comes from the network address the request arrives on, which maps to a rough city, not a street. It is useful for comparing regions or confirming a campaign reached the right country, not for finding an individual. Device type is read from the browser signature the phone sends, which is reliable for the mobile versus desktop split and the iPhone versus Android split. Repeat versus new is what turns a raw scan count into something meaningful, because 500 scans from 500 people is a very different result than 500 scans from 50 people checking your menu five times each.

What you cannot measure, and why

This is the part most articles skip, and it is the part that builds trust with the people scanning your codes. A QR scan is an anonymous web request. It does not carry personal information, so there are hard limits on what any tool can honestly report.

You cannot know who the person is. There is no name, no account, no identity attached to a scan unless the person later signs in or fills out a form on the page you sent them to. The scan itself is faceless.

You cannot know their exact location. Phones do not hand over GPS coordinates when they scan a code. The approximate city comes from the network address, and that is as precise as it gets. Any product promising a pin on a map at street level is either guessing or misleading you.

You cannot know their phone number, their email, or anything else the person did not choose to give you. The scan is a request to open a link. That is all the phone sends.

Being clear about this is not a weakness. Scan analytics are genuinely useful precisely because they are aggregate and anonymous. You learn about patterns across a crowd, not about individuals, and that is enough to make good decisions without crossing a line your visitors would object to.

How scan tracking works, step by step

Here is the full path a single scan takes, from the moment a phone camera sees the code to the moment the number appears on your screen.

1. Someone points their camera at your dynamic code and taps the link that pops up. The link is your short URL, for example scanburst.com/q/abc123.
2. The request reaches the short link server. Before doing anything else, it reads a few harmless details from the request: a rough location from the network address, the device signature, and the time.
3. The server checks whether this looks like a real person. Bots, link previewers, and security scanners are filtered out so they never inflate your count.
4. The server records the event in a privacy-safe way. A good tool never stores the raw network address. It keeps a one-way hash instead, which is enough to tell a repeat scan from a new one but cannot be reversed to identify anyone.
5. The server redirects the phone to your real destination. This happens in a fraction of a second, so the person just sees your page load normally.
6. The event shows up in your dashboard, where it is added to your totals and charts.

The order matters. The scan is counted and then forwarded, which is why the tracking is invisible to the person and instant from their point of view. It also means you can change the destination later without reprinting the code, since the short link stays the same while the target behind it moves.

Using the data

Numbers are only worth collecting if they change what you do. A few practical ways to use scan analytics:

Spot your peak times. If a code on a restaurant menu gets scanned mostly between 12 and 1, you know when your table traffic actually happens, and you can staff or promote around it.

Compare campaigns and locations. Put a different dynamic code on each poster, flyer, or city, and the scan counts tell you which placement earned its space. A code that gets 40 scans and one that gets 4 are giving you a clear budget decision.

A/B test where the code goes. Because a dynamic code lets you swap the destination without reprinting, you can send this week's scans to one landing page and next week's to another, then compare. This works well for a code that drives to app download or an Instagram profile, where the right destination is not always obvious until you have tried both.

Watch repeat versus new over a campaign's life. A healthy launch shows lots of new scans early, then more repeats as the same people come back. If you only ever see first-time scans, your code is reaching new eyes but not earning return visits, which is a content problem, not a traffic problem.

None of this requires knowing who anyone is. The aggregate picture is enough to tell you what is working.

If you want to start measuring, you need a dynamic code, and you can design one free at the Scanburst generator. Scanburst includes scan analytics on Pro ($12/mo, or $9/mo billed yearly) and Business ($39/mo), with the privacy-safe approach described above built in. Make the code, print it, and watch the scans come in.