Drie verschillende verliezen
Contentblockers (uBlock Origin, AdGuard, Brave Shields, blockers op DNS-niveau) vergelijken hostnamen van requests en script-URL's met openbare lijsten. connect.facebook.net, googletagmanager.com en analytics.google.com staan op die lijsten; het eigen subdomein van de site niet. De blokkade vindt plaats voordat er code draait, dus niets op de pagina kan je vertellen dat het is gebeurd — de bezoeker verschijnt simpelweg niet.
Trackingpreventie in de browser (Safari ITP, Firefox ETP, Brave) blokkeert geen requests naar first-party hosts; ze beperkt state: third-party cookies worden gepartitioneerd of geblokkeerd, door scripts geschreven cookies verlopen na 7 dagen, en cookies die via een CNAME naar een third-party adres worden gezet, worden eveneens begrensd. De bezoeker verschijnt wél, maar vaker als nieuwe bezoeker dan in werkelijkheid het geval is.
Geweigerde toestemming is de bezoeker die nee zegt. Er is technisch niets kapot; de data mag niet worden verzameld. Een setup die dit verlies ‘terughaalt’, is geen meting maar een overtreding.
Hoe groot elk verlies is
Dat verschilt per doelgroep. Technische en jongere doelgroepen laten — in Duitsland bijvoorbeeld — contentblocker-percentages zien die ruim boven het wereldwijde gemiddelde liggen; het Safari-aandeel bepaalt de ITP-effecten; toestemmingspercentages hangen af van het ontwerp van de CMP en het vertrouwen in de site. Meet liever je eigen cijfers dan branchegemiddelden te citeren: vergelijk de geaccepteerde paginaweergaven van de collector (events-pagina, per bron) met het aantal paginaweergaven dat de tag van de leverancier over dezelfde periode rapporteert — het gat is je contentblocker-verlies op de host van die leverancier. De toestemmingspagina geeft het weigeringspercentage direct, en het aandeel terugkerende bezoekers per browser in je analytics laat het ITP-effect zien.
Wat een first-party server-side setup terughaalt
- Events met toestemming die lijstgebaseerde blockers tegenhouden. De SDK laadt vanaf jouw subdomein en post naar jouw collector; blockers matchen dat niet. Het event met toestemming bereikt je collector en van daaruit de server-API's van de leveranciers. De matchkwaliteit hangt af van welke identifiers de toestemming toeliet.
- Server-side levering van wat de browser niet kon versturen. Aankopen en leads die door de shop of de server zijn bevestigd, worden geleverd, ook als de pixel van de leverancier nooit is geladen.
- Storingen en tijdelijke fouten bij de leverancier. De worker probeert het opnieuw; de browser deed dat nooit.
Wat er niet verandert: de anonieme ID wordt door de SDK geschreven onder analytics- of marketingtoestemming, en Safari begrenst door scripts weggeschreven opslag nog steeds op zeven dagen. Het herkennen van terugkerende Safari-bezoekers daarbuiten blijft beperkt; Track werkt daar niet omheen.
Wat het niet mag terughalen
- Geweigerde toestemming. Geen click-ID's, geen identifiers, geen marketing-destinations. De router dwingt dit per event af; het is geen instelling die je kunt uitzetten.
- Geblokkeerde pixels van leveranciers als zodanig. Blokkeert de bezoeker
fbevents.js, dan blijft de browserkant van Meta geblokkeerd. Het serverpad ontvangt het event met toestemming — dat is het ontwerp — maar injecteert de pixel niet via een omweg. - Fingerprinting als vervanging voor identifiers. Niet geïmplementeerd, niet configureerbaar. Onbekend blijft onbekend.
De ‘Event Match Quality’ van leveranciers eerlijk lezen
Leveranciers scoren hoeveel identifiers elk server-event meedraagt. Na de overstap naar server-side stijgt die score vaak, omdat het gehashte e-mailadres uit het bestelsysteem nu wordt meegestuurd. Dat is een echte verbetering voor aankopen met toestemming. Het is geen bewijs dat er meer mensen worden getrackt; de toestemmingspagina laat hetzelfde weigeringspercentage zien als voorheen.
Praktische stappen
- Zet de collector en de SDK op een first-party subdomein (zie de gids over first-party domeinen).
- Stuur aankopen en leads vanaf de server met dezelfde event-ID als de browser.
- Vergelijk de aantallen per browser op de datakwaliteitspagina; verwacht dat het gat kleiner wordt voor Chrome met blockers en voor Firefox, en dat de herkenning van terugkerende bezoekers op Safari verbetert.
- Laat het toestemmingspercentage met rust, of verbeter het met een duidelijkere banner — nooit met techniek.