UTM-parameters op QR-codes: waarom scans in GA4 als Direct verdwijnen

Druk honderd flyers voor tien klanten, zet op elke flyer een QR-code, en na de lanceerweek laten je GA4-rapporten voor bijna allemaal hetzelfde zien: een piek in Direct-verkeer. Geen bron, geen medium, geen campagne. Gewoon een stapel sessies zonder attributie die net zo goed van de QR-code kunnen komen als van iemand die de URL uit het hoofd intypte, of van iets heel anders. De scan gebeurde wel. De attributie niet.

De oplossing is UTM-parameters, en de meeste uitleg daarover stopt bij "voeg wat tags toe aan je URL." Dat is prima advies voor één marketeer die één campagne draait. Het houdt geen stand zodra een bureau dit tegelijk voor een tiental klanten doet, want het probleem is niet "we zijn vergeten de link te taggen." Het is "iedereen heeft zijn links net iets anders getagd," en dat is stiekem erger: de rapporten zien er compleet uit, maar Facebook, facebook en Instore-QR zijn drie verschillende rijen in drie verschillende klantdashboards, en niemand merkt het tot een kwartaalrapport de kloof moet verklaren.

Dit artikel behandelt wat UTM-parameters precies doen, waarom een gescande QR-code zonder deze parameters standaard als Direct wordt geregistreerd, een naamconventie die is gebouwd om meerdere klanten te overleven in plaats van één campagne, en een QR-specifiek probleem waar bijna niemand over schrijft: een UTM-string maakt je URL langer, en een langere URL maakt je QR-code dichter. Voorbij een bepaald punt begint die afweging tegen je te werken, en wel precies in de printomstandigheden waar bureaus op vertrouwen: kleine flyers, gelamineerde tafelstandaards, laagwaardig krantenpapier.

Wat UTM-parameters precies zijn

UTM-parameters zijn vijf specifieke query-string velden die aan een URL worden toegevoegd en een analyseplatform vertellen waar een bezoek vandaan kwam. Google's eigen documentatie is expliciet dat er in de praktijk maar drie verplicht zijn: utm_source (waar het verkeer vandaan komt, bijvoorbeeld flyer of google), utm_medium (het marketingkanaal, bijvoorbeeld qr of email), en utm_campaign (het specifieke initiatief, bijvoorbeeld spring-menu-launch). Twee andere zijn optioneel en situationeel: utm_term, vooral gebruikt voor zoekwoorden bij betaald zoeken, en utm_content, gebruikt om varianten van elkaar te onderscheiden, zoals twee QR-plaatsingen op dezelfde poster.

Laat je een verplicht veld leeg, dan gokt GA4 niet. Het rapporteert de waarde als (not set), wat functioneel hetzelfde probleem is als helemaal geen tag: een sessie die je wel ziet, maar niet kunt verklaren.

Eén detail dat meer schade aanricht dan je zou verwachten: UTM-waarden zijn hoofdlettergevoelig. Google's eigen helpdocumentatie stelt dit expliciet en raadt kleine letters aan als standaardpraktijk. utm_source=Instagram en utm_source=instagram zijn voor GA4 niet dezelfde waarde. Ze worden twee aparte rijen in elk rapport, waardoor het verkeer van één kanaal in tweeën wordt gesplitst om geen andere reden dan dat iemand een hoofdletter typte. Dit is geen bug die je kunt wegconfigureren. Zo is het platform gebouwd, en de enige echte verdediging is een naamconventie die wordt afgedwongen voordat links live gaan, niet achteraf opgeschoond.

Er is geen officiële maximumlengte voor een UTM-waarde, maar er is wel een praktische grens die je moet kennen: GA4 begrenst de meeste event-parameterwaarden op 100 tekens, waardoor een te beschrijvende utm_campaign-string in rapportages stilletjes kan worden afgekapt. Houd waarden kort en gestructureerd in plaats van beschrijvende zinnen.

Waarom een gescande QR-code als Direct verschijnt

Een QR-code opent een link niet zoals een klik in een browser dat doet. Er is geen verwijzende pagina, dus er is geen HTTP-referrerheader die GA4 kan uitlezen. Google's documentatie over Direct-verkeer is specifiek over het mechanisme: een sessie wordt geclassificeerd als (direct) / (none) wanneer GA4 geen UTM-parameters vindt, geen herkende advertentie-click-ID, en geen referrer die het aan een bekende bron kan koppelen. Een getypte URL, een link uit een PDF en een gescande QR-code komen allemaal in exact dezelfde categorie terecht, om exact dezelfde reden: niets in het verzoek vertelt GA4 waar de bezoeker vandaan kwam.

Dat is het hele verhaal. Het is geen QR-specifieke bug, en het is niets wat een QR-platform namens jou kan oplossen, want de ontbrekende informatie (bron, medium, campagne) werd om te beginnen nooit in het verzoek gecodeerd. De oplossing moet op URL-niveau plaatsvinden, voordat de code wordt gegenereerd. Voor de volledige uitleg om dit correct in te richten in GA4, zie QR-codescans bijhouden in Google Analytics 4.

Het is de moeite waard om dit apart te noemen, want ook ervaren teams trappen erin: een redirect die onderweg query-parameters verwijdert (een https-naar-http-redirect, of een URL-verkorter die ze niet doorgeeft) laat je UTM-tags vallen, zelfs als je de link correct hebt opgebouwd. Als het Direct-verkeer van een klant onverklaarbaar hoog lijkt, controleer dan de volledige redirect-keten die de scan daadwerkelijk doorloopt, niet alleen de URL die op de QR-code staat.

Een naamconventie die meer dan één klant overleeft

De meeste UTM-adviezen gaan ervan uit dat één persoon één set campagnes beheert, dus "wees gewoon consistent" volstaat dan. Een bureau heeft iets nodig dat meer op een schema lijkt: vaste regels die een junior teamlid op zijn eerste dag correct kan volgen, zonder een beslissing waarbij iets fout kan gaan.

Een structuur die standhoudt op bureauschaal:

• utm_source, de fysieke of digitale plaatsing, niet de klant. Gebruik flyer, poster, business-card, menu, email-signature, packaging. Dit is het meest bruikbare veld om te beantwoorden "welke plaatsing levert daadwerkelijk scans op," en het is het veld dat de meeste naamconventies te vaag laten om nuttig te zijn.
• utm_medium, vastgezet op qr voor elke link die van een QR-code afkomstig is, bij elke klant, zonder uitzondering. Hierdoor kun je "alle QR-prestaties" binnen je hele bureau in één rapport filteren, in plaats van het per klant opnieuw te reconstrueren.
• utm_campaign, een gestructureerd patroon, geen vrije tekst. Iets als client-campaign-yyyymm, bijvoorbeeld northside-cafe-summer-menu-202607. Het datumsuffix is belangrijker dan het lijkt: het voorkomt dat een terugkerende seizoenscampagne stilletjes de data van vorig jaar overschrijft onder dezelfde campagnenaam.
• utm_content, gereserveerd voor echte varianten van dezelfde plaatsing, meestal A/B-tests. Twee QR-codes op dezelfde poster die "Scan voor 10% korting" testen tegen "Scan om het menu te zien" krijgen identieke source, medium en campaign, en verschillen alleen in content, zoals content=offer-a versus content=offer-b. Dat is wat de A/B-splitsing zichtbaar maakt in één rapport in plaats van twee aparte rapporten die je handmatig moet samenvoegen. Zie zo A/B-test je een QR-codecampagne voor de volledige testopzet waar dit in past.

De regel die dit daadwerkelijk afdwingt, meer dan welk naampatroon dan ook, is governance: één gedeelde, zichtbare single source of truth voor elke getagde link bij elke klant, en één afgedwongen hoofdletterconventie (altijd kleine letters) in plaats van vertrouwen op het geheugen. Als je bureau codes al organiseert in een workspace per klant, is die structuur een logische plek om ook de taxonomie te standaardiseren, want dezelfde grens die klantdata scheidt, moet ook hun utm_campaign-waarden scheiden. Zie één workspace per klant voor hoe die scheiding in de praktijk werkt.

Het QR-specifieke probleem: UTM-lengte versus scanbetrouwbaarheid

Dit is het deel dat bijna geen enkele UTM-gids vermeldt, omdat bijna geen enkele UTM-gids is geschreven door iemand die de resulterende code ook daadwerkelijk moet laten drukken.

Een QR-code kan tekst in een paar verschillende modi coderen, en die modus is belangrijk omdat elke modus data met een andere dichtheid inpakt. De meest efficiënte is numerieke modus, dan alfanumerieke modus, die een tekenset van 45 tekens ondersteunt: cijfers, hoofdletters, spatie en een handvol symbolen ($ % * + - . / :). Een getagde URL kan geen alfanumerieke modus gebruiken. Hij bevat kleine letters, plus ?, &, = en _, die allemaal buiten die tekenset van 45 tekens vallen. Dat dwingt de encoder in bytemodus, die per teken beduidend minder ruimte-efficiënt is dan alfanumerieke modus. Met andere woorden: zodra je UTM-parameters toevoegt, heb je je QR-code al dichter gemaakt dan het kale domein nodig zou hebben gehad, nog voordat je een enkel teken trackingdata hebt toegevoegd.

Vanaf daar geldt: meer tekens betekent een hogere QR-versie, en een hogere versie betekent een dichter rooster van modules dat in dezelfde afdrukgrootte wordt geperst. De capaciteitstabel (bytemodus, wat een UTM-URL gebruikt) maakt die sprong concreet:

• Versie 1 (21x21 modules): 17 tekens bij foutcorrectie L, tot 7 bij H.
• Versie 3 (29x29 modules): 53 tekens bij L, tot 24 bij H.
• Versie 5 (37x37 modules): 106 tekens bij L, tot 44 bij H.
• Versie 7 (45x45 modules): 154 tekens bij L, tot 64 bij H.
• Versie 10 (57x57 modules): 271 tekens bij L, tot 119 bij H.

Een kaal, kort domein past comfortabel in Versie 1 of 2. Een realistische, met UTM getagde URL, met source, medium, campaign en een datumsuffix, komt doorgaans uit op zo'n 90 tot 110 tekens zodra het domein is meegeteld, wat je rond Versie 7 of 8 uitkomt bij een gemiddeld foutcorrectieniveau. Dat is zichtbaar meer modules die in hetzelfde fysieke vierkant worden gepropt, wat kleinere individuele modules betekent als de afdrukgrootte gelijk blijft, wat weer minder tolerantie betekent voor een goedkope printer, een iets zachte scherpstelling, of glans van laminaat.

Foutcorrectie voegt een tweede, gerelateerde afweging toe. Denso Wave's eigen cijfers stellen de herstelbare data op ongeveer 7% voor niveau L, 15% voor M, 25% voor Q en 30% voor H. Hogere niveaus overleven meer printschade en scannen onder een hoek beter, maar bij een vaste versie bevatten ze minder data, en bij een vast aantal tekens duwen ze je juist naar een hogere, dichtere versie. Er is geen instelling die je zowel maximaal herstel als maximale capaciteit geeft in een kleine code; je wisselt altijd het een tegen het ander in. Voor de volledige uitleg van wanneer je welk niveau gebruikt, zie QR-code foutcorrectie: wat L, M, Q en H precies betekenen.

De praktische oplossing, en de reden waarom dit probleem beter te beheersen is dan het in eerste instantie lijkt, is dat je de volledige getagde URL helemaal niet in de afgedrukte QR-code hoeft te coderen. Een dynamische QR-code codeert een korte redirect-URL, die op Versie 1 of 2 blijft ongeacht hoe uitgebreid de UTM-string van de bestemming wordt, en de redirect zelf brengt de bezoeker server-side door naar de volledig getagde bestemming. De QR-code blijft klein en drukvriendelijk; de analytics blijven volledig getagd. Dit is een van de duidelijkere praktische argumenten voor dynamische boven statische QR-codes, specifiek voor bureaus die UTM-zware campagnes draaien, naast het vaker aangehaalde argument dat je een link na het drukken nog kunt aanpassen. Voor de bredere vergelijking, zie dynamische versus statische QR-codes.

De link bouwen zonder de scan te breken

Een praktische volgorde die zowel de tracking als de drukkwaliteit intact houdt:

1. Bouw eerst de volledig getagde bestemmings-URL, met je afgesproken naamconventie. Google's eigen Campaign URL Builder is hiervoor het standaardhulpmiddel en voorkomt typefouten in parameternamen, en die tellen: utm_medium verkeerd gespeld als utm_meduim is onzichtbaar voor GA4 en levert simpelweg geen attributie op.
2. Wijs een dynamische QR-code naar die getagde URL in plaats van de getagde URL rechtstreeks te coderen. De afgedrukte code hoeft dan alleen een korte redirect te bevatten, waardoor hij op een lage versie blijft, ongeacht hoe lang de bestemmings-URL is.
3. Kies de foutcorrectie op basis van de printomgeving, niet standaard. Een code die op een schone, goed verlichte plek komt te staan, zoals een tafelstandaard op een toonbank, kan veilig L of M gebruiken. Een code die op een buitenposter, een verzendlabel, of ergens komt waar hij vuil of schade kan oplopen, is de capaciteitskosten van Q of H waard.
4. Test de daadwerkelijke afdrukgrootte voordat je de volledige oplage drukt. Scan hem vanaf een normale telefoonafstand, in het licht dat de uiteindelijke locatie daadwerkelijk heeft, niet op een monitor.

Veelgemaakte fouten die de attributie stilletjes breken

Een handvol specifieke faalpatronen komt vaak genoeg voor om direct te benoemen, want elk ervan ziet eruit als een werkende opzet, tot iemand probeert de cijfers te herleiden.

Inconsistent hoofdlettergebruik is de meest voorkomende fout en het makkelijkst te voorkomen. Flyer, flyer en FLYER zijn voor GA4 drie verschillende waarden, geen één. De enige echte oplossing is kleine letters afdwingen voordat een link live gaat, niet nadat een rapport er verkeerd uitziet.

Interne links taggen is een aparte, minder voor de hand liggende fout met dezelfde onderliggende oorzaak: UTM-parameters toevoegen aan een link tussen twee pagina's op je eigen site overschrijft de oorspronkelijke sessiebron van de bezoeker met "je eigen site" als referrer, waardoor conversies onterecht worden toegeschreven aan een intern kanaal dat in werkelijkheid niemand heeft aangebracht. UTM-parameters horen thuis op links die een kanaal verlaten dat je niet zelf beheert (een gedrukte flyer, een e-mail, een site van een derde partij), nooit op interne navigatie.

Redirect-ketens die query-parameters laten vallen, wissen UTM-data stilletjes halverwege de reis, en dat is waarom de QR-code, de redirect en de uiteindelijke landingspagina samen gecontroleerd moeten worden, niet alleen de code zelf.

En de duurste fout van allemaal is drukken voordat je test: vijfduizend flyers met een ongetagde, verkeerd getypte of dode QR-code is geen rapportageprobleem, het is een herdrukrekening. Een dynamische QR-code beperkt die fout in elk geval, omdat de bestemming nog gecorrigeerd kan worden nadat de drukoplage al is uitgeleverd; zie de bestemming van een QR-code wijzigen zonder herdruk voor hoe dat herstel werkt als het jou overkomt.

Zodra de tagging consistent is, is de data die het oplevert alleen nuttig als je weet wat je ermee moet doen. Zie QR-code-analytics: welke scanstatistieken ertoe doen om getagde scandata om te zetten in iets bruikbaars voor een klantrapport, en zo bereken je de ROI van een QR-codecampagne om die attributie door te trekken naar een getal waar een klant om geeft.

Veelgestelde vragen

Wat is een QR-code met UTM-tags?

Het is een standaard QR-code die een URL codeert met UTM-parameters (source, medium, campaign en optioneel term en content) in de query-string, zodat wanneer iemand hem scant en op de bestemming landt, een analyseplatform zoals GA4 de resulterende sessie kan toeschrijven aan die specifieke plaatsing in plaats van deze te registreren als niet-toegeschreven Direct-verkeer.

Waarom laat GA4 QR-codescans zien als Direct-verkeer?

Omdat een gescande QR-code geen HTTP-referrer heeft, net als een getypte URL. Zonder UTM-parameters in de bestemmingslink heeft GA4 niets om de sessie aan toe te schrijven, dus valt het terug op de classificatie (direct) / (none), ongeacht hoe de bezoeker daadwerkelijk is aangekomen.

Wat zijn de vijf UTM-parameters?

utm_source, utm_medium en utm_campaign zijn de drie die Google aanraadt te gebruiken op vrijwel elke getagde link. utm_term en utm_content zijn optioneel, gebruikt voor respectievelijk zoekwoorden bij betaald zoeken en voor het onderscheiden van varianten van dezelfde link, zoals bij een A/B-test.

Moet utm_medium "qr", "qr-code" of "print" zijn?

Kies één exacte waarde en gebruik die voor elke link die van een QR-code afkomstig is, bij elke klant, zonder uitzondering. De meeste bureaus standaardiseren op qr, omdat het ondubbelzinnig is en je "alle QR-prestaties" in één query kunt filteren. print is te breed, want dat vangt ook niet-QR-printkanalen op en voegt data samen die gescheiden zou moeten blijven.

Zijn UTM-parameters hoofdlettergevoelig in GA4?

Ja. Dit staat rechtstreeks in Google's documentatie, het is geen aanname. utm_source=Google en utm_source=google worden behandeld als twee verschillende waarden en verschijnen als aparte rijen in rapporten. Consequent afgedwongen kleine letters zijn de enige echte verdediging.

Wordt een QR-code moeilijker te scannen door UTM-parameters toe te voegen?

Het maakt de code dichter, wat niet helemaal hetzelfde is maar wel tot hetzelfde praktische risico leidt. UTM-URL's vereisen codering in bytemodus in plaats van de compactere alfanumerieke modus, en de extra tekens duwen de code naar een hogere versie met een dichter modulerooster. Bij een vaste afdrukgrootte betekent dat kleinere individuele modules en minder tolerantie voor problemen met de drukkwaliteit. De oplossing is niet het vermijden van UTM-tags; het is de QR-code naar een korte, dynamische redirect wijzen in plaats van naar de volledig getagde URL.

Kun je UTM-parameters toevoegen aan een statische QR-code?

Technisch gezien wel. De parameters zitten in de bestemmings-URL, niet in iets wat specifiek is voor dynamische codes. Het praktische nadeel is dat een statische code met een lange getagde URL er rechtstreeks in verwerkt zowel dichter is om te scannen als permanent vastligt. Verandert de campagnenaamconventie, of moet de link worden gecorrigeerd, dan moet de afgedrukte code zelf worden herdrukt.

Wat gebeurt er als je QR-codes eerst zonder UTM-tags drukt?

Elke scan komt in GA4 terecht als Direct-verkeer, niet te onderscheiden van iemand die de URL uit het hoofd typte. Bij een statische QR-code kan dit gat in de data niet met terugwerkende kracht worden gedicht zodra hij is gedrukt. Bij een dynamische QR-code is de oplossing om de bestemmings-URL bij te werken met de tags; scans vanaf dat moment worden correct toegeschreven, al blijft de ongetagde periode zonder attributie.

Hoe voorkomen bureaus UTM-naamconflicten tussen meerdere klanten?

Door de naamconventie te behandelen als een vast schema in plaats van een richtlijn: een beheerde, korte lijst met toegestane utm_medium-waarden, een gestructureerd patroon voor utm_campaign (klant, campagne, datum), afgedwongen kleine letters, en één gedeelde single source of truth met elke getagde link die momenteel in gebruik is, zodat niemand hoeft te gokken hoe de vorige persoon een vergelijkbare campagne heeft genoemd.

De korte versie

UTM-parameters zijn het enige dat voorkomt dat een gescande QR-code verdwijnt in de Direct-verkeersbak van GA4, want een scan draagt zelf geen referrer met zich mee. De drie die ertoe doen zijn source, medium en campaign; houd ze in kleine letters, houd het patroon gestructureerd in plaats van beschrijvend, en zet utm_medium vast op één waarde voor elke QR-link bij elke klant. Onthoud daarnaast dat een getagde URL langer en dichter te coderen is dan een kaal domein, dus wijs je QR-codes naar een korte, dynamische redirect in plaats van de volledig getagde link rechtstreeks in de afdruk te verwerken. Bouw de naamconventie één keer, leg hem ergens vast waar elk klantaccount hem moet gebruiken, en het rapportagegat dat nu verschijnt als onverklaard Direct-verkeer verandert in een kanaal dat je daadwerkelijk kunt verdedigen tegenover een klant.