QR-code retargeting: zo zet je een pixel op die scans niet mist

De meeste gidsen over QR-code retargeting stoppen bij "zet een Facebook-pixel op je landingspagina" en noemen dat klaar. Sommige gaan een stap verder en noemen het geheel cookieloze marketing, wat op geen van de vier grote advertentieplatformen klopt. Geen enkele vermeldt dat de grootste reden waarom een scan stilletjes niet in de juiste doelgroep terechtkomt, niet de QR-code zelf is, maar hoe snel de bezoeker de pagina verlaat waar de code naartoe leidt. Dit is de versie die alles behandelt: wat er werkelijk gebeurt tussen een scan en een advertentiedoelgroep, waarom de claim "cookieloos" onjuist is, wat de wetgeving rond toestemming echt vereist, wat Apple's privacyregels wel en niet beperken, en hoe je de combinatie van pixel en server-side tracking bouwt die standhoudt zodra een echte mobiele browser eraan te pas komt.

Wat QR-code retargeting eigenlijk is

Een QR-code kan niemand op eigen kracht retargeten. Het is een link. Retargeting gebeurt op de pagina waar de code naartoe verwijst, via hetzelfde ad-tech-mechanisme dat ook retargeting vanaf een Google-zoekopdracht of een Instagram-story mogelijk maakt: een klein scriptje op die pagina, meestal een pixel of tag genoemd, meldt aan een advertentieplatform "deze browser is hier net geweest".

De keten bestaat uit vijf stappen. De camera van de telefoon leest de code en volgt de redirect. De redirect wordt opgelost, meestal als een snelle server-side 301 of 302, naar de bestemmings-URL. De HTML van de bestemmingspagina laadt en de JavaScript van de tag wordt gedownload en uitgevoerd, bijvoorbeeld Meta's fbevents.js of TikTok's pixel-script. De tag stuurt een netwerk-beacon met een identifier: een cookiewaarde, een click-ID, of gehashte contactgegevens. Het advertentieplatform matcht die beacon aan een bestaand profiel en voegt de browser of de persoon, op zijn eigen schema en niet direct, toe aan een doelgroep die je met een volgende campagne kunt targeten.

Niets in die keten is uniek voor QR. Wat wel uniek is aan QR, is dat de bezoeker zonder browsegeschiedenis op je site en zonder eerdere interactie met je advertentieaccount arriveert, waardoor de eerste pageview na de scan ook heel vaak de enige kans is die de tag krijgt om af te vuren voordat de snelste bezoekers het tabblad al sluiten. Precies dat feit is waarom de faalscenario's hieronder hier zwaarder wegen dan bij een normaal websitebezoek.

Nee, het is niet cookieloos

Verschillende pagina's van QR-aanbieders omschrijven pixel-gebaseerde retargeting als "cookieloze marketing". Het loont om hier precies in te zijn, want het bepaalt zowel wat je een klant kunt beloven als welke toestemming je moet verzamelen. Check de eigen documentatie van elk platform en het patroon is consistent: elk van hen noemt een cookie als onderdeel van hoe het matchen werkt.

De developerdocumentatie van Meta stelt dat de Pixel "leunt op Facebook-cookies, die ons in staat stellen bezoekers van je website te koppelen aan hun bijbehorende Facebook-gebruikersaccount", en noemt er twee specifiek: _fbp, een willekeurig gegenereerde first-party ID-cookie die automatisch wordt aangemaakt bij de eerste pageload, en _fbc, die de ad-click-identifier uit een fbclid-URL-parameter opslaat en na 90 dagen verloopt. Google's supportdocumentatie omschrijft de Google Ads-tag als een tag die "cookies opslaat die informatie over de interactie bevatten, en een unieke identifier voor een gebruiker of de advertentieklik die de gebruiker naar je site bracht", gekoppeld aan de click-ID die je advertentie genereerde. Het helpcentrum van TikTok bevestigt dat de TikTok Pixel standaard first-party cookies gebruikt, plus third-party cookies tenzij je die uitschakelt, "om events te helpen matchen met mensen die interactie hebben met jouw content op TikTok". LinkedIn's Insight Tag plaatst cookies en, buiten de EU, EER, VK en Quebec, een extra pseudonieme identifier genaamd de LinkedIn Ads ID, die LinkedIn expliciet omschrijft als "een extra signaal bovenop cookies", niet als vervanging ervan.

Letterlijk gelezen bevestigen dus vier afzonderlijke platformen, in hun eigen documentatie, dat cookies de kern vormen van hoe een door QR aangedreven retargetingdoelgroep wordt opgebouwd. Een QR-scan bereikt dezelfde cookie-gebaseerde stack als elk ander websitebezoek; de code verandert alleen hoe de bezoeker op de pagina komt die de cookie plaatst. Het cookieloos noemen is geen versimpeling, het is een feitelijke fout, en één met gevolgen voor de volgende paragraaf.

Het toestemmingsprobleem dat een QR-scan veroorzaakt

Omdat de cookies echt zijn, gelden hier dezelfde toestemmingsregels als voor elke andere trackingpixel, en een QR-scan maakt de timing krapper dan de meeste bureaus verwachten.

Onder de ePrivacyrichtlijn is voorafgaande toestemming vereist voor het opslaan of uitlezen van informatie op het apparaat van een gebruiker, tenzij dit strikt noodzakelijk is om een dienst te leveren waar de gebruiker expliciet om heeft gevraagd. Een retargetingpixel valt daar niet onder. De Guidelines 2/2023 van het European Data Protection Board (EDPB), definitief vastgesteld in oktober 2024, gaan direct in op trackingpixels en concluderen dat het plaatsen van een pixel op een pagina telt als "opslag" via het cachingmechanisme van het apparaat, en dat de pixel die vervolgens "naar huis belt" naar het advertentieplatform een aparte handeling is van "toegang verkrijgen", waardoor een marketingpixel dezelfde voorafgaande toestemming nodig heeft als een cookie, ongeacht of hij daadwerkelijk een cookie gebruikt. Dat sluit het gat dat sommige aanbieders hebben gebruikt door te stellen dat een 1x1-trackingpixel op de een of andere manier iets anders zou zijn dan een cookie. Volgens de huidige EDPB-richtlijnen is dat niet zo.

De eigen definitie van toestemming in de AVG, in artikel 4, lid 11 en artikel 7, vereist dat toestemming vrij gegeven, specifiek, geïnformeerd en door een duidelijke actieve handeling wordt gegeven; overweging 32 sluit stilzwijgen, vooraf aangevinkte vakjes of simpelweg doorgaan met browsen uit als geldige toestemming. De Franse toezichthouder CNIL past dit sinds april 2021 concreet toe op marketingtags: geen lezen of schrijven op het apparaat van een bezoeker voordat die ja heeft gezegd.

Hier komt de QR-specifieke complicatie om de hoek kijken. Een bezoeker die op een zoekresultaat of advertentie klikt, is meestal al eerder langs je cookiebanner gekomen, tijdens een eerder bezoek, of komt binnen via een link waar een consent management platform de tijd krijgt om te laden voordat er iets afvuurt. Een QR-scan komt vaak koud binnen, rechtstreeks vanaf een fysiek object, op één specifieke pagina met maar één taak: redirecten en tracken. Als je retargetingtag het eerste is wat die pagina doet, vuur je hem af voordat er toestemming bestaat, bij elke enkele scan, en dat is een regelrechte schending van artikel 5, lid 3 van de ePrivacyrichtlijn, geen randgeval. De oplossing is technisch, niet juridisch: zet de retargetingtag achter je toestemmingsbanner met een tool zoals Google's Consent Mode of de eigen blokkeringsregels van je CMP, zodat de QR-landingspagina zich precies gedraagt als elke andere pagina die als first party wordt bezocht, en niet als een sluiproute om de banner heen.

Buiten de EU/VK/EER draait de logica om. De Californische CCPA en CPRA werken met een opt-outmodel: een bedrijf mag standaard gegevens delen voor cross-context behavioural advertising, totdat de bezoeker zijn "Do Not Sell or Share My Personal Information"-recht uitoefent, via een geplaatste link of via een geautomatiseerd opt-outsignaal zoals Global Privacy Control, dat bedrijven sinds 1 januari 2026 automatisch moeten respecteren. In de praktijk betekent dit dat dezelfde QR-landingspagina twee verschillende standaardinstellingen nodig heeft, afhankelijk van waar de bezoeker staat op het moment van scannen: afgeschermd in Europa, open met een gerespecteerd opt-outsignaal in Californië. De meeste consent management platforms regelen dit met geolocatieregels; controleer of die van jou dat doet voordat de oplage de deur uitgaat voor beide rechtsgebieden.

Voor het bredere plaatje van wat een getrackte scan verzamelt en hoe je end-to-end compliant blijft, zie zijn QR-codes AVG-proof?

Wat Apple's privacyregels werkelijk beperken

Bureaus gaan er vaak van uit dat Apple's App Tracking Transparency-framework hét obstakel is tussen een QR-scan en een schone retargetingdoelgroep. Dat klopt meestal niet, en als je dit verkeerd inschat, ga je het verkeerde probleem oplossen.

ATT, dat sinds iOS 14.5 in april 2021 apps verplicht om toestemming te vragen voordat ze gebruikers tracken of de IDFA-advertentie-identifier uitlezen, regelt het gedrag van native apps. Apple's eigen developer-FAQ is specifiek over de grens: ATT geldt voor een in-app webview alleen wanneer die wordt gebruikt "voor app-functionaliteit", en geldt expliciet niet wanneer de webview "de gebruiker in staat stelt om op het open web te navigeren". Een QR-scan opent de camera van de telefoon en geeft de controle vervolgens door aan de standaardbrowser of een webview die zich gedraagt als gewone webnavigatie, en dat valt duidelijk aan de andere kant van die grens. Het is zeer onwaarschijnlijk dat ATT het mechanisme is dat je QR-retargetingpixel blokkeert, want het was nooit gebouwd om dit pad te reguleren.

De regel die er werkelijk toe doet is Safari's Intelligent Tracking Prevention (ITP), en die is restrictiever dan de meeste bureaus beseffen. ITP blokkeert sinds 2020 standaard alle third-party cookies, zonder uitzonderingen. Specifiek voor QR: wanneer ITP "link decoration" detecteert, dat wil zeggen trackingparameters die aan een URL zijn toegevoegd, wat op vrijwel elke QR-redirect van toepassing is, beperkt het de levensduur van elke cookie die door de eigen JavaScript van die pagina wordt geplaatst tot 24 uur, in plaats van het langere venster dat dezelfde tag zou krijgen bij een normale verwijzing. Meta's _fbc-cookie staat gedocumenteerd als 90 dagen geldig; op een QR-landingspagina die in Safari wordt geopend, kan ITP's link-decoration-regel dat terugbrengen tot één dag. Dit is de echte, aanwijsbare, technische reden waarom een QR-retargetingdoelgroep scheeftrekt richting de dag van de scan en daarna snel uitdunt, specifiek bij iPhone-verkeer, en het is de moeite waard om dit zo aan een klant uit te leggen in plaats van met een vaag "iets met Apple en privacy".

Daar komt bij waar een QR-scan in de praktijk waarschijnlijk wordt geopend: in de eigen in-app browser van Instagram of TikTok, als de bezoeker doorklikte vanuit een story of een gedeelde link in plaats van de native camera-app. Deze in-app browsers draaien vaak hun eigen, aparte cookiejar in plaats van die van Safari te delen, waardoor een bezoeker die vanaf een gedrukte poster met de native camera scant en later een gerelateerde link vanuit Instagram aanklikt, voor diezelfde pixel kan lijken op twee verschillende, niet-gematchte personen. Dit is goed gedocumenteerd als technische mogelijkheid (beveiligingsonderzoeker Felix Krause toonde in 2022 aan dat de in-app browser van Instagram tracking-capabel script injecteert in de third-party pagina's die hij rendert), maar er zijn geen publieke gegevens over precies wat elk platform hier vandaag mee doet, dus behandel het als een reden waarom je cijfers ruizerig zullen zijn bij scans die via social binnenkomen, niet als een specifiek privacylek om te beweren.

De echte reden waarom scans uit de doelgroep verdwijnen

De meest gehoorde technische verklaring voor het ondertellen bij QR-retargeting klopt niet: het is niet zo dat een snelle redirect de pixel op de een of andere manier "voor is". Een server-side 301 of 302 wordt opgelost voordat er ook maar enige HTML of JavaScript draait, dus de snelheid van de redirect heeft niets om vroeg of laat tegen af te vuren. De pixel leeft op de bestemmingspagina, en het echte risicomoment opent zodra die pagina begint te laden en sluit zodra de bezoeker hem verlaat. Een bezoeker die scant, een blik werpt op een traag ladende pagina en binnen een seconde weer wegklikt, kan vertrekken voordat het script van de tag zelfs maar klaar is met downloaden.

Browserleveranciers hebben specifieke tooling gebouwd rond precies dit probleem, want het bestond al voor QR en speelt bij elke pagina die een bezoeker snel kan verlaten. De sendBeacon()-API bestaat zodat een pagina een kleine analytics-payload in de wachtrij kan zetten die het wegnavigeren overleeft, en de huidige richtlijnen van browsers (uit Chrome's eigen engineeringdocumentatie) raden aan om dit vanuit de visibilitychange-event te doen, met een check of de pagina verborgen is geraakt, in plaats van vanuit unload of beforeunload, die Chrome actief aan het uitfaseren is omdat ze "in veel typische unload-situaties niet afgaan, waaronder het sluiten van een tabblad via de tabbladwisselaar op mobiel". Een onafhankelijk empirisch onderzoek naar de betrouwbaarheid van beacon-aflevering vond dat ruwweg 72% van de beacons die op unload-moment werden verstuurd, en dichter bij 93% van de beacons die eerder, tijdens het laden van de pagina, werden afgevuurd, daadwerkelijk hun bestemming bereikten, waarbij iOS Safari werd aangewezen als het minst betrouwbare geval voor alles wat wordt uitgesteld tot het moment van vertrek. Niets hiervan is een officiële platformstatistiek, maar het komt overeen met wat bureaus in de praktijk zien: mobiele bezoekers op trage verbindingen zijn degenen die retargeting stilletjes mist.

Het praktische gevolg voor een QR-landingspagina: houd hem licht genoeg om ruim binnen de eerste seconde of twee te renderen en zijn tags af te vuren, voeg niets toe dat de tag achter andere scripts laat wachten, en als je Google Tag Manager gebruikt, controleer dan of elke trigger die een doorklik of een formulier op die pagina betreft, gebruikmaakt van GTM's optie "wachten op tags" in plaats van ervan uit te gaan dat de tag al is afgevuurd. Niets hiervan lost een trage verbinding op, maar het elimineert elke vermijdbare vertraging die je zelf in de hand hebt.

Een pixel toevoegen aan een QR-landingspagina, stap voor stap

De betrouwbare manier om dit te doen is via Google Tag Manager in plaats van de pagina handmatig te bewerken, omdat je zo op één plek de tags van elk platform beheert en de toestemmingsafscherming kunt afbakenen.

Maak een GTM-account en een Web-container aan op tagmanager.google.com, en installeer daarna de twee snippets die GTM je geeft: het hoofdscript zo hoog mogelijk in de <head> van de pagina, en de <noscript>-fallback direct na de openende <body>-tag. Voeg voor elk platform de tag toe met het officiële template uit GTM's Template Gallery in plaats van ruwe vendor-script te plakken: Meta publiceert zijn eigen Pixel-template (gebouwd en onderhouden op GitHub onder de facebook-organisatie), dat een Event ID-veld ondersteunt specifiek om te dedupliceren tegen server-side events, wat relevant wordt zodra je er een Conversions API naast zet, waar we hierna op ingaan.

Bepaal de trigger nauwkeurig. Omdat een QR-landingspagina meestal één specifieke URL is en geen hele site, vuur je de retargetingtag af op dat specifieke paginapad, niet op GTM's standaardtrigger "Alle pagina's". Zo blijven de tag, en je toestemmingsafscherming, precies beperkt tot de pagina waar ze thuishoren, in plaats van door te lekken naar de rest van de site. Publiceer via "Indienen" en vervolgens "Publiceren en versie maken", niet via alleen "Versie maken", want dat slaat enkel een concept op; elke echte publicatie maakt een versie aan waarnaar je kunt terugrollen als er iets misgaat.

Doelgroepgrootte en timing: wat je een klant vertelt

Bureaus krijgen voor elke campagne twee vragen: hoe groot moet de doelgroep zijn, en hoe snel kunnen we hem gebruiken. Het eerlijke antwoord is dat dit per platform verschilt en dat sommige officiële cijfers minder vaststaan dan ze lijken.

Customer Match van Google Ads heeft een minimum van 100 geüploade records nodig. De remarketingsegmenten voor Display, Search en YouTube hebben een minimum van 100 actieve bezoekers in de afgelopen 30 dagen nodig voor lijsten die sinds 1 februari 2024 zijn aangemaakt of vernieuwd, hoewel Google een aparte, ogenschijnlijk niet-bijgewerkte supportpagina heeft die specifiek voor Search-remarketinglijsten nog een minimum van 1.000 cookies noemt. Aangezien Google dit cijfer eerder heeft aangepast, check je beter de actuele Google Ads-interface dan dat je een van beide cijfers als vaststaand aan een klant voorlegt. TikTok's Custom Audiences hebben in totaal 1.000 gematchte gebruikers nodig voordat een advertentiegroep ze kan gebruiken. LinkedIn's Matched Audiences hebben 300 gematchte accounts nodig voordat het platform de doelgroep als "Geverifieerd" en bruikbaar markeert. Meta publiceert geen vast minimum voor een website-Custom Audience; de eigen richtlijn is kwalitatief: wacht op "enkele honderden mensen" voordat je er een activeert. Het cijfer "100" dat bureaus vaak voor Meta noemen, komt in werkelijkheid uit de aparte minimale brongrootte voor een Lookalike Audience, niet uit de levering van Custom Audiences, en die twee worden makkelijk door elkaar gehaald in een klantpresentatie.

Timing is net zo ongelijk. Google Ads begint bezoekers binnen enkele seconden na het afvuren van een tag te matchen, maar een net aangemaakte lijst kan 48 tot 72 uur nodig hebben om volledig te vullen. LinkedIn stelt ronduit dat een Matched Audience tot 48 uur kan duren om te verwerken. Meta en TikTok publiceren helemaal geen officieel cijfer voor de verwerkingstijd; beide zeggen alleen dat het vullen afhangt van je verkeer en van wanneer de tag live ging, zonder terugvulling voor scans van vóór die datum. Beloof je een klant een concreet cijfer voor Meta of TikTok, dan beloof je iets waar geen van beide platformen zich schriftelijk aan verbindt.

Server-side tracking dicht het gat dat een pixel niet kan

De eigen documentatie van elk platform komt uit op dezelfde erkenning: een pixel die alleen in de browser draait, verliest events aan connectiviteitsproblemen, mislukte pageloads, adblockers en precies het ITP- en in-app-browsergedrag dat hierboven is beschreven, en een server-side verbinding herstelt daar een aanzienlijk deel van. Meta noemt dit de Conversions API, die dezelfde events rechtstreeks vanaf je server naar Meta stuurt, gededupliceerd tegen de browser-Pixel via een gedeelde event-ID, en stelt dat deze bestaat om "website-events te delen die de Pixel mogelijk verliest door netwerkconnectiviteitsproblemen of laadfouten van de pagina". TikTok's Events API gebruikt bijna identieke bewoordingen: "connectiviteitsproblemen en inconsistenties in browsers kunnen de via Pixel gerapporteerde conversies beïnvloeden", en raadt aan om beide samen te laten draaien. Google Ads biedt Enhanced Conversions, dat first-party gegevens zoals een e-mailadres hasht voordat het ze verstuurt, gematcht tegen Google's eigen data van ingelogde gebruikers, om conversies te herstellen die de cookie-gebaseerde tag alleen zou missen. LinkedIn's Conversions API stuurt server-side events die de afhankelijkheid van cookie-matching grotendeels wegnemen.

Specifiek voor QR, waar het verkeer overwegend mobiel is en onevenredig vaak tegen Safari's ITP-beperkingen en in-app browsers aanloopt, is server-side tracking geen optionele upgrade, het is het onderdeel dat ervoor zorgt dat de cijfers die een klant ziet ongeveer overeenkomen met wat er werkelijk is gebeurd. Als je uit deze gids maar één ding bouwt naast de basispixel, maak het dan de Conversions API van het platform of het equivalent daarvan, draaiend naast de pixel met overeenkomende event-ID's, zodat het platform dedupliceert in plaats van dubbel telt.

Voor de attributievraag die deze hele opzet probeert te beantwoorden, zie hoe dit zich verhoudt tot een UTM-gebaseerde aanpak in QR-code UTM-parameters, en voor waar dit doorgaans op grote schaal wordt ingezet, zie QR-codes voor direct mail en QR-codes voor evenementen en beurzen.

Veelgestelde vragen

Is QR-code retargeting cookieloos?

Nee. Meta, Google Ads, TikTok en LinkedIn documenteren allemaal cookies als onderdeel van hoe hun pixel of tag een bezoeker aan een doelgroep koppelt: Meta noemt specifiek _fbp en _fbc, Google Ads koppelt een cookie aan de click-ID, TikTok gebruikt standaard first- en third-party cookies, en LinkedIn's pseudonieme ID wordt omschreven als aanvulling op cookies, niet als vervanging. Een QR-scan bereikt dezelfde cookie-gebaseerde stack als elk ander websitebezoek.

Heb je toestemming nodig voordat je iemand retarget die een QR-code scant?

Ja, in de EU, het VK en de EER. De richtlijnen van het European Data Protection Board uit 2024 behandelen een trackingpixel hetzelfde als een cookie onder de toestemmingsvereiste van de ePrivacyrichtlijn, dus moet hij achter actieve toestemming worden geplaatst en niet bij het laden van de pagina worden afgevuurd. Buiten die regio's geven regels zoals de CCPA/CPRA bezoekers in plaats daarvan een opt-outrecht, ook via een geautomatiseerd Global Privacy Control-signaal dat bedrijven moeten respecteren.

Hoe snel verschijnt een QR-scan in een retargetingdoelgroep?

Dat hangt af van het platform. LinkedIn noemt tot 48 uur. Google Ads begint binnen enkele seconden te matchen, maar een nieuwe lijst kan 48 tot 72 uur nodig hebben om volledig te vullen. Meta en TikTok publiceren geen officiële verwerkingstijd, alleen dat het afhangt van het verkeersvolume en van wanneer de tag voor het eerst live ging.

Wat is de minimale doelgroepgrootte voor retargeting?

Customer Match van Google Ads heeft 100 records nodig; de segmenten voor Display/Search/YouTube hebben voor nieuwere lijsten 100 actieve gebruikers in de afgelopen 30 dagen nodig (check de actuele richtlijnen van Google Ads, want dit cijfer is eerder gewijzigd). TikTok vereist 1.000 gematchte gebruikers. LinkedIn vereist 300 voor een "Geverifieerde" doelgroep. Meta stelt geen vast minimum, alleen de kwalitatieve richtlijn om te wachten op enkele honderden mensen.

Blokkeert Apple's App Tracking Transparency QR-code retargeting?

Niet rechtstreeks. ATT regelt tracking in native apps en de IDFA-identifier, en Apple's eigen documentatie sluit in-app webviews uit die worden gebruikt voor navigatie op het open web, en dat is precies wat een QR-scan doorgaans in gang zet. De beperking die er werkelijk toe doet is Safari's Intelligent Tracking Prevention, die third-party cookies volledig blokkeert en first-party, via JavaScript geplaatste cookies beperkt tot 24 uur op elke URL die het als drager van trackingparameters aanmerkt, precies de vorm van de meeste QR-redirectlinks.

Waarom pikt mijn retargeting pixel niet al mijn QR-scans op?

De meest waarschijnlijke oorzaak is niet de QR-code of de redirect, want die zijn allebei al opgelost voordat er enig trackingscript draait. Het gaat om hoe snel de bezoeker de bestemmingspagina verlaat ten opzichte van hoe lang het script van de tag nodig heeft om te downloaden, uit te voeren en af te vuren, in combinatie met ITP's 24-uurscap op cookies bij URL's met link decoration in Safari en de aparte cookiejar die veel in-app browsers gebruiken. Houd de landingspagina licht, vuur tags vroeg af, en voeg server-side tracking toe om te herstellen wat de browserpixel mist.

Moet je een pixel gebruiken, een server-side Conversions API, of allebei?

Allebei, gededupliceerd. Elk groot platform documenteert dezelfde redenering: een browserpixel alleen verliest events aan connectiviteitsproblemen, adblockers en privacybeperkingen van browsers, en een server-side verbinding (Meta's Conversions API, TikTok's Events API, Google's Enhanced Conversions, LinkedIn's Conversions API) herstelt daar een aanzienlijk deel van wanneer deze naast de pixel draait met een overeenkomende event-identifier.

Kun je QR-code scanners ook retargeten op TikTok of LinkedIn, niet alleen op Meta en Google?

Ja, met hetzelfde onderliggende mechanisme: een tag op de landingspagina, op dezelfde manier toegevoegd en afgebakend via Google Tag Manager, met de eigen minimale doelgroepgrootte en verwerkingstijd van elk platform.

Wat is het verschil tussen QR-code retargeting en QR-code analytics?

Analytics telt en beschrijft wat er is gebeurd: hoeveel scans, van waar, op welk apparaat. Retargeting maakt van diezelfde bezoekers een doelgroep waar je op een ander platform opnieuw aan kunt adverteren. Beide kunnen uit dezelfde scan voortkomen, maar het tweede werkt alleen als er een retargetingtag, met correcte toestemming, op de bestemmingspagina aanwezig is. Voor de analyticskant, zie QR-code analytics: welke scanstatistieken ertoe doen.

De korte versie

QR-code retargeting is geen speciale of cookieloze techniek; het gebruikt dezelfde pixels, dezelfde cookies en dezelfde toestemmingsregels als elke andere webretargeting, alleen bereikt via een scan in plaats van een klik. Zet de tag achter echte toestemming in de EU/VK, respecteer opt-outsignalen in Californië, en stop met piekeren over Apple's App Tracking Transparency, die hier vrijwel nooit van toepassing is, ten gunste van Safari's Intelligent Tracking Prevention, die dat wel is en die je trackingcookie op de meeste QR-links stilletjes beperkt tot 24 uur. Als de cijfers nog steeds mager ogen, kijk dan naar hoe snel je landingspagina zijn tag afvuurt ten opzichte van hoe snel mobiele bezoekers vertrekken, niet naar de QR-code zelf, en dicht het gat met een server-side Conversions API- of Events API-verbinding in plaats van een zwaardere pixel. Controleer het actuele doelgroepminimum en de verwerkingstijd van elk platform voordat je een cijfer aan een klant voorlegt, want meerdere daarvan veranderen. Bouw dit één keer, als een afgebakende Google Tag Manager-opzet op je QR-landingspagina's, en elke toekomstige campagne erft het gratis mee.