How to Track QR Code Scans (Without Guesswork)

Tracking QR codeA 2D matrix barcode that encodes data in a square grid of black and white modulesA single black or white square in the QR grid. The number of modules per side scales with the QR versionThe size of a QR code, numbered 1 (21×21 modules) through 40 (177×177). Higher versions store more data but require more printed space. Read more →, from 21×21 modules for version 1 up to 177×177 for version 40. Read more →. Read more → scans is not magic. It is measurement design. A scan is just a website visit triggered by a camera tap, so the same rules that apply to any other marketing funnel apply here: define the event you want to learn about, tag the source, and watch what happens after the visit.

This guide walks through four ways to track QR scans, when to choose each one, what to measure beyond the scan count, and the naming and privacy habits that keep your data usable as your program grows.

Start with the question, not the tool

Before picking a tracking method, decide what you actually want to learn. The methods differ in cost and complexity, and choosing the wrong one because it has a nicer dashboard wastes weeks.

Useful questions to answer:

• Which placement drives the most scans? Window poster versus checkout counter, table tent versus menu insert.
• Which location performs best? Store 12 versus store 27, downtown versus suburban.
• Which creative wins? Headline A versus headline B, different QR placements within the same poster design.
• Do scans convert? Does anyone actually buy, book, sign up, or join the Wi-Fi after scanning?

If you only track raw scans, you can run a campaign that produces thousands of scans and zero business outcomes without ever noticing. The interesting metric is almost never the count of scans. It is what those scans did next.

Method 1: Unique landing-page URLs per placement

The cleanest tracking method is one QR code, one URL.

Examples:

• Window poster → https://example.com/spring-sale-window
• Checkout counter → https://example.com/spring-sale-checkout
• Table tent → https://example.com/spring-sale-table

Each URL records its own pageview in any analytics tool. Attribution is by URL path, which means it survives ad blockers, query-string strippers, and link sharing.

Pros

• Clear attribution by URL path, no extra tagging required.
• Survives sharing — if someone forwards the link to a friend, the placement attribution stays.
• Easy to audit a year later. The URL itself documents the placement.
• Works with any analytics tool, including ones that ignore UTM parameters.

Cons

• You need to create and maintain multiple landing pages or path aliases.
• For dozens of placements, the management overhead grows.

This is excellent for businesses with full control of their website that want stable, long-term measurement. Generate the codes for each unique URL with URL to PNG or URL to SVG for print.

Method 2: UTM parameters on a shared landing page

UTM parameters are query-string tags appended to a URL. Analytics tools recognize them and break out traffic by source, medium, campaign, and content. This lets you point many QR codes at the same landing page and still see them as distinct sources.

Example payload encoded in the QR code:

https://example.com/spring-sale?utm_source=poster&utm_medium=qr&utm_campaign=spring_2026&utm_content=window_a

Recommended UTM fields for QR codes:

• utm_source — the physical channel: poster, packaging, receipt, table_tent, parking_sign.
• utm_medium — use qr consistently across every QR campaign so you can filter all QR traffic in one report.
• utm_campaign — the campaign name: spring_2026, brand_launch_q2.
• utm_content — placement-level identifier: window_a, checkout_b, store12_table_3.

Pros

• No extra landing pages to manage.
• Works with GA4, Plausible, Fathom, Matomo, and almost everything else.
• Great for A/B tests of creative or placement.
• Easy to deploy at scale once a naming convention is in place.

Cons

• Long query strings make denser QR codes. A 200-character URL is harder to print small than a 30-character one. See error correction explained for what density costs you.
• Some apps and platforms occasionally strip parameters when sharing.
• Requires discipline. UTMs that drift in naming become useless data.

Keep UTMs short and consistent. The best tracking system is the one your team will actually use the same way every time.

Method 3: A redirect layer you control

The third option encodes a short URL that points to a redirect service you run, which logs the hit and forwards the user to the final destination.

The QR code carries:

https://go.example.com/spring-window-a

Your redirect service logs the request and issues a 302 to:

https://example.com/spring-sale?utm_source=poster&utm_medium=qr&utm_campaign=spring_2026&utm_content=window_a

Pros

• Short payloads mean simpler, more reliable QR patterns at small print sizes.
• Server-side logging captures every hit, including users with aggressive ad blockers.
• Central place to manage analytics and link health.
• You can change the destination later without reprinting, as long as the short link itself stays the same.

Cons

• Operational responsibility. go.example.com has to keep working for as long as printed codes exist. That can mean years.
• More infrastructure or a vendor dependency.
• If the domain ownership changes hands, every printed code is at risk.

If you choose this method, treat the redirect domain like critical product infrastructure. Monitor uptime. Auto-renew the domain. Document who owns the rules. The trade-offs are covered in detail in static vs dynamic QR codes.

Method 4: Vendor-managed dynamic QR platforms

Many QR platforms offer dynamic codes where the platform owns the redirect domain, hosts the analytics dashboard, and manages the link rules. You pay a subscription, you get a dashboard, you avoid building anything.

Pros

• Quick setup, often a few minutes.
• Built-in dashboards with location, device, and time-of-scan data.
• Easy to demo to a non-technical stakeholder.

Cons

• Vendor lock-in. Printed codes depend on the vendor’s redirect domain. Stop paying and the codes stop working.
• Limited control over data retention, privacy, or analytics granularity.
• Migration is hard. Moving a hundred printed codes to a new vendor means reprinting everything.

For short-lived campaigns, vendor platforms are fine. For packaging or long-lived signage, the operational continuity question matters more than the dashboard convenience. Domain ownership wins on a long enough timescale.

Measure outcomes, not just scans

Scans are an input. They tell you whether the physical placement got eyeballs. Outcomes are what tell you whether the campaign actually worked.

Track:

• Landing page views — confirms the scan turned into a real session.
• Primary conversion — whatever the QR code is meant to drive. Purchase, signup, booking, form submit, click-to-call, Wi-Fi join.
• Drop-off rate — bounces and quick exits. A high scan count with 90% bounces means the landing page is wrong, not that the QR code is winning.
• Time to first meaningful action — a slow page is the most common reason scans do not convert.
• Device mix — iOS versus Android. Useful for debugging compatibility problems and for understanding your audience.

For multi-placement campaigns, the most valuable comparison is scan-to-conversion rate by placement, not raw scans. A poster that gets 1,000 scans and 10 conversions is worse than one that gets 200 scans and 40.

A solid tracking setup for most teams

If you want something reliable without building infrastructure:

1. Use your normal website URLs over HTTPS. No redirect layer required.
2. Append UTM parameters with a consistent naming convention.
3. In GA4 (or your analytics tool of choice), build a report comparing session_source, session_medium, campaign, and content.
4. Define conversion events on the landing page — form submits, checkout, click-to-call, button taps.
5. Review the report weekly during the campaign. Compare placements on conversion rate, not scan count.

For a small team, this covers maybe 80% of QR measurement needs. The remaining 20% — server-side capture, vendor analytics, complex routing — are real but rare.

Naming conventions that scale

Once you have more than ten placements, naming discipline is the difference between data you can use and data nobody trusts. A useful schema:

• utm_source — physical channel, lowercase, underscores: poster, packaging, receipt, table_tent, sign, business_card.
• utm_medium — always qr for QR campaigns. Filter on this to pull every QR scan in one query.
• utm_campaign — {theme}_{period}: spring_sale_2026, brand_launch_q2_2026.
• utm_content — {location}_{placement}_{variant}: store12_window_a, nyc_lobby_b.

Write the rules down. Put them in a shared doc. Make new codes follow the same shape every time. The first time someone deploys Spring Sale 2026! with capital letters and a space, your reports start splitting traffic across three near-duplicates.

Privacy, briefly

QR tracking should focus on:

• placement performance,
• landing-page behavior,
• conversion outcomes.

It should not focus on identifying individual scanners. Avoid fingerprinting, cross-site tracking, or asking for personal information just to count a scan. Privacy-first measurement keeps user trust higher, especially with QR codes in public spaces where the scanner did not opt in to anything beyond a single page visit.

For most businesses, “did this poster drive sales” is the question. You do not need to know who scanned it to answer that. For a deeper look at the trust side, see are QR codes safe?.

Sources

• Wikipedia — UTM parameters — Background on the URL-tagging convention used to attribute traffic.
• Google Analytics — Campaign URL builder — Official tool for constructing UTM-tagged URLs.