QR-codes tracken zonder cookies: waarom een scan first-party data blijft

Elk bureau dat de resultaten van een QR-campagne rapporteert, moet uiteindelijk een ongemakkelijke vraag beantwoorden: hoeveel van die attributie kun je eigenlijk hard maken? Jarenlang was het eerlijke antwoord "minder dan het dashboard suggereert", omdat de meeste digitale attributie nog altijd leunt op cookies van derden en pixels van advertentienetwerken, en beide verliezen stilletjes hun grip. Een QR-scan heeft dat probleem niet, niet omdat ScanKit slim omgaat met privacy, maar door wat een scan structureel is: een first-party gebeurtenis, gelogd op je eigen server, zonder dat er iets over sites heen te matchen valt.

Dit is geen tijdelijke workaround voor een ongemak. Het is een structureel voordeel dat elk jaar waardevoller wordt naarmate de rest van de trackingstack steeds meer ruis vertoont. Hier lees je wat er werkelijk gebeurt met cookie- en pixelgebaseerde attributie, waarom een QR-scan buiten dat verval staat, en hoe je scandata verwerkt in een rapport dat een klant kan vertrouwen, zonder dat je de helft ervan moet nuanceren.

De trackingstack waarop bureaus hun rapportage bouwden, brokkelt stilletjes af

Safari blokkeert cookies van derden en cross-site cookies standaard en volledig sinds Safari 13.1 en iOS/iPadOS 13.4, alweer in maart 2020. Dat is geen recente verandering: bureaus die campagnes draaien voor een publiek met veel iPhone-gebruikers leven hier al zes jaar mee. Firefox volgde met Total Cookie Protection, dat elke cookie van derden isoleert in een eigen pot per site, zodat matching over domeinen heen nooit meer mogelijk is, standaard aan voor alle gebruikers sinds Firefox 103 in juni 2022.

Chrome is degene waar iedereen zich in vergist. De kop "Chrome maakt einde aan cookies van derden" doet al sinds 2019 de ronde, maar Google stelde het plan in april 2024 uit, liet het afschaffingstraject in juli 2024 volledig varen, en liet in april 2025 zelfs de losstaande prompt "kies je trackingvoorkeur" vallen die het als vervanging had voorgesteld. Chrome staat cookies van derden vandaag nog steeds standaard toe; het praktische effect van twee jaar aankondigingen waren de bestaande browserprivacyinstellingen, geen nieuw blokkeermechanisme. Als een rapport of een verkooppraatje van een leverancier je vertelt dat Chrome in 2024 een einde maakte aan cookies, is dat simpelweg niet wat er is gebeurd, en het is de moeite waard om dat recht te zetten, omdat het onderschat hoezeer de echte blokkade (Safari, Firefox) al jarenlang stilletjes van kracht is.

Voeg daar adblockers aan toe. Onderzoeksdata van GWI plaatste het wereldwijde gebruik van adblockers op 29,5% van de internetgebruikers in Q2 2025, met een Amerikaans cijfer dat dichter bij een derde ligt: 32,5%. En de platforms die vroeger zwakke first-party-metingen opvingen, hebben ronduit gezegd dat mobiele privacywijzigingen hen schaden: de CFO van Meta zelf omschreef de impact van Apple's App Tracking Transparency als tegenwind "in de orde van $10 miljard" op de omzet van 2022, tijdens het Q4 2021-winstgesprek van het bedrijf, een schatting die Meta zelf maakte over zijn eigen meting, geen gok van een derde partij.

Niets van dit alles betekent dat digitale attributie overal kapot is. Het betekent dat het specifieke mechanisme waar veel campagnerapportage van afhangt, cross-site of cross-app identiteitsmatching, al zes jaar zwakker wordt en geen tekenen van omkeer vertoont. Een QR-scan is nooit op dat mechanisme gebouwd geweest.

Wat een QR-scan structureel anders maakt

Marketingdata wordt meestal in drie categorieën ingedeeld. First-party data is wat je rechtstreeks verzamelt uit je eigen interacties met iemand, zonder tussenpersoon. Third-party data wordt verzameld door een bedrijf dat nooit een directe relatie had met de persoon die het beschrijft, precies de categorie waar cookies van derden en device-graph-matching onder vallen. Zero-party data, een term die Forrester-analist Fatemeh Khatibloo in 2018 bedacht, is wat iemand bewust en uit eigen beweging aan je vertelt: een aangegeven voorkeur of een expliciete opt-in.

Een scan van een dynamische ScanKit-code is first-party van aard. Er zit geen advertentienetwerk in de keten dat beslist of er een pixel wordt afgevuurd, geen cookie die een cross-site redirectketen moet overleven, en geen probabilistisch model dat een mobiel ID aan een desktopsessie koppelt omdat een derde van het signaal ergens stroomopwaarts is geblokkeerd. De camera van de telefoon leest de code, opent de URL, en je eigen redirectserver logt het verzoek. Dat is de hele keten.

Wat legt die server-side log eigenlijk vast? Een standaard HTTP-verzoek bevat een tijdstempel, de user-agent-string (die apparaattype, besturingssysteem en browser identificeert), een referrer-header indien aanwezig, en het IP-adres van de client. Dat is oprecht nuttig voor rapportage op campagneniveau, maar het loont om precies te zijn over wat IP je vertelt: geolocatiedatabases herleiden IP-adressen tot op landniveau met een nauwkeurigheid van ongeveer 99,8%, maar IP-gebaseerde locatie is niet, en kan niet, precies genoeg zijn om een specifiek adres of individu te identificeren. Nauwkeurigheidscijfers van leveranciers voor een fijnere resolutie (staat of regio, ongeveer 80% in de VS; stad binnen ongeveer 50 kilometer, ongeveer tweederde van de tijd) maken het punt duidelijk: je krijgt een richtinggevend bruikbaar locatiesignaal, geen match op huishoudniveau. Wil je een steviger identiteitssignaal dan "iemand in deze stad heeft deze code gescand", dan moet je de scan koppelen aan een formulier, een accountlogin, of een andere expliciete zero-party-actie verderop in de funnel, in plaats van de log zelf verder op te rekken dan hij gaat.

Het andere structurele punt dat het waard is om ronduit te benoemen, want leveranciers doen dat zelden: niemand in de identity-resolution-branche (AppsFlyer, Adjust, mParticle en de rest) publiceert een concreet percentage voor deterministische versus probabilistische matchrates dat je kunt citeren. Wat ze wel zullen zeggen, en wat per definitie waar is, is dat deterministische matching (een identifier die ondubbelzinnig aan één actie gekoppeld is, wat een scan van een unieke dynamische code is) niet dezelfde schattingsfout kent als probabilistische matching (afleiden dat twee verschillende apparaten of sessies "waarschijnlijk" bij dezelfde persoon horen). Een QR-scan van een code die je zelf hebt gegenereerd en beheert, is vanaf het begin deterministisch; er is geen gemodelleerde schatting om te wantrouwen.

Breekt iOS-privacybescherming QR-codetracking daadwerkelijk?

Bureaus die ATT als reden hebben horen aanvoeren waarom "mobiele tracking niet meer werkt", moeten precies weten wat het wel en niet dekt. App Tracking Transparency regelt één specifiek ding: de toegang van een app tot de advertentie-identifier van het toestel (IDFA) en het vermogen om de data van die app te koppelen aan data van apps en websites van andere bedrijven, voor advertentietargeting of -meting. Het is een App Store- en SDK-beleid dat binnen native apps geldt. Een QR-scan die een normale webpagina opent in Safari of Chrome is geen app die IDFA-toegang aanvraagt, dus ATT heeft er helemaal geen zeggenschap over.

Mail Privacy Protection is een aparte, smallere functie: het verbergt het IP-adres van een Mail-gebruiker en laadt externe content (inclusief tracking pixels) vooraf, zodat een afzender niet kan zien óf of wanneer een e-mail is geopend. Het is volledig beperkt tot Apple Mail. Een QR-code die op een flyer, poster of product staat, is geen e-mail-open-gebeurtenis, dus MPP raakt die ook niet.

De enige Apple-functie die daadwerkelijk kan interacteren met een QR-redirect is Link Tracking Protection, geïntroduceerd met iOS 17 en macOS Sonoma in 2023. Die verwijdert bekende trackingparameters uit de querystring van een URL voordat het verzoek ooit over het netwerk wordt verstuurd, maar alleen in drie specifieke omgevingen: Berichten, Mail en Safari Privé Surfen. Het richt zich op herkende trackingidentifiers, het soort dat advertentienetwerken aan een link plakken voor cross-site clickmatching, niet op het pad van een URL of een standaard campagne-attributieparameter. In de praktijk betekent dit twee dingen voor hoe je de bestemmings-URL van een dynamische code opbouwt. Ten eerste bevindt de overgrote meerderheid van QR-scans, geopend via de camera van een telefoon rechtstreeks in een normaal, niet-privé browsertabblad, zich nooit in een omgeving die LTP raakt. Ten tweede: als je diezelfde getrackte link ook deelt via sms of e-mail, houd dan elke campagne-identifier in het URL-pad of de slug in plaats van in een queryparameter die op een bekende tracker lijkt, dan komt hij ongemoeid door, ongeacht de omgeving.

Hebben QR-redirectlogs een cookiebanner nodig?

Dit is waar veel bureaus zichzelf óf uit voorzichtigheid nuttige data ontzeggen, óf te weinig voorzichtig zijn en in een compliance-probleem lopen, dus het loont om precies te zijn. Onder de ePrivacy-regels (en het Britse equivalent, PECR) wordt toestemming getriggerd door het opslaan van informatie op, of het uitlezen van informatie van, het apparaat van een gebruiker: het mechanisme dat een cookie of een trackingscript gebruikt. Zowel de Guidelines 2/2023 van de European Data Protection Board als de Franse CNIL zijn expliciet geweest dat deze reikwijdte niet beperkt is tot letterlijke cookies; IP-verzameling die voortkomt uit het uitlezen van de terminalapparatuur van de gebruiker (wat een tracking pixel doet) kan er ook onder vallen. De toezichthouders hebben geen blanco streep getrokken die alle server-side IP-logging als categorie vrijstelt, dus bouw je compliance-positie niet op "het is maar een serverlog, dus ePrivacy is niet van toepassing."

Wat wél overeind blijft: een QR-redirect die een verzoek logt om de dienst betrouwbaar te laten draaien en misbruik te voorkomen (de uitzondering voor "strikt noodzakelijke" doeleinden die zowel de ICO als de CNIL erkennen, dezelfde basis die fraudepreventie, load balancing en basisauthenticatie dekt) heeft niet dezelfde opt-in-cookiebanner nodig als een marketingcookie die daarna op de landingspagina wordt geplaatst. Het onderscheid dat ertoe doet, is waar de logging voor is: de redirect laten draaien en het scanvolume op campagneniveau meten, staat anders dan het instellen van een permanente identifier zodat je die bezoeker later op andere sites kunt retargeten, wat regelrecht een toestemmingsplichtige activiteit is. En los van het ePrivacy-antwoord: het IP-adres in je log is nog steeds persoonsgegevens onder de AVG, dus je hebt nog steeds een rechtsgrond nodig (gerechtvaardigd belang is hiervoor de gangbare keuze), een vastgestelde bewaartermijn, en je moet de gelogde velden beperken tot wat je daadwerkelijk gebruikt. Onze AVG-gids gaat dieper in op het ontwerp van toestemming voor de landingspagina zelf; het punt hier is smaller: de scanlog en de landingspagina-cookie zijn twee verschillende compliance-vraagstukken, en ze door elkaar halen is hoe bureaus ofwel nuttige rapportage te veel blokkeren, ofwel een echte verplichting te weinig afdekken.

Van scans naar attributie waar je klant echt op kan vertrouwen

De praktische winst van dit alles is een rapportageproces dat niet de voorbehouden nodig heeft van een cookiegebaseerd rapport. Begin met een unieke dynamische code per touchpoint, niet één code die hergebruikt wordt over een poster, een flyer en een direct mail-stuk, zodat een scan op het moment zelf al toe te schrijven is aan een specifieke plaatsing; dat is dezelfde discipline achter het tracken van een printcampagne met QR-codes. Elke scan is dan een first-party gebeurtenis die je in realtime kunt doorsturen naar waar de klant zijn source of truth al bijhoudt. Het algemene patroon is een webhook: je redirectserver post de event-payload naar een URL op het moment dat het gebeurt, in plaats van dat het CRM ernaar moet pollen. De custom-events-API van HubSpot is een concreet voorbeeld van de ontvangende kant: een POST met de eventnaam, een ISO 8601-tijdstempel, een properties-object en een contactidentifier is genoeg om een scan rechtstreeks aan het record van een persoon te koppelen, zonder dat daar cross-site matching voor nodig is.

Dat betekent niet dat je UTM-parameters of GA4 overboord gooit. Het betekent dat je stopt ze als je enige source of truth te behandelen. Voer scans in GA4 in zoals we beschrijven in onze Google Analytics 4-gids, zodat een scan als eigen kanaal verschijnt in plaats van weg te vallen onder "direct", maar behandel de server-side scanlog, degene zonder cookie-afhankelijkheid en zonder adblocker om te omzeilen, als de bron die de knoop doorhakt als de twee niet overeenkomen. Als je het klantrapport opbouwt, gaan onze gids over scanstatistieken en de walkthrough over campagne-ROI er allebei precies van uit dat dit soort schone, deterministische gebeurtenis de input is; hoe minder probabilistische schakels er in de keten zitten voordat het getal de klant bereikt, hoe makkelijker dat gesprek is.

Veelgestelde vragen

Gebruiken QR-codes cookies?

Nee. Het scannen van een QR-code opent een URL; de redirectserver kan het verzoek loggen (tijdstempel, apparaattype, IP) zonder ook maar één cookie te plaatsen of uit te lezen. Een cookie komt pas in beeld als de landingspagina er zelf een plaatst, wat een aparte beslissing is die los staat van de scan.

Welke data verzamelt een QR-codescan precies?

Op zijn minst alles wat een standaard HTTP-verzoek meedraagt: een tijdstempel, de user-agent-string (apparaat, besturingssysteem, browser), een referrer-header indien aanwezig, en het IP-adres van de client. IP is betrouwbaar te herleiden tot op landniveau en bij benadering tot een stad of regio, niet tot een specifieke persoon of adres.

Hoe nauwkeurig is QR-codetracking vergeleken met cookietracking?

Geen enkele met naam genoemde analyticsleverancier publiceert een concreet percentage voor deze vergelijking, dus wantrouw elk cijfer dat je hierover ziet circuleren. Wat kwalitatief wel klopt, is dat een scan van een unieke code die je zelf beheert een deterministische gebeurtenis is (precies deze code werd op precies dit moment gescand), terwijl cookie- en cross-device-attributie steeds meer leunt op probabilistische matching om de gaten te overbruggen die cookieblokkering en adblockers veroorzaken.

Waarom wordt pixelgebaseerde advertentie-attributie minder betrouwbaar?

Omdat de identiteitssignalen waarop het leunt standaard worden uitgeschakeld. Safari blokkeert cookies van derden sinds 2020, Firefox sinds 2022, en Apple's App Tracking Transparency beperkt het delen van identifiers tussen apps binnen iOS-apps. De CFO van Meta zelf schatte de impact van ATT op de omzet van 2022 op ongeveer $10 miljard, volgens Meta's eigen inschatting.

Verstoort iOS Link Tracking Protection QR-codetracking?

Bijna nooit. Het verwijdert alleen bekende trackingparameters, en alleen binnen Berichten, Mail en Safari Privé Surfen. Een normale scan die via de camera van de telefoon in een gewoon browsertabblad wordt geopend, valt in geen van die drie omgevingen.

Hebben QR-code-redirects een cookiebanner nodig?

Een verzoek loggen puur om de redirect te laten draaien en het scanvolume te meten, kan meestal steunen op de uitzondering voor "strikt noodzakelijke" doeleinden die toezichthouders erkennen. Het plaatsen van een tracking- of retargetingcookie op de landingspagina daarna is een aparte, toestemmingsplichtige actie. Het IP-adres blijft in beide gevallen persoonsgegevens, waarvoor een rechtsgrond onder de AVG en een vastgestelde bewaartermijn nodig zijn.

Wat is het verschil tussen first-party, zero-party en third-party data?

First-party data komt uit je eigen directe interacties met iemand. Zero-party data is wat iemand bewust aan je vertelt (een aangegeven voorkeur, een opt-in). Third-party data wordt verzameld door een bedrijf zonder directe relatie met de persoon die het beschrijft. Een QR-scan van je eigen code is per definitie first-party.

Kan QR-scandata naar een CRM of CDP gestuurd worden?

Ja, meestal via een webhook: de redirectserver post de scangebeurtenis naar het CRM of de CDP op het moment dat die plaatsvindt. Platforms met een custom-events-API, waaronder HubSpot, accepteren een eventnaam, een tijdstempel, een properties-object en een contactidentifier, wat genoeg is om een scan rechtstreeks aan het record van een persoon te koppelen.

Heb ik nog UTM-parameters nodig als ik dynamische QR-codes gebruik?

Ja, voor rapportage op kanaalniveau binnen GA4 en vergelijkbare tools. Het punt is niet om UTM-tagging te vervangen; het is om de server-side scanlog te behandelen als de bron die de knoop doorhakt wanneer cookieafhankelijke tools scans onderrapporteren die adblockers of browserprivacyinstellingen voor hen hebben verborgen.

Kort samengevat

Cookies van derden zijn in Safari en Firefox al standaard geblokkeerd, Chrome heeft hetzelfde nooit doorgevoerd, adblockers bereiken bijna een derde van de gebruikers, en platforms als Meta hebben ronduit gezegd dat mobiele privacywijzigingen hen meetbare advertentie-inkomsten hebben gekost. Een QR-scan staat buiten dat verval omdat hij nooit op cross-site identiteitsmatching is gebouwd: het is een first-party, deterministische gebeurtenis die je eigen server rechtstreeks logt. iOS-privacyfuncties gericht op apps en e-mail raken een normale scan niet, en de compliance-vraag voor de scanlog staat los van, en is eenvoudiger dan, de toestemmingsvraag voor een landingspagina-cookie. Koppel elke unieke dynamische code aan een webhook die de scan rechtstreeks naar het CRM van je klant pusht, houd GA4 aan voor rapportage op kanaalniveau, en gebruik de deterministische scanlog als het getal dat je verdedigt wanneer de twee niet overeenkomen.