UTM parameters on QR landing pages: a clean naming scheme

A lot of QR attribution setups fail for a boring reason:

the links work, but the naming does not.

A team launches poster QR codes, packaging QR codes, event QR codes, and storefront QR codes. Each one gets “some UTMs.” A month later the dashboard is full of rows like:

• spring-sale
• Spring_Sale
• springsale
• spring-sale-poster
• poster_spring_2026
• qr-offline
• offline_qr
• print-qr

At that point the problem is not tracking. It is taxonomy.

That is why UTM parameters on QR landing pages should be treated as a naming contract, not as free-form campaign copy.

The cleanest systems are not the ones with the most parameters. They are the ones whose parameters mean the same thing every time.

Why this topic matters

Teams usually hit this problem after one of these moments:

• campaign reporting is fragmented because naming drift created multiple rows for the same thing
• QR placements are measurable, but impossible to compare cleanly over time
• a dynamic QR platform adds parameters inconsistently
• marketing wants more granularity, while analytics wants fewer dimensions
• duplicate UTM keys appear in URLs and different tools interpret them differently
• or privacy and security teams push back on stuffing too much metadata into the query string

The real question is not:

• “Can we add UTMs to the QR link?”

It is:

• which URL fields should carry stable attribution meaning, and which details belong somewhere else?

That is the design problem.

Start with the cleanest principle: UTM is taxonomy, not prose

The fastest way to ruin QR reporting is to let UTM values become informal campaign descriptions.

UTMs should not be:

• whatever sounded good in the moment
• sentence fragments
• vendor-specific naming accidents
• or one-off strings that only make sense to the person who created the QR

They should be:

• stable
• documented
• constrained
• and reusable across campaigns

That means your naming guide should define:

• which parameters you use
• what each one means
• allowed value styles
• and where finer-grained variation belongs

Without that, UTM data becomes difficult to aggregate and nearly impossible to govern.

The practical baseline: source, medium, campaign, and then restraint

Google’s campaign-tagging guidance makes the basics clear: custom URLs can carry utm_source, utm_medium, utm_campaign, and optional fields such as utm_id, utm_term, and utm_content. GA4 also supports additional manual campaign fields like utm_creative_format and utm_marketing_tactic in its reporting schema. citeturn263832search6turn263832search18

That does not mean every QR link should use every parameter.

A clean baseline for most QR landing pages is:

• utm_source
• utm_medium
• utm_campaign

Then add:

• utm_content for asset or placement variation
• utm_id for a controlled internal campaign ID

Only add more if you truly need them and can govern them consistently.

The more fields you add, the easier it becomes to create accidental cardinality explosions in reports.

What each parameter should do in a QR workflow

A good naming scheme works because each field has one job.

utm_source

This should usually identify the traffic source family or distribution context.

Common examples:

• print
• packaging
• poster
• event
• storefront

Some teams prefer branded taxonomies that map to reporting systems more cleanly. That is fine. The important part is that utm_source should not drift between:

• channel
• campaign slogan
• store name
• and creative copy

Pick one meaning and keep it.

utm_medium

This should describe the marketing medium in a stable way.

For QR traffic, a lot of teams choose:

• qr
• offline
• print

Any of those can work if documented. What does not work is rotating between them without a rule.

A good convention is:

• source describes where the user encountered it
• medium describes the marketing medium class

For example:

• utm_source=poster
• utm_medium=qr

That gives you useful slices in analytics without overloading either field.

utm_campaign

This should identify the campaign concept, not every microscopic variation.

Examples:

• spring-launch-2026
• new-menu-rollout-q2
• product-box-refresh-2026

What it should usually not do:

• encode store ID, city, asset size, and print batch all at once

Campaign naming should be stable enough that all the relevant QR placements for one campaign still roll up together.

utm_content

This is often the right place for creative or placement variation.

Examples:

• poster-a3-window
• table-tent-v2
• box-side-panel
• event-badge-front

This is where you separate:

• poster versus flyer
• placement A versus placement B
• design version 1 versus version 2

That gives you detailed comparison without destroying campaign-level reporting.

utm_id

This is often underused, but it is extremely valuable for disciplined systems.

GA4’s reporting schema explicitly includes utm_id as manual campaign ID support. citeturn263832search6

That makes utm_id a strong place for:

• internal numeric or slug campaign IDs
• a stable system identifier that survives campaign-name changes
• integration with planning sheets or BI models

A useful pattern is:

• human-readable utm_campaign
• system-stable utm_id

That gives analysts something nice to read and engineers something stable to join on.

The cleanest QR pattern: first-party redirect plus controlled UTMs

The strongest QR attribution systems usually do not print the final long marketing URL directly.

A safer pattern is:

1. QR points to a short first-party URL you control
2. that redirect layer knows the campaign, asset, or placement
3. it forwards to the landing page with a clean, governed set of UTMs
4. destination analytics and conversion tracking happen downstream

Why this is better:

• you control the URL contract
• you can fix naming policy centrally
• you avoid reprinting when destinations change
• and you reduce the temptation to stuff too much metadata into the QR payload itself

This also makes it easier to keep:

• original landing URL
• canonical destination
• and analytics-preserving URL separate in your own systems

Keep the naming scheme small enough to remember

A naming convention that requires a four-page cheat sheet to create one QR link will fail in practice.

A strong scheme is usually:

• small
• memorable
• constrained
• enforced in tooling

For example:

Source vocabulary

• poster
• packaging
• menu
• storefront
• event

Medium vocabulary

• qr

Campaign vocabulary

• lowercase kebab-case
• date or season only if it matters
• one stable campaign slug

Content vocabulary

• placement plus creative variant
• e.g. window-a, table-v2, front-label

That is enough structure to produce consistent data without slowing teams down too much.

Query-string cleanliness matters more for QR than people think

QR workflows amplify URL-design mistakes because the URL itself is often:

• printed
• copied
• forwarded
• scanned by many devices
• and logged in several systems

RFC 3986 defines the syntax and semantics of URI components, including the query component, but it also makes clear that application semantics govern how much of that query string is actually meaningful for your use case. citeturn263832search1turn263832search19

That means your QR attribution design needs a policy for:

• which parameters are allowed
• whether duplicates are allowed
• whether parameter order matters
• which parameters are purely for attribution
• and which values must never appear in the URL at all

Do not let the query string become a dumping ground for every campaign detail.

Duplicate UTM parameters are a real reporting hazard

Query strings can contain duplicate keys. The web platform allows this. MDN’s URLSearchParams.getAll() explicitly exists because multiple values can be associated with the same parameter name. append() adds additional values, and set() replaces existing ones. sort() only sorts by key and preserves the order of duplicate keys because it uses a stable sort. citeturn263832search2turn263832search8turn263832search17turn263832search5

That is not just an implementation detail. It matters for analytics.

Google’s own help community response for GA4 says that when duplicate UTM parameters appear, GA4 will typically use the last value present in the query string. citeturn263832search0

That means this can create silent reporting surprises:

• two utm_campaign values in one URL
• one team thinks the first will win
• the analytics tool uses the last
• reports no longer match expectations

The cleanest rule is: do not allow duplicate UTM keys in production QR URLs.

Prevent them in your generator or redirect layer instead of trying to interpret them later.

Parameter order should not carry business meaning

A good naming scheme should not depend on whether:

• utm_source comes before utm_medium
• or utm_campaign comes last

That is because parameter order is fragile and easy to rewrite in tools. MDN documents URLSearchParams.sort() precisely because deterministic ordering is often useful for canonicalization and comparison. citeturn263832search5

So a practical rule is:

• parameter order should be normalized for comparison keys
• but business meaning should live in parameter values, not their order

If order changes your interpretation, the scheme is too brittle.

Keep attribution and destination identity separate

This is one of the highest-leverage design decisions.

A landing page has at least two useful URL forms:

Canonical destination URL

The clean page location without campaign-specific query noise.

Analytics-preserving landing URL

The actual URL that carries the UTM parameters for attribution.

These should be treated separately in systems and reporting.

Why? Because the same landing page may be reached by:

• multiple campaigns
• multiple QR placements
• multiple media types

If you dedupe purely on the full UTM-bearing URL, you may mistake one destination for many distinct pages. If you strip UTMs too early, you lose attribution.

So the safe model is:

• preserve the original scanned or redirected URL
• derive a canonical destination URL for page-level grouping
• keep attribution dimensions separately

That keeps reporting cleaner.

Do not put sensitive data in QR URLs

This is not only a security point. It is also a cleanliness point.

OWASP’s guidance on query-string exposure says sensitive information in URLs can leak through logs, browser history, referrers, and other systems even when HTTPS is used. citeturn263832search4

That means QR URLs should not include:

• email addresses
• personal identifiers
• auth tokens
• one-time secrets
• or anything you would not want copied into logs and screenshots

If you need audience-specific routing, do it through a server-side identifier design with explicit privacy review, not by casually encoding personal data into UTMs or other query parameters.

A practical naming model that works

For many teams, this is enough:

Example

https://brand.example/r/menu-spring?utm_source=menu&utm_medium=qr&utm_campaign=spring-launch-2026&utm_content=table-tent-v2&utm_id=cmp-2026-041

This gives you:

• source = where it was encountered
• medium = qr
• campaign = the shared campaign rollup
• content = the asset or placement variant
• id = stable system key

That is much cleaner than:

• inventing a new utm_campaign for every poster
• or cramming placement data into utm_source

Naming rules that reduce reporting drift

A strong style guide usually includes rules like:

• lowercase only
• use hyphens, not spaces
• no punctuation beyond hyphens and digits unless explicitly allowed
• no dates unless they are part of the campaign identity
• do not abbreviate unless the abbreviation is documented
• keep values stable across reports, redirects, and BI models
• do not reuse the same campaign slug for unrelated initiatives

These rules sound small. They do a lot of work in practice.

They are what keep one campaign from becoming six near-duplicate rows in a dashboard.

A practical workflow

Use this when designing QR UTM conventions.

1. Define what each UTM field means

Do this before building links. One field, one job.

2. Choose a limited vocabulary

Especially for:

• utm_source
• utm_medium

3. Keep campaign names human-readable but stable

Use utm_campaign for the campaign concept, not for every tiny variation.

4. Move finer detail to utm_content or utm_id

Do not overload campaign with placement detail.

5. Use a first-party redirect layer

This lets you enforce the naming scheme centrally.

6. Reject duplicate UTM keys

Do not rely on downstream tool-specific behavior.

7. Preserve canonical destination separately

Keep attribution and destination identity distinct.

That workflow produces much cleaner analytics than “just add some UTMs.”

Good examples

Example 1: restaurant menu QR

Good:

• utm_source=menu
• utm_medium=qr
• utm_campaign=spring-menu-refresh-2026
• utm_content=table-tent-v2

This rolls up all menu-refresh assets while still distinguishing the table-tent variation.

Example 2: packaging QR

Good:

• utm_source=packaging
• utm_medium=qr
• utm_campaign=summer-product-launch-2026
• utm_content=box-side-panel

This keeps the campaign stable and lets packaging placements be compared cleanly.

Example 3: bad naming drift

Bad:

• utm_campaign=summer
• utm_campaign=summer_launch
• utm_campaign=SummerLaunch2026
• utm_campaign=qr_summer_box

These values are too inconsistent to aggregate cleanly without cleanup.

Common anti-patterns

Anti-pattern 1: letting each team invent its own medium

Then one report mixes:

• qr
• offline
• print
• scan for the same type of traffic.

Anti-pattern 2: encoding every placement detail in utm_campaign

Campaign rollups become fragmented and unreadable.

Anti-pattern 3: allowing duplicate UTM keys

Different tools may interpret them differently, and GA4 commonly uses the last value. citeturn263832search0turn263832search2

Anti-pattern 4: putting sensitive data in query strings

This creates avoidable privacy and logging risk. citeturn263832search4

Anti-pattern 5: treating UTMs as the only source of truth

A first-party redirect model with controlled metadata is often more durable than relying on raw URL strings alone.

Which Elysiate tools fit this topic naturally?

The most natural related tools are:

• Free QR Code Generator
• QR Code Generator SVG

They fit because clean UTM naming starts at the QR creation stage. If the destination strategy and parameter policy are sloppy before the code is generated, reporting gets messy later.

Why this page can rank broadly

To support broader search coverage, this page is intentionally shaped around several connected query families:

Core UTM intent

• utm parameters on qr landing pages
• qr code utm naming scheme
• how to name utm campaign for qr

Attribution architecture intent

• first party qr redirect utm
• qr landing page attribution
• canonical url vs utm url

Analytics hygiene intent

• duplicate utm parameters
• clean campaign naming convention
• privacy safe qr tracking parameters

That breadth helps one page rank for much more than the literal title.

FAQ

What should utm_source be for a QR code?

Usually the source should identify the source family or distribution context, such as poster, packaging, menu, or another documented source taxonomy.

What should utm_medium be?

Use a stable value such as qr, offline, or print, but keep it consistent across campaigns.

Should every QR placement get its own utm_campaign?

Usually no. Campaign should identify the campaign concept, while placement detail is better handled with utm_content, utm_id, or first-party redirect metadata.

Can duplicate UTM parameters break reporting?

Yes. Query strings can hold duplicate keys, and different tools may resolve them differently. Prevent duplicates rather than relying on parser behavior.

Should I strip UTMs when canonicalizing landing pages?

Only in a derived comparison or destination key. Keep attribution separately so you do not destroy campaign reporting.

What is the safest default mindset?

Make UTM values boring, consistent, and governed. The cleaner the naming contract, the more useful the reporting becomes.

Final takeaway

UTM parameters on QR landing pages work best when they are treated like a schema, not like ad hoc campaign copy.

The safest baseline is:

• give each UTM field one clear job
• keep source and medium vocabularies small
• use campaign for rollups, not placement clutter
• use content or IDs for finer variation
• reject duplicate UTM keys
• preserve canonical destination separately from attribution
• and enforce the scheme through a first-party redirect layer whenever possible

That is how QR attribution stays clean enough to trust six months later, not only on launch day.