How to add UTM parameters to a QR code

The pattern

A UTM parameter is just a query-string tag your analytics reads on arrival. Append the set to the destination, then encode:

https://example.com/spring?utm_source=poster&utm_medium=qr&utm_campaign=spring26&utm_content=window

The URL generator has UTM fields built in, so you fill in four boxes rather than hand-assembling a query string (and hand-assembly is where stray spaces and ? vs & mistakes come from).

A convention that keeps the data useful

• utm_medium=qr, always. One filter then isolates every QR scan across all campaigns. This is the parameter that earns its keep.
• utm_source = the physical placement: poster, packaging, receipt, table-tent.
• utm_campaign = the campaign name you use everywhere else.
• utm_content = the individual asset, so the window poster and the counter card become comparable: this is how you learn which placement works.

You will also see teams use utm_source=qr&utm_medium=offline. It functions; the grouping is just coarser. What matters is picking one convention and never mixing them, mixed conventions split your traffic into unmergeable buckets. The reporting side of this is covered in Google Analytics with QR codes.

The density cost, in numbers

Parameters are payload, and payload is modules. Take a 26-character destination:

Encoded URL	Length	Version (EC M)	Grid
https://example.com/spring	26 chars	2	25 × 25
Same + full UTM set above	99 chars	6	41 × 41

At a printed width of 3 cm, that is the module shrinking from 1.2 mm to 0.73 mm, a 39% loss of module size for identical human-visible behaviour. Why length explodes density is explained in why longer URLs make denser codes; whether your printed size still covers the scan distance is a size calculator question.

For screens, none of this matters: pixels are free. For print, it often does.

Having both: the short-link pattern

The standard resolution is to keep the tags out of the code and in the redirect:

Code encodes:   https://example.com/p/win     (29 chars, version 2–3)
Server 302 →    https://example.com/spring?utm_source=poster&utm_medium=qr&...

The code stays low-version and print-friendly; analytics still receives the full UTM set. This is Option 2 of tracking QR scans without a paid tool, and it additionally gives you a destination you can change later. If you use a shortener instead of your own domain, read shortening before making a QR code for the dependency you are taking on.

Before printing: decode the final artwork in the validator and read the query string back character by character: UTM typos (utm_souce, duplicated ?) silently discard your attribution.

FAQ

What UTM parameters should I use for a QR code?

Set utm_medium to qr so all scans segment together, utm_source to the physical placement, utm_campaign to the campaign, and utm_content to the specific asset. Keep one convention across every code you print.

Do UTM parameters make a QR code harder to scan?

They make it denser. A full set adds 60 to 100 characters, which can raise the version by three or more and shrink every module at a fixed print size. Either print larger or move the tags behind a short redirect.

Should utm_source be qr or the placement?

Either convention works if applied consistently. Putting qr in utm_medium and the placement in utm_source preserves more information: medium filters all QR traffic, source compares placements.

Do UTM parameters change what the person scanning sees?

Normally nothing beyond a longer URL in the address bar: the parameters are read by analytics, not the page. They are visible to the user, so keep values professional; anyone can read them.