UTM tags for QR: so there is something to read in the report later

A QR code has no idea where it is

Two numbers get mixed up constantly. Your dashboard counts scans: a camera read the code and a browser opened. Web analytics counts sessions: the page loaded and something happened on it. Both are real, and they are never equal.

The gap is where the useful information sits. A scan the person cancelled, a scan on a phone with no signal, a scan that lands on a dead page — all of those live in one number and not the other. And when a scan does turn into a session, the destination sees a visitor with no referrer at all. It looks exactly like someone typing the address by hand.

UTM tags are how you break that silence. They are not decoration and they are not a formality: without them, ten campaigns and one campaign produce the same report.

The fields, and the ones you will actually use

The classic set is source, medium and campaign. Source is where the code physically sits. Medium is what kind of object carries it. Campaign is the reason it exists at all. A fourth field, content, separates two designs of the same campaign.

Concretely, for a menu code on the counter of a café: source till, medium print, campaign spring-menu, content a5-card. If a scan arrives with all four, you know the object, the spot, the promotion and the artwork — before you have opened a single chart.

One code per placement, not per poster

Print two hundred identical stickers and the report will say: two hundred stickers. That is a true statement and a useless one. Run a separate code for each spot instead — the entrance, the till, the restroom door, the table by the window.

A separate code costs nothing. A merged one costs a year of guessing, and by the time you want to split it, the print run is finished and the stickers are on the wall.

A naming scheme you can still read in six months

Write the rules down once, put them where the team can find them, and follow them without exceptions: lowercase only, hyphens instead of spaces, no accents, no dates in the value.

Dates deserve their own sentence. If the campaign value is spring-menu-2026, you cannot count what that menu did over its whole life, and next spring you will create a second row that means the same thing. Keep the date in a spreadsheet column, not in the URL.

The argument you will have in month two

Both numbers are correct, and neither is the campaign. Scans measure the object; sessions measure the page. If you report one, say which one. The pair is the honest answer, and the difference between them is the most interesting thing you will learn about your print.

Static or dynamic decides where the tags live

For one poster and one fixed destination, a static code is simpler and entirely sufficient. Dynamic earns its keep the moment you print more than one object, or the destination might change, or you want to know how many people read the code — not only how many stayed.

What analytics will show, and what it never will

Most analytics tools have no built-in channel for printed codes. utm_medium=print usually lands under Unassigned or Referral until you define a custom channel group — worth ten minutes, because otherwise your best-performing print piece looks like noise.

Two things stay invisible regardless. A scan where the person closed the browser before the page rendered never becomes a session, and no tag can record it. And the code cannot tell you the person scanned, read the offer, and decided not to click — the dashboard knows a scan happened and nothing beyond it.

Keep personal data out of the URL

A tagged URL is a public object. It sits in browser history, gets forwarded in chats, appears in screenshots and in the referrer of every asset the page loads. Treat it as something a stranger may read.

That rules out email addresses, phone numbers, order numbers and staff names. Table 12 is fine; a guest's surname in the source field is a data-protection problem with a very short path to a complaint.

Check the tags survive the round trip

A printed proof is not the URL. Decode the actual code on the actual sheet, then follow the redirect and look at the address bar of the landing page. If the tags are not there, the campaign is already broken and you have not spent the print budget yet.

The usual culprit is an intermediate redirect that strips the query string, or a destination page that immediately rewrites the URL. Both are cheap to fix before printing and expensive to explain after.

How to build it in practice

In the QR generator, paste the destination URL with the tags already attached, or create a dynamic code and put the tags on its target. Pick the type that matches the code you actually ordered, generate the file, and keep the full tagged URL next to the design file so the next person can see what was printed.

The QR Studio is where the two versions of a campaign usually appear — a card and a poster, same offer, different artwork. Give each one its own content value there, otherwise the difference between them disappears from the report on day one.

Then run the QR scanner over the first printed proof. It shows the decoded URL in full, tags included, so you catch a typo or a stripped parameter on paper in your hand instead of on a wall you cannot reach.

Mistakes that quietly ruin the report

• The same code on every placement in a print run.
• Uppercase and lowercase versions of one source value.
• A date inside the campaign name.
• Tags added on the short link instead of on the destination.
• Nobody wrote the naming rules down, so two people invented two systems.
• The printed proof was never decoded and the redirect strips the parameters.