QR-codes meten in Google Analytics: zo voorkom je dat scans als 'Direct' verdwijnen

Je hebt 40.000 flyers laten drukken, de klant is blij, de codes worden gescand, en dan open je Google Analytics en blijkt elk van die bezoeken in een bakje te zitten met het label "Direct". Geen campagne, geen bron, niets om aan de klant te laten zien. De scans zijn gebeurd. GA4 heeft alleen geen idee dat ze van een QR-code kwamen.

Dit is veruit de meest voorkomende fout bij het meten van QR-codes, en hij is volledig op te lossen. De oplossing zijn UTM-parameters, toegepast met iets meer zorg dan de tutorials voor losse winkels suggereren, want een bureau dat codes uitrolt over een hele klantenportefeuille loopt tegen problemen aan die die tutorials nooit noemen. Deze gids behandelt de techniek erachter, de ene GA4-eigenaardigheid die de meeste setups stilletjes sloopt, en een tagging-systeem dat overzichtelijk blijft over tientallen campagnes heen.

Waarom QR-scans als "Direct" verschijnen in GA4

Als iemand op een link in een e-mail tikt of doorklikt vanaf een andere website, geeft de browser een referrer mee: het adres van de pagina waar diegene vandaan komt. GA4 leest die referrer en plaatst het bezoek onder de juiste bron. Een QR-scan heeft geen referrer. De scan gebeurt in een camera-app of een in-app browser, die je bestemmings-URL koud opent, zonder enige registratie van waar het verzoek vandaan kwam.

Zonder referrer en zonder campagne-tags op de URL kan GA4 een QR-scan niet onderscheiden van iemand die je webadres met de hand intikt. Allebei zien eruit als een bezoeker die uit het niets opdook, dus belanden ze allebei in Direct traffic, gerapporteerd als de bron (direct) en het medium (none). Google is daar in de eigen analytics-documentatie helder over: verkeer zonder identificerende informatie valt standaard terug op Direct. De camera-app doet niets verkeerd; er staat in een kale scan simpelweg niets dat GA4 kan uitlezen.

De klus is dus om die informatie zelf in de URL te zetten. Daar zijn UTM-parameters voor.

De vijf UTM-parameters, en welke een QR-code nodig heeft

UTM-parameters zijn tags die je achter een bestemmings-URL plakt. GA4 leest ze uit en plaatst het bezoek dienovereenkomstig. Er zijn er vijf, gedefinieerd door Google's Campaign URL Builder:

• utm_source - waar het verkeer vandaan komt. Voor een QR-code is dit de fysieke plaatsing: summer-flyer, shop-window, tradeshow-banner.
• utm_medium - het marketingkanaal. Voor QR is dit conventioneel qr of qr-code. Onthoud dat even, want dit is precies het veld waar mensen in GA4 over struikelen.
• utm_campaign - de campagne waar de plaatsing bij hoort: spring-sale-2026, client-rebrand-launch.
• utm_term - optioneel, oorspronkelijk voor zoekwoorden in betaalde zoekcampagnes. Zelden gebruikt op QR-codes.
• utm_content - optioneel, om twee versies van elkaar te onderscheiden. Handig als je dezelfde campagne op twee verschillende plaatsingen draait en ze wilt vergelijken.

Google is expliciet dat je de eerste drie altijd moet instellen: source, medium en campaign. De andere twee zijn er voor als je meer detail nodig hebt. Een getagde QR-bestemming ziet er zo uit:

https://client.com/offer?utm_source=shop-window&utm_medium=qr&utm_campaign=spring-sale-2026

GA4 koppelt utm_source aan Session source, utm_medium aan Session medium en utm_campaign aan Session campaign. Dat zijn de dimensies waarop je straks rapporteert.

Eén regel telt hier zwaarder dan alle andere, en hij komt keihard uit Google's documentatie: parameterwaarden zijn hoofdlettergevoelig. utm_source=Google en utm_source=google zijn twee verschillende bronnen, gerapporteerd op twee aparte rijen. Email en email tellen nooit bij elkaar op. Voor één code is dit een kleine ergernis. Over een hele bureauportefeuille aan campagnes, waar verschillende mensen verschillende klussen taggen, is het het verschil tussen een schoon rapport en een versplinterd rapport. Kies een hoofdlettterconventie (kleine letters is de verstandige standaard) en wijk er nooit van af.

Houd de waarden ook URL-veilig. Vermijd spaties en gereserveerde tekens (&, ?, #, =, +, /); vervang spaties door koppeltekens of underscores en blijf consequent in welke je kiest.

De valkuil waar niemand je voor waarschuwt: utm_medium=qr belandt in "Unassigned"

Hier is de eigenaardigheid die de meeste QR-setups stilletjes sloopt, en die vrijwel geen enkele tutorial noemt.

GA4 sorteert verkeer in standaardkanalen (Direct, Organic Search, Email, Paid Social, Referral enzovoort) op basis van een vaste set regels die je niet kunt aanpassen. Elk kanaal heeft voorwaarden op de bron en het medium. Email vangt bijvoorbeeld elk medium dat overeenkomt met email. Referral vangt mediums referral, app of link. Organic Social vangt social en de varianten daarvan.

Loop dat lijstje na en je merkt iets op: er is geen regel voor een medium qr. De kanaaldefinities van GA4 bevatten het simpelweg niet. Dus als je een code tagt met het voor de hand liggende, logisch ogende utm_medium=qr, leest GA4 de tag perfect uit, slaat de bron en campagne correct op, en plaatst het kanaal vervolgens onder Unassigned, het bakje dat Google gebruikt als niets anders matcht.

Je data is niet verloren. Als je rechtstreeks naar de dimensies Session source en Session medium kijkt, staat je qr-verkeer er allemaal, correct toegewezen. Maar in de standaard kanaalrapporten, en in elk dashboard dat op kanaalgroeperingen is gebouwd, verdwijnt het in Unassigned tussen alle andere restjes. Klanten zien "Unassigned" en vragen wat dat betekent. Het ziet er niet uit als een campagne die je bewust hebt gedraaid.

Er zijn twee nette manieren om hiermee om te gaan:

1. Gebruik een medium dat GA4 al herkent, en wees beschrijvend in de bron. Zet utm_medium=referral en utm_source=qr-shop-window. Het verkeer belandt in het Referral-kanaal, wat in elk geval een benoemde, logische plek is, en de QR-plaatsing staat uitgeschreven in de bron. Nadeel: het mengt met echt referral-verkeer, dus je leunt op de bron om het te scheiden.
2. Bouw een aangepaste kanaalgroep in GA4. Maak een kanaalgroep met een regel die utm_medium=qr (of qr-code) opvangt en noem hem "QR". Dit is het nettere antwoord als je een echt QR-kanaal in je rapporten wilt. Het is een eenmalige instelling per property en je houdt je voor de hand liggende utm_medium=qr-tags intact.

Wat je ook kiest, beslis het één keer en pas het toe op elke code. Het slechtste resultaat is een mengelmoes: sommige codes op qr, sommige op referral, sommige op qrcode, verspreid over Unassigned en Referral zonder consistente manier om ze samen te brengen.

Zet de UTM's op de bestemming, niet op de gedrukte code

Er is een sterke technische reden om geen lange, met UTM's volgeladen URL rechtstreeks in een statische QR-code te drukken: het maakt de code fysiek moeilijker te scannen.

De dichtheid van een QR-code wordt bepaald door hoeveel data hij draagt. De QR-standaard, ISO/IEC 18004, definieert 40 versies, van een raster van 21x21 modules tot 177x177. Hoe meer tekens je codeert, hoe hoger de versie, hoe meer modules, en hoe kleiner elke module wordt bij een gegeven afdrukformaat. Een lange URL volgepropt met utm_source, utm_medium, utm_campaign en de rest kan een code makkelijk in een dichtere versie duwen die een grotere afdruk of een scan van dichterbij nodig heeft om betrouwbaar leesbaar te zijn. Op een flyer die je op armlengte vasthoudt is dat precies de verkeerde kant op.

De oplossing is een dynamische QR-code. Een dynamische code codeert een korte redirect-URL, niet de uiteindelijke bestemming. De gedrukte code blijft laag in dichtheid en makkelijk te scannen, hoe lang de getagde bestemming ook is, want de lange UTM-string staat op het redirect-doel, niet in de gedrukte vakjes. Het betekent ook dat je de UTM's kunt aanpassen of corrigeren nadat de code gedrukt is, iets wat een statische code nooit kan. Een campagnenaam verkeerd gespeld, of halverwege besloten om één plaatsing in tweeën te splitsen? Met een dynamische code pas je de bestemming aan en is elke toekomstige scan correct getagd. We behandelen de techniek daarachter in de bestemming van een QR-code wijzigen zonder opnieuw te drukken, en het bredere argument voor dynamisch boven statisch in dynamische versus statische QR-codes.

De flow hierboven is het waard om te volgen, want hij verklaart een getal dat veel klanten in verwarring brengt.

1. De gedrukte QR-code bevat een korte redirect-URL.
2. Een scan komt binnen op die redirect. Dit is waar je QR-platform een scan telt.
3. De redirect stuurt de bezoeker door naar de bestemming en draagt de UTM-tags mee.
4. De bestemmingspagina laadt en vuurt de GA4-tag af. Dit is waar GA4 een session telt.

Je scanaantal en je GA4-sessies zullen nooit gelijk lopen

Omdat een scan en een session op twee verschillende punten door twee verschillende systemen geteld worden, zullen de twee getallen niet overeenkomen, en dat is normaal. Je QR-platform telt de hit op de redirect. GA4 telt pas een session zodra de bestemmingspagina geladen is en zijn tag heeft gedraaid. Er gebeurt van alles in het gat tussen die twee gebeurtenissen:

• Iemand scant, ziet de URL-preview en besluit niet door te gaan. Scan geteld, geen session.
• De bezoeker heeft een ad- of analytics-blocker. Pagina laadt, GA4 vuurt nooit af. Scan geteld, geen session.
• Een trage verbinding of een wegtik haalt de pagina onderuit voordat de tag draait.
• Link-preview-bots en prefetchers raken de redirect zonder ooit een echt mens te zijn. Scan geteld, geen menselijke session.

Het scanaantal op de redirect-laag is vrijwel altijd het hogere van de twee. Dat is geen fout in een van beide systemen; ze meten verschillende dingen. De QR-scan is "iemand richtte een camera en koos ervoor". De GA4-session is "een browser bereikte de pagina succesvol en draaide onze analytics". Een handige vuistregel is om enig verschil te verwachten en alleen te onderzoeken als het ongewoon groot wordt, want een grote afwijking kan wijzen op een kapotte redirect, een ontbrekende tag of een vloed aan bot-scans. Voor wat elke scan-metric je nu echt vertelt, zie welke scan-statistieken ertoe doen.

Een UTM-taxonomie die een klantenportefeuille overleeft

Alles hierboven werkt voor één code. De reden dat bureaus in de problemen komen is schaal: twaalf klanten, veertig plaatsingen, drie mensen die URL's taggen, en zes maanden later zijn de GA4-rapporten een chaos van Spring_Sale, spring-sale, SpringSale en spring sale 2026, die geen van alle bij elkaar optellen want, weet je nog, GA4 behandelt elk daarvan als een aparte campagne.

De verdediging is een kleine, saaie, gedocumenteerde taxonomie die elke campagne aanhoudt:

• Alles in kleine letters. Google's eigen richtlijn wijst die kant op, en het omzeilt de hoofdlettervalkuil volledig. Eén schrijfwijze, geen uitzonderingen.
• Geen spaties, één scheidingsteken. Kies koppeltekens of underscores en gebruik alleen dat. spring-sale-2026, nooit spring sale 2026.
• Een vaste woordenschat per veld. Bepaal de toegestane waarden voor source, medium en campaign en schrijf ze op. utm_medium is altijd qr. utm_source is altijd de plaatsing, gekozen uit een afgesproken lijst. utm_campaign volgt een patroon als {client}-{campaign}-{year}.
• Beheer het op één plek. Een gedeelde spreadsheet of een UTM-builder die het hele team gebruikt, zodat niemand op een vrijdagmiddag een nieuwe spelling verzint. De tool is minder belangrijk dan de discipline om elke URL er doorheen te leiden.

Dit sluit natuurlijk aan op hoe je klanten in je QR-platform al scheidt. Als je één werkruimte per klant aanhoudt, laat dan de naam van de werkruimte de woordenschat voor campagne en bron voeden, zodat de structuur in je QR-tool en de structuur in GA4 op één lijn liggen. Als een klant om zijn cijfers vraagt, filter je op een campagne-prefix die je kunt voorspellen, niet op gokken hoe iemand het gespeld heeft.

QR-prestaties lezen en rapporteren in GA4

Zodra codes getagd zijn en de kanalen op orde zijn, leeft het rapport in Reports > Acquisition > Traffic acquisition (Rapporten > Acquisitie > Verkeersacquisitie). Zet de primaire dimensie op Session source, Session medium of Session campaign, of gebruik je aangepaste QR-kanaal als je dat hebt gebouwd, en je QR-verkeer staat er als een benoemde, filterbare regel.

Een paar GA4-bijzonderheden zijn de moeite waard om te kennen voordat je een klant een getal overhandigt:

• Koppel scans aan resultaten. Een bezoek is niet het doel; de boeking, de aanmelding, de aankoop is het doel. Markeer die actie als key event in GA4 en segmenteer daarna Traffic acquisition op je QR-campagne om te zien hoeveel van die scans uitmondden in waar de klant echt om geeft.
• Let op het attributievenster. GA4 schrijft een key event terug toe aan een campagne binnen een terugkijkvenster: standaard 30 dagen voor acquisitiegebeurtenissen bij het eerste bezoek en 90 dagen voor andere key events. Een scan vandaag die vijf weken later converteert wordt nog steeds toegewezen; een langer gat misschien niet.
• Stel cross-domain measurement in als de reis meerdere domeinen omspant. Als de QR op het ene domein landt en de conversie op een ander gebeurt (een apart boekings- of checkout-domein), configureer dan cross-domain measurement in de GA4 data stream, zodat de reis als één gebruiker telt in plaats van een self-referral die de bron reset.
• Let op de voorrang van auto-tagging bij Google Ads. Als een QR-campagne-URL ooit via Google Ads loopt, overschrijft auto-tagging (de gclid) je handmatige UTM's standaard. Om je handmatige tags te laten winnen, schakel je de property-instelling in die handmatige tagging voorrang geeft op auto-tagging.

Dat is de hele lus: tag de bestemming, leid hem via een dynamische code zodat de afdruk scanbaar en bewerkbaar blijft, repareer de kanaal-eigenaardigheid zodat QR-verkeer een thuis heeft, en rapporteer tegen een key event dat de klant herkent. Voor het grotere plaatje van een fysieke campagne van begin tot eind meten, loopt hoe je een printcampagne met QR-codes meet de volledige setup door.

Veelgestelde vragen

Waarom verschijnen mijn QR-codes als direct verkeer in Google Analytics?

Omdat een QR-scan geen referrer meedraagt. De scan opent je URL vanuit een camera of in-app browser zonder enige registratie van waar hij vandaan kwam, dus tenzij de URL zelf UTM-parameters draagt, heeft GA4 niets om het bezoek aan toe te wijzen en plaatst het onder Direct ((direct) / (none)). UTM-tags op de bestemmings-URL zetten is wat GA4 de source, medium en campaign geeft om op te rapporteren.

Welke UTM-parameters moet ik aan een QR-code toevoegen?

Minimaal de drie die Google zegt altijd te gebruiken: utm_source (de plaatsing, bijvoorbeeld shop-window), utm_medium (conventioneel qr) en utm_campaign (de campagnenaam). utm_term en utm_content zijn optioneel en alleen de moeite waard als je twee versies van een plaatsing van elkaar moet onderscheiden.

Wat moet utm_medium zijn voor een QR-code?

De gangbare conventie is qr of qr-code, in kleine letters en consequent gebruikt. Houd er rekening mee dat GA4 geen standaard kanaalregel voor qr heeft, dus verkeer dat zo getagd is belandt in Unassigned. Bouw óf een aangepaste kanaalgroep die utm_medium=qr opvangt, óf gebruik een herkend medium als referral met een beschrijvende bron. Kies één aanpak en pas die toe op elke code.

Zijn UTM-parameters hoofdlettergevoelig in GA4?

Ja. Google's documentatie stelt dat parameterwaarden hoofdlettergevoelig zijn, dus utm_source=Google en utm_source=google rapporteren als twee aparte bronnen, en Spring-Sale en spring-sale tellen als twee verschillende campagnes. Standaardiseer op kleine letters om te voorkomen dat je je eigen data opsplitst.

Waar zie ik QR-codeverkeer in GA4?

Ga naar Reports > Acquisition > Traffic acquisition (Rapporten > Acquisitie > Verkeersacquisitie) en zet de dimensie op Session source, Session medium of Session campaign. Je getagde QR-verkeer verschijnt onder de waarden die je hebt ingesteld. Als je utm_medium=qr hebt getagd en een aangepaste kanaalgroep hebt gebouwd, staat het daar; anders kijk je rechtstreeks naar de dimensies source en medium in plaats van naar het standaard kanaalrapport.

Waarom is mijn GA4-sessieaantal lager dan het scanaantal van mijn QR-platform?

De twee worden op verschillende punten gemeten. Je QR-platform telt de scan zodra de redirect geraakt wordt; GA4 telt pas een session nadat de bestemmingspagina geladen is en zijn tag draait. Bounces voordat de pagina laadt, ad- en analytics-blockers, trage verbindingen en link-preview-bots zitten allemaal in het gat, dus het scanaantal ligt normaal gesproken hoger. Een bescheiden verschil is te verwachten; alleen een heel groot gat is het onderzoeken waard.

Moet ik de URL inkorten voordat ik er een QR-code van maak?

Het helpt. Een lange URL volgepakt met UTM-parameters codeert in een dichtere, lastiger te scannen code. Een dynamische QR-code lost dit op door een korte redirect-URL te coderen en de lange getagde bestemming op het redirect-doel te houden, zodat de gedrukte code laag in dichtheid blijft en je de UTM's na het drukken nog kunt aanpassen.

Kan ik de UTM-parameters aanpassen nadat de QR-code gedrukt is?

Alleen met een dynamische code. Een statische code bakt de exacte URL in de gedrukte vakjes, dus de tags liggen voor altijd vast. Een dynamische code wijst naar een korte redirect die je beheert, dus je kunt een campagnenaam corrigeren of een plaatsing op elk moment opnieuw splitsen, en elke toekomstige scan pikt de nieuwe tags op.

De korte versie

QR-scans belanden in Direct omdat ze geen referrer meedragen, dus GA4 heeft niets om ze aan toe te wijzen. Los dat op door de bestemmings-URL te taggen met utm_source, utm_medium en utm_campaign, in kleine letters en consequent. Let op de ene valkuil die vrijwel iedereen te grazen neemt: een utm_medium van qr matcht geen enkele GA4-kanaalregel en valt in Unassigned, dus bouw óf een aangepast QR-kanaal óf gebruik een herkend medium. Houd de UTM's op de bestemming van een dynamische code, niet ingebakken in de afdruk, zodat de code scanbaar en bewerkbaar blijft, en accepteer dat scanaantallen altijd iets voor zullen lopen op GA4-sessies. Rapporteer daarna tegen een key event dat de klant herkent, niet tegen kale bezoeken.

Kies je tagging-conventie nu, voordat de volgende batch codes naar de drukker gaat, en schrijf hem op waar het hele team hem kan zien. Het schoonste QR-rapport is het rapport waarvoor je de regels op dag één hebt vastgelegd.