How I track QR code scans

QR code tracking is usually redirect tracking. The printed QR code opens a short campaign URL first, the system records the scan, then the customer is sent to the real destination.

That gives me enough data for local print work without making the QR code complicated: scan count, time, campaign, and destination. I still treat the numbers as directional. A scan is not a customer.

Use a dynamic QR campaign

The redirect is where tracking happens

A static QR code points straight to the final URL. There is no service in the middle to count scans or change the destination later. That can be fine for simple print jobs, but it is not enough when I need reporting.

A dynamic QR code points to a managed short URL. When someone scans, that short URL can log the request and redirect to the destination. It can also be edited later, which matters when the printed code is on signs, menus, business cards, or flyers.

I keep the QR payload short for the same reason I do with PDF codes. DENSO WAVE's QR Code documentation explains that larger amounts of encoded data require larger QR symbols. The short redirect URL keeps the printed symbol simpler.

Name campaigns before printing

Bad names ruin good data

I name the campaign before exporting the QR code. The name should tell me the business, channel, location, and print asset without opening the file.

• dentist-main-street-front-desk-card
• cafe-june-menu-table-tent
• realtor-123-oak-flyer
• gym-winter-offer-window-poster

The names are plain on purpose because they make reporting easier. If a counter card and a window poster use the same destination, I still create separate campaigns. Otherwise I cannot tell which print asset did the work.

Use campaign URLs when useful

Analytics needs a clean destination too

If the destination site uses Google Analytics, I often add campaign parameters to the final URL. Google's Analytics help says campaign URL parameters can identify campaigns that refer traffic, and that those values can appear in traffic acquisition reporting.

For print, I keep the parameters plain: source as the business or location, medium as qr, and campaign as the print asset. I avoid stuffing every detail into the URL because the dynamic QR campaign already has its own name and scan history.

I split the reporting work. The QR platform tells me scans. The destination analytics tells me what happened after the page opened, if the site is set up to measure it.

Read scan counts carefully

A scan is not a sale

QR tracking can answer practical print questions. The table tent may get scanned more than the counter card. A front-desk flyer may beat the mailer. An old poster may still get traffic after the new one goes up.

It cannot prove everything. One person can scan twice. Staff can test the code. A customer can scan and leave. A browser or network can fail after the scan. I use scan data to compare campaigns and spot problems, not to pretend every scan is revenue.

• Ignore the first few test scans before judging a campaign.
• Compare similar print assets over similar dates.
• Check destination analytics before calling a campaign successful.
• Keep old campaigns active if printed material is still in the world.

What I check after launch

Tracking should not break the customer path

After printing, I scan the physical code and watch the full path. The short URL should load quickly, redirect cleanly, and land on the right mobile page. If campaign parameters are used, I check that the destination URL still opens normally.

I also keep the original final URL in the campaign notes. If a tracking link ever needs to be rebuilt, I do not want to recover the destination from a printed proof or a screenshot.

For most local QR campaigns, I track the scan, keep the destination editable, use campaign URLs when the destination analytics can read them, and avoid overstating what a scan count means.