Why your QR scans show as Unassigned in GA4

Unassigned in GA4 is not an error and it is not lost traffic. It means the session arrived and was recorded, GA4 tried to file it under one of its default channel groups, and none of the rules matched. Every session is still there. They are sitting in a bucket that means we could not classify this, and the report gives you no hint about why.

QR scans land in that bucket for one specific reason. The default channel grouping is a list of rules that read utm_source and utm_medium and look for values Google recognises: organic, cpc, email, referral, affiliate, sms, audio and a handful more. There is no rule for qr. So utm_medium=qr is a perfectly valid tag that matches nothing, and a perfectly valid tag that matches nothing is Unassigned. Nothing is broken. The tag simply is not on Google's list.

There is a second failure that people confuse with this one, and telling them apart saves an afternoon. A scan with no UTM tags at all usually reports as Direct, because a phone camera opening a URL sends no referrer. Direct and Unassigned mean opposite things. Direct means GA4 had nothing to work with. Unassigned means GA4 had something and did not recognise it. If your QR traffic is sitting in Direct, the tags are missing or are being stripped somewhere. If it is sitting in Unassigned, the tags arrived and the medium is unrecognised. Check which one you have before changing anything.

From there, two ways out, and they are a genuine trade-off rather than a right and a wrong answer.

The first is to use a medium GA4 already recognises. The default rules key on a fixed set of values, and for a printed campaign the usual choice is referral. Your scans then land in a named channel from day one, at the cost of being mixed in with everything else that arrives as a referral. Read Google's current default channel definitions before committing to a value, because the list belongs to them and it has changed before.

The second is to keep utm_medium=qr, which is accurate and specific, and define a custom channel group in GA4 with a rule that catches it. You then get a channel that means what it says, and QR is separated from web referrals in every report that uses channel groupings. Decide this before a campaign rather than after it: whether a new group reaches data already collected is a property of your setup, and finding out after the fact is not a pleasant way to learn.

If you would rather see what GA4 will do with a set of tags before committing them to print, the builder at /tools/utm-builder warns about exactly this and stores nothing.

Whichever route you take, one detail causes more mess than the channel question does. GA4 does not normalise case. Spring and spring are two campaigns, two rows and two sets of numbers, and nothing anywhere warns you. Online this is annoying. On a printed campaign it is expensive, because the tag lives in the redirect rather than in a link somebody can quietly edit, and by the time the split shows up in a report the posters are already on walls. Lowercase everything, decide the convention once, and check it before the print run.

Consistency across surfaces matters for the same reason. A flyer, a window decal and a poster belonging to one campaign should share a campaign name and differ only in utm_content or utm_source. Then the report can answer both questions you will actually ask: whether the campaign worked, and which surface produced the scans. Giving each surface its own campaign name answers neither question well, and it cannot be repaired later without editing history.

GA4 reads nine UTM parameters: utm_source, utm_medium, utm_campaign, utm_id, utm_term, utm_content, utm_source_platform, utm_creative_format and utm_marketing_tactic. A print campaign needs three or four. Source, medium and campaign decide how a session is filed. Content is what separates the flyer from the decal. The remaining five exist for paid platforms that populate them automatically, and adding them by hand mostly adds columns nobody reads.

There is one structural point that is specific to QR rather than to analytics in general. If the UTM tags are encoded into the printed image, then fixing a wrong medium means reprinting. If the printed image encodes a short link and the tags are appended at the moment the redirect happens, a wrong medium is an edit that takes seconds and every code already in the world is corrected at once. That is the practical argument for a dynamic code even when the destination itself will never change: the tagging is the part most likely to be wrong on the first attempt.

To check whether any of this is working, do not wait for tomorrow's reports. Scan your own code with a phone and open the realtime report, then look at session source and session medium. It shows up within a minute or so. If it reports the medium you set, the tagging survived the redirect and the only remaining question is which channel group it falls into, which is a configuration decision you now get to make deliberately. If it reports direct or none, the tags are not arriving at all, and that is a different problem that no channel grouping will fix.