UTM Parameters + QR Codes: The Complete Guide to GA4 Attribution
A utm parameters qr codes ga4 guide — setting up the five real UTM fields on a QR code's destination, naming them so they actually make sense in GA4 months later, and what QR analytics and GA4 each tell you that the other doesn't.
Why UTM Parameters and QR Codes Are a Natural Pair
A QR code is the last mile between a physical placement and a digital destination — it gets someone from a flyer, a poster, or packaging onto a webpage. UTM parameters are what tell Google Analytics 4 why that visit happened once the person lands: which campaign, which source, which specific placement. Put together, they close the loop all the way from a printed piece of paper to a labelled, attributable session in your analytics — something neither one does on its own.
Setting Up UTM Parameters on an SMLLR QR Code
SMLLR supports the standard five UTM fields — source, medium, campaign, term, and content — applied automatically to the final destination URL whenever someone scans the code. This works across every QR type whose final output is a real URL (a plain URL, a Landing Page, a Coupon or Offer, a PDF or video link, and most social/business types), since UTM parameters are appended to that URL at redirect time. It does not apply to QR types that are always static — vCard, Plain Text, Crypto Payment, and similar types encode raw content directly rather than a URL, so there's nothing to append a parameter to.
Choosing Values That Will Actually Make Sense in GA4 Later
The most common way UTM tracking becomes useless months later is inconsistent naming — "Flyer," "flyer_mumbai," and "MumbaiFlyer" all show up as three separate sources in GA4 instead of one readable pattern. A workable convention: utm_source=qr (or a more specific source if you're distinguishing print from another QR use), utm_medium=print (or the specific channel — packaging, ooh, event), utm_campaign set to a stable campaign name used consistently across every placement in that campaign, and utm_content used specifically to distinguish placements within the same campaign (flyer-mumbai vs flyer-delhi, or standee-entrance vs standee-counter). Decide the naming pattern before the campaign launches, not after the first report looks messy.
Seeing This Data in GA4
UTM parameters alone tell GA4 where a session came from; a tracking pixel (Pro plan, ₹4,999/month, and up) is what actually fires the pageview event itself. Set up both together: the GA4 Measurement ID as a tracking pixel on the QR code, and UTM parameters on the destination URL, and GA4 will show scan-driven traffic as a clearly labelled source/medium/campaign combination alongside your other channels — comparable, for the first time, to a digital ad campaign's own reporting.
QR-Level Analytics vs GA4: What Each One Tells You That the Other Doesn't
These two are genuinely complementary rather than redundant, and worth using both for different questions:
- **SMLLR's own dashboard** shows scan counts, device and OS breakdown, and city-level location — all available immediately with zero GA4 setup required, since it's measuring the scan itself, not what happens after the page loads.
- **GA4** shows what happens *after* the landing page loads — bounce rate, session duration, and goal or conversion completions — none of which SMLLR's own scan analytics track, since that's downstream web-analytics territory rather than QR-scan territory.
- Using only one leaves a real gap: QR analytics alone can't tell you whether people who scanned actually did anything on the page, and GA4 alone (without UTM tagging) can't reliably tell you the traffic came from a physical QR code at all.
A Practical UTM Naming Template for Multi-Placement Campaigns
For a campaign running across multiple placements, a simple spreadsheet before launch pays for itself: one row per QR code, with its placement name, the utm_content value assigned to it, and the physical location it's going. This becomes the reference everyone on the team uses when setting up new codes mid-campaign, rather than each person inventing their own naming pattern on the fly — which is exactly how UTM data becomes unreadable by the time someone tries to build a report from it.
Create your QR code on SMLLR, set up UTM parameters from day one, and get a clean, comparable GA4 attribution story for every print placement.
Related Reading
Frequently Asked Questions
Which UTM parameters does SMLLR support?
All five standard fields — source, medium, campaign, term, and content — applied automatically to the destination URL whenever the code redirects.
Can I add UTM parameters to any QR code type?
Only to QR types whose final destination is a real URL — a plain URL, Landing Page, Coupon/Offer, PDF, video, or most social/business types. Always-static types like vCard, Plain Text, and Crypto Payment encode raw content directly, so there's no URL to append UTM parameters to.
What UTM naming convention should I use for a multi-placement print campaign?
Keep utm_source and utm_medium consistent (e.g. qr / print), use one stable utm_campaign name across every placement in that campaign, and use utm_content to distinguish individual placements — decide this pattern before launch, not after the data is already messy.
Do I need a tracking pixel in addition to UTM parameters?
Yes, for GA4 to actually register the pageview — UTM parameters label where the traffic came from, but a GA4 tracking pixel (Pro plan, ₹4,999/month, and up) is what fires the pageview event itself.
What does GA4 show that SMLLR's own QR analytics doesn't?
What happens after the landing page loads — bounce rate, session duration, and goal or conversion completions. SMLLR's dashboard covers the scan itself (count, device, city); GA4 covers what happens downstream on the page.
What does SMLLR's QR analytics show that GA4 alone doesn't?
Scan-level data available immediately with no GA4 setup at all — total scans, device and OS breakdown, and city-level location, none of which require the visitor to do anything beyond scanning.