Adblockers en tracking: wat je webshop misloopt

Adblockers stoppen tracking door te voorkomen dat het pixelscript van het advertentieplatform, of de verzoeken die het verstuurt, in de browser van de shopper worden geladen. Dan hoort het platform nooit van de paginaweergave, de add-to-cart of de aankoop, ook al staat de bestelling in je webshop. Aankopen die server-side uit je bestelgegevens worden verstuurd, worden niet geraakt, omdat de browser van de shopper er niet bij betrokken is.

Deze gids legt uit hoe adblockers en privacyfuncties van browsers werken, welke events je webshop mist, wat server-side tracking terughaalt en wat niet. Je vindt aan het eind een eenvoudige manier om het gat in je eigen webshop te meten.

Hoe blokkeren adblockers trackingpixels?

De meeste adblockers werken met filterlijsten. Een filterlijst is een lange lijst regels die overeenkomen met webadressen: domeinen, paden en bestandsnamen van bekende advertentie- en trackingscripts. Als een pagina de browser vraagt iets te laden dat bij een regel past, annuleert de blocker het verzoek.

De bekendste lijsten zijn EasyList, voor advertenties, en EasyPrivacy, voor tracking. Ze werken met extensies als Adblock Plus, AdBlock, uBlock Origin en AdGuard. De pixel van een groot advertentieplatform is een gemakkelijk doelwit voor deze lijsten, omdat hij op veel verschillende sites hetzelfde script van hetzelfde domein laadt.

Browsers met ingebouwde bescherming

Sommige browsers blokkeren trackers zonder extensie. Brave zet Shields standaard aan voor elke site, en Shields blokkeren advertenties, trackers en cross-site cookies van derden. Firefox blokkeert in privévensters content van bekende cross-site trackingdomeinen, en mensen kunnen strengere instellingen kiezen die voor alle vensters gelden. De Intelligent Tracking Prevention van Safari blokkeert alle cookies van derden en verkort de levensduur van cookies die scripts zetten. In onze gids over Safari ITP en advertentietracking lees je wat die beperkingen inhouden.

Blockers voor het hele netwerk

Sommige mensen blokkeren trackers voor een heel apparaat of thuisnetwerk, met een DNS-blocker of een VPN met trackerfilter. Die stoppen verzoeken naar trackingdomeinen in elke browser en app op dat netwerk. Van browser wisselen verandert niets aan het resultaat.

Welke events mist je webshop?

Als de pixel wordt geblokkeerd, gaat elk event verloren dat hij vanuit die browser had verstuurd. De schade is niet voor elk event gelijk.

Verloren browse-events maken je retargetingdoelgroepen kleiner. Verloren aankopen richten meer schade aan. Het platform rapporteert minder conversies, de ROAS in het advertentierapport daalt en het biedalgoritme leert van minder kopers. Een winstgevende campagne kan dan verliesgevend lijken, en misschien draai je hem terug.

Waarom server-side events uit bestelgegevens niet worden geblokkeerd

Een adblocker draait in de browser van de shopper. Hij kan alleen verzoeken stoppen die de browser doet. Als de aankoop uit de bestelgegevens van je webshop wordt verstuurd, gaat het verzoek van een server naar de API van het advertentieplatform. De browser van de shopper maakt geen deel uit van dat pad, dus de blocker heeft niets om te annuleren.

Het platform koppelt de aankoop daarna aan een persoon met de gegevens in het event: de gehashte e-mail en het telefoonnummer uit de bestelling, het IP-adres en de user agent, en het click-id als er een is opgeslagen. Niets hiervan loopt via de blocker. Voor het volledige datapad lees je wat server-side tracking is.

Wat kan server-side tracking niet herstellen?

Het click-id heeft de browser nodig

De bestelling zelf is veilig, maar de koppeling met de advertentieklik wordt in de browser gelegd. Een script moet het click-id uit de landings-URL lezen en opslaan. Als een adblocker ook dat script blokkeert, komt de bestelling zonder click-id binnen. Het platform kan de aankoop nog steeds koppelen via gehashte klantgegevens, maar die koppeling is minder zeker.

Twee dingen beperken dit verlies. Verzamel events ten eerste first-party: serveer het trackingscript en de verzoeken ervan vanaf je eigen domein, bijvoorbeeld via een Shopify-app-proxy of een subdomein van je site. Filterlijsten richten zich op bekende trackingadressen van derden, dus een first-party pad is veel moeilijker te blokkeren, al is het niet onmogelijk. Gebruik ten tweede de landingspagina die sommige webshopplatforms, zoals Shopify, bij elke bestelling opslaan. Als die URL nog het click-id of de UTM's bevat, kan de bestelling worden toegeschreven zonder enig browserevent.

Browse-events gaan nog steeds verloren

Bestelgegevens bevatten bestellingen, geen paginaweergaven. Aankopen vanuit bestellingen versturen brengt de paginaweergaven en add-to-cart-events van een bezoeker wiens browser alles blokkeerde niet terug. Een first-party collector kan deze events vanaf de server doorsturen als zijn eigen verzoeken wel doorkomen.

Geweigerde toestemming is geen blokkade

Een bezoeker die in je cookiebanner marketingcookies weigert, is niet hetzelfde als een bezoeker met een adblocker. De eerste bezoeker heeft een keuze gemaakt die je tracking moet volgen. Met Respect visitor consent aan zet ROASaurus voor die bezoeker geen bezoeker-id, dus zijn advertentieklikken en bezoeken worden niet aan hem gekoppeld. Zijn browserevents worden bewaard zonder bezoeker-id, IP-adres of browsergegevens en worden niet naar advertentieplatforms verstuurd. De betaalde bestelling wordt nog wel server-side verstuurd, met gehashte klantgegevens uit de bestelling en het IP-adres en de user agent van de bestelling. Houd de twee groepen uit elkaar als je je verlies meet, en lees toestemming en privacy voor de details.

Zo schat je je eigen verlies in

Je hebt geen branchegemiddelden nodig, want die hangen af van doelgroep, apparaat en land. Je kunt je eigen gat meten door de bestellingen in je webshop te vergelijken met de aankopen die de browserpixel in dezelfde periode heeft gerapporteerd.

1. Kies een periode en één platform

   Gebruik 14 of 30 dagen en één platform, bijvoorbeeld Meta. Gebruik in beide systemen dezelfde tijdzone.

2. Tel de webbestellingen in je webshop

   Begin met alle bestellingen. Haal de bestellingen weg die nooit via je online checkout lopen: kassabestellingen, handmatige bestellingen en conceptbestellingen, verlengingen van abonnementen en testbestellingen.

3. Tel de Purchase-events van de browser

   Tel in de eventtool van het platform de Purchase-events die de browserpixel heeft verstuurd. Dat gaat het makkelijkst voordat je serverevents toevoegt. Als serverevents al draaien, gebruik dan de weergave per verbindingsmethode van het platform, als die er is. Meta Events Manager toont de verbindingsmethode van elk event en telt de events daar vóór ontdubbeling. Gebruik niet de toegeschreven aankopen uit het advertentierapport.

4. Deel

   Browseraankopen ÷ webbestellingen is het aandeel dat de pixel heeft gezien. De rest is je gat.

5. Scheid toestemming van blokkades

   Schat de bestellingen van bezoekers die marketingcookies hebben geweigerd, met het weigeringspercentage uit je toestemmingstool. Wat overblijft, komt vooral door adblockers, privacyinstellingen en pagina's die niet zijn geladen.

Het gat verandert ook de ROAS. Stel dat Meta voor deze webshop een ROAS van 2.0 meldt en de break-even-ROAS 2.3 is. Op basis van pixeldata verliezen de campagnes geld. Als advertentiebestellingen net zo vaak werden gemist als alle webbestellingen, namelijk 24%, zag de pixel slechts 76% van de advertentieomzet. De echte ROAS zou dan ongeveer 2.0 ÷ 0.76 = 2.6 zijn, boven break-even. Dit is een bovengrens, omdat niet elke ontbrekende bestelling van een advertentie kwam. In onze gids over break-even-ROAS lees je hoe je die drempel bepaalt.

Zo beperk je wat je verliest

De oplossingen zijn voor elk webshopplatform hetzelfde. Ze werken het best samen.

1. Verstuur aankopen uit bestelgegevens. Zo dicht je het aankoopgat voor elk platform dat je koppelt, wat de browser van de bezoeker ook blokkeert.
2. Houd de pixel, met een gedeeld event-id. Bezoekers zonder blocker versturen nog steeds browserevents met cookies en paginacontext. Met hetzelfde event-id op beide exemplaren kan het platform er één bewaren. Zie dubbeltelling voorkomen.
3. Verzamel first-party. Serveer het trackingscript en de events vanaf je eigen domein, zodat click-id's voor meer bezoekers worden opgeslagen.
4. Verstuur gehashte klantgegevens. Met het e-mailadres en telefoonnummer uit de bestelling kan het platform aankopen koppelen die geen click-id hebben.
5. Meet opnieuw. Herhaal de vergelijking een maand later. De Purchase-events die het platform ontvangt, moeten nu overeenkomen met je webbestellingen.

Hoe ROASaurus omgaat met adblockers

ROASaurus verstuurt elke betaalde bestelling server-side naar de advertentieplatforms die je toevoegt onder Tracking & platforms, zodat een adblocker in de browser van de shopper de aankoop niet tegenhoudt. Op Shopify lopen de events van de storefront via de app-proxy van Shopify op je eigen webshopdomein. Je kunt het script en de events ook serveren vanaf een CNAME-subdomein van je site. Als een bezoeker geen browsercontact heeft, valt de attributie van ROASaurus terug op de click-id's en UTM's in de landings-URL van de bestelling, als de webshop die vastlegt, zoals Shopify doet.

Elke verzending en het antwoord van het platform staan in de Event log, zodat je kunt controleren of elke bestelling elk platform heeft bereikt. Zie server-side tracking en de Shopify-integratie voor de installatie.

Bronnen

1. EasyList: Overview
2. Brave: Brave Shields
3. MDN Web Docs: Firefox tracking protection
4. WebKit: Tracking Prevention in WebKit
5. Meta for Developers: Verifying Your Setup

In ROASaurus

• Server-side tracking in ROASaurus
• Dubbeltelling voorkomen
• Toestemming en privacy

Lees verder