How I track a QR campaign without making the printed code fragile

QR campaign tracking is not just putting a QR code on a poster and hoping analytics catches it. I want to know which printed piece drove the scan, but I also want the printed code to stay simple enough to scan.

My default setup is a dynamic QR code that points to a short campaign URL. The dashboard counts scans, and the final destination can still use normal campaign parameters for Google Analytics or another analytics tool.

Start with the campaign question

Track the decision you can act on

I decide what I need to compare before generating codes. A restaurant might compare table tents against window signs, while a clinic compares reception cards against appointment reminders. For a retail shop, shelf labels and package inserts may need separate codes.

That decides how many QR codes I need. If every placement uses the same code, I can measure the campaign as a whole. If each placement gets its own code, I can compare placements. I do not create twenty codes unless someone will use the extra data.

Use campaign parameters carefully

Keep the URL naming boring and consistent

Google Analytics supports campaign parameters such as utm_source, utm_medium, utm_campaign, utm_term, and utm_content. Google also notes that parameter values are case sensitive, so SpringSale and springsale can split into different rows.

For print, I usually keep the values plain: utm_source=qr, utm_medium=print, utm_campaign=summer_menu, and utm_content=table_tent or window_sign. The exact names matter less than keeping them consistent across every printed asset.

I avoid putting a long tagged URL directly into the QR symbol when the campaign will be printed at small sizes. More characters can push the QR code into a larger version with more modules. The printed square gets denser, and small print becomes less forgiving.

Use a dynamic layer for print

The printed code should survive normal changes

A dynamic QR campaign gives me two useful pieces: scan data at the QR layer and an editable destination. If the landing page changes, the booking link moves, or the menu PDF gets replaced, I can update the destination without reprinting the code.

This is also where I keep placement names. One campaign can be called front-counter-card. Another can be called receipt-footer. When the scans come in, I do not need to guess which printed file created the traffic.

For a simple one-off flyer, a static QR code can be fine. For anything that will sit in a window, go on packaging, or get printed in bulk, I prefer the dynamic layer because fixing a destination later is cheaper than reprinting.

Check the scan before the full run

The proof has to test both code and analytics

• Scan the proof from the real distance and angle.
• Confirm the landing page opens on mobile data.
• Check that the dynamic campaign recorded the scan.
• Check that the final URL keeps the expected campaign parameters.
• Save the QR image, destination URL, campaign name, and print file together.

I also keep the quiet zone clean. DENSO WAVE describes the quiet zone as the clear margin around the symbol and says a QR code needs a four-module margin on every side. Cropping that space to make a design tighter is a common way to break a printed proof.

Once the proof works, the campaign is ready for a small run. I still check the first real scans after launch because print placement changes behavior. A code that works on my desk might perform differently on a glossy window, a curved package, or a receipt.

Good QR campaign tracking gives me one clear answer: which printed asset drove the scan. The setup should stay simple enough that the printed code still scans and the reporting names still make sense a month later.