Safari ITP en advertentietracking: wat nog werkt

Intelligent Tracking Prevention (ITP) van Safari beperkt hoe lang een website een terugkerende bezoeker kan herkennen. Het blokkeert alle cookies van derden en beperkt cookies die door JavaScript worden gezet tot 7 dagen, of tot 24 uur na sommige advertentieklikken. Aankopen die server-side vanuit je bestelgegevens worden verstuurd, click-id's die worden opgeslagen wanneer de shopper landt en gehashte klantgegevens werken nog steeds.

Deze gids legt elke ITP-regel uit zoals WebKit die documenteert, wat de regels doen met attributieperiodes en remarketing en welke trackingmethoden nog werken voor een webshop. Hij eindigt met een manier om te controleren hoeveel Safari je eigen webshop beïnvloedt.

Wat is Safari ITP?

Intelligent Tracking Prevention is een geheel van privacybeschermingen in WebKit, de browser-engine achter Safari op Mac, iPhone en iPad. WebKit heeft het vele malen uitgebreid en documenteert de huidige regels op zijn pagina Tracking Prevention.

Sommige ITP-regels gelden voor elke website. Andere gelden alleen voor domeinen die ITP heeft geclassificeerd als domeinen met cross-site trackingmogelijkheden, op basis van hoe die domeinen zich gedragen op de sites die iemand bezoekt. ITP staat standaard aan, dus het raakt elke Safari-bezoeker van je webshop, niet alleen privacybewuste.

Wat zijn de cookielimieten in Safari ITP?

De limiet van 7 dagen op scriptcookies

De meeste pixels en analysetools schrijven hun eigen first-party cookies met JavaScript. De Meta-pixel bewaart bijvoorbeeld een browser-id in een cookie met de naam _fbp. In Safari verwijdert ITP cookies en andere opslag die door JavaScript is aangemaakt na 7 dagen zonder interactie van de gebruiker op je site. WebKit definieert interactie van de gebruiker als een klik, een tik of een toetsaanslag. Scrollen telt niet.

In de praktijk houdt een shopper die terugkomt en je site binnen 7 dagen gebruikt meestal de cookie. Een shopper die meer dan 7 dagen wegblijft, komt terug zonder cookie en lijkt een nieuwe bezoeker.

De limiet van 24 uur na een decorated link

Advertentieplatforms voegen click-id's toe aan de links in hun advertenties. WebKit noemt dit link decoration. Wanneer een domein dat ITP als tracker heeft geclassificeerd de bezoeker naar je pagina stuurt en de uiteindelijke URL een querystring of fragment heeft, worden cookies die JavaScript op die landingspagina schrijft beperkt tot 24 uur. De limiet geldt voor de pagina die via die navigatie wordt bereikt, niet voor de site als geheel.

Cookies van derden

Safari blokkeert standaard alle cookies van derden, en WebKit zegt dat er geen uitzonderingen op die blokkade zijn. Een derde partij kan alleen toegang vragen via mechanismen zoals de Storage Access API. Een advertentieplatform kan dus zijn eigen cookie niet lezen vanuit je pagina's. Het is afhankelijk van de first-party cookies die zijn pixel schrijft, en die vallen onder de regels van 7 dagen en 24 uur.

CNAME- en IP-adrescloaking

Een veelgebruikte omweg is een trackingsubdomein, zoals t.yourstore.com, dat naar een trackingserver verwijst. Cookies van dat subdomein worden gezet in het HTTP-antwoord, dus het zijn geen scriptcookies. WebKit behandelt het subdomein als gecamoufleerd wanneer het via een CNAME naar een ander domein verwijst. Sinds Safari 17 behandelt het het subdomein ook als gecamoufleerd wanneer het IP-adres op een andere partij dan je site lijkt, bijvoorbeeld wanneer de twee adressen in duidelijk verschillende netwerkbereiken liggen. In beide gevallen beperkt ITP de cookies die in het antwoord worden gezet tot 7 dagen. Wie de server bezit, maakt voor deze regels niet uit.

Hoe gaat Safari om met click-id's in links?

Een click-id zoals fbclid of gclid maakt deel uit van de URL van de landingspagina. Bij normaal browsen laadt Safari de URL met zijn parameters, dus een script op de landingspagina kan het click-id lezen. De limiet van 24 uur hierboven beperkt hoe lang een cookie die op die pagina is geschreven meegaat. Het haalt het click-id niet uit de URL.

Privé-browsen gaat verder. Sinds Safari 17 geldt Link Tracking Protection wanneer de bezoeker van de ene website naar de andere navigeert, zoals van een advertentie naar je webshop. Safari verwijdert een reeks queryparameters waarvan WebKit heeft vastgesteld dat ze worden gebruikt voor cross-site tracking van gebruikers of klikken. De aankondiging van WebKit noemt de parameters niet. Het voorbeeld daarin verwijdert een trackingparameter en laat een campagneparameter staan. Op de landingspagina krijgen scripts van derden die de URL lezen hem ook zonder querystring. Dezelfde beschermingen zijn bij normaal browsen beschikbaar voor mensen die geavanceerde bescherming tegen tracking en fingerprinting voor al het browsen inschakelen.

Hoe zit het met Private Relay en IP-adressen?

Volgens WebKit verbergt Safari sinds Safari 15 standaard IP-adressen voor bekende trackers. Mensen die voor iCloud+ betalen, kunnen ook iCloud Private Relay inschakelen. Dat stuurt Safari-verkeer via twee afzonderlijke relays, beheerd door verschillende partijen, zodat websites een relay-IP-adres zien in plaats van dat van de bezoeker zelf. Apple zegt dat het relay-adres de globale locatie van de bezoeker op stadsniveau behoudt, en dat meerdere gebruikers in hetzelfde gebied één adres kunnen delen.

Dit verzwakt tracking die op het IP-adres steunt, zoals het koppelen van een bezoeker op basis van IP-adres en browser. Het raakt click-id's, gehashte e-mailadressen of bestelgegevens niet. ROASaurus gebruikt een IP-match alleen als laatste redmiddel, en alleen wanneer precies één recente bezoeker met dat IP-adres en die browser past. Een gedeeld relay-adres leidt dan meestal tot geen match.

Wat betekent ITP voor attributieperiodes?

Een attributieperiode is het aantal dagen na een klik waarin een aankoop nog aan die klik kan worden toegeschreven. In ROASaurus kies je een attributieperiode van 1 tot 90 dagen, met 7 dagen als standaard. Advertentieplatforms hebben hun eigen instellingen. In Safari kan een opzet die alleen op browsercookies vertrouwt, een aankoop alleen aan een klik koppelen zolang de cookie leeft.

Het effect groeit met de periode. Een attributieperiode van 1 of 7 dagen is niet langer dan de levensduur van 7 dagen van een scriptcookie, tenzij de limiet van 24 uur geldt. Bij een attributieperiode van 28 dagen zijn aankopen op dag 8 of later van shoppers die tussendoor niet terugkwamen, afhankelijk van andere data.

Zo bepaal je de omvang hiervan voor een webshop. De cijfers zijn een voorbeeld; gebruik je eigen cijfers.

Wat betekent ITP voor remarketing?

Remarketingdoelgroepen worden opgebouwd uit browserevents, zoals mensen die een product bekeken of aan de winkelwagen toevoegden. In Safari kan het platform zijn cookies van derden niet gebruiken, en de first-party cookie van de pixel wordt na 7 dagen zonder bezoek verwijderd. Een Safari-bezoeker die na 8 dagen terugkomt, lijkt nieuw voor de pixel. De eerdere productweergaven zijn in de browser niet meer aan die bezoeker gekoppeld.

Daar volgen twee effecten uit. Doelgroepen met lange looptijden, zoals 30 of 180 dagen, houden minder Safari-bezoekers vast dan de looptijd doet vermoeden. Je analytics toont ook meer nieuwe en minder terugkerende bezoekers dan je werkelijk hebt. Klantlijstdoelgroepen die zijn opgebouwd uit gehashte e-mailadressen in je webshop of e-mailtool zijn niet van cookies afhankelijk, dus die worden niet op dezelfde manier geraakt.

Wat werkt nog in Safari?

Server-side events uit bestellingen

Een aankoop die vanuit de bestelgegevens van je webshop wordt verstuurd, hangt van geen enkele cookie in Safari af. De webshop registreert de bestelling, een server stuurt die naar de API van het platform en het platform ontvangt hem. Het event bevat het gehashte e-mailadres en telefoonnummer uit de bestelling. Het platform kan die koppelen aan een van zijn gebruikers en zijn eigen gegevens over advertentieklikken en -weergaven controleren, binnen zijn eigen attributieperiode. Lees wat server-side tracking is voor het volledige datapad.

Click-id's vastgelegd bij de landing

Het click-id staat in de URL van de eerste pagina. Een script kan het daar lezen en naar je server sturen, waar het samen met het bezoeker-id wordt opgeslagen. De kopie op de server verloopt niet na 7 dagen. Wat verloopt, is de browsercookie die een terugkerend bezoek koppelt aan die opgeslagen bezoeker. Andere data kan een bestelling nog steeds aan een opgeslagen klik koppelen, zoals een e-mailadres dat de shopper eerder in een aanmeldformulier gaf, of het click-id in de landings-URL van de sessie waarin de bestelling is geplaatst.

First-party dataverzameling, met de limiet van 7 dagen

Het tracking-script en de bijbehorende verzoeken vanaf je eigen domein aanbieden houdt de dataverzameling first-party, wat ook helpt tegen adblockers. Het zorgt er op zichzelf niet voor dat cookies langer meegaan. Een trackingsubdomein dat via een CNAME naar een ander domein verwijst, of dat WebKit als IP-adres van een derde partij ziet, valt onder de limiet van 7 dagen. Een ROASaurus-trackingsubdomein geeft het bezoeker-id opnieuw uit als HTTP-cookie, maar Safari kan die cookie nog steeds beperken tot 7 dagen. De app proxy van Shopify houdt verzoeken op het domein van je webshop, maar Shopify verwijdert cookies uit verzoeken en antwoorden van de app proxy, dus het bezoeker-id wordt daar door JavaScript geschreven en de regel van 7 dagen geldt.

Wat de shopper je vertelt

Shoppers kunnen je vertellen hoe ze je hebben gevonden, en dat antwoord hangt niet van cookies af. Een enquête na aankoop vraagt het na de checkout. In ROASaurus combineert het Total Impact-model het antwoord met de klikdata en geeft het de enquête 50% van de credit als er ook klikken zijn.

Zo controleer je hoeveel Safari je webshop beïnvloedt

1. Bepaal het aandeel Safari in je bestellingen

   Groepeer in je analysetool aankopen per browser. Tel Safari op Mac, iPhone en iPad.

2. Meet de tijd tussen klik en aankoop

   Zoek uit hoeveel bestellingen er meer dan 7 dagen na de advertentieklik komen. Vergelijk in het attributierapport van ROASaurus de attributieperiodes van 7, 14 en 28 dagen en kijk hoeveel credit verschuift.

3. Vergelijk pixelaankopen met bestellingen

   Tel de Purchase-events die je pixel heeft verstuurd, per browser gesplitst als je platform dat toestaat, en vergelijk ze met je bestellingen over dezelfde periode.

4. Controleer je serverevents

   Zorg dat elke betaalde bestelling server-side wordt verstuurd met gehasht e-mailadres en telefoonnummer, en dat de browser- en serverkopieën één event-id delen.

Als een groot deel van je bestellingen uit Safari komt en veel daarvan meer dan 7 dagen na de klik binnenkomen, rapporteren browsercookies alleen te weinig van je advertenties. Aankopen die uit bestelgegevens worden verstuurd, met gehashte klantgegevens, geven de advertentieplatforms een andere manier om die bestellingen te koppelen. Hoe ROASaurus dit doet, zie je op de pagina server-side tracking, en hoe het klikken crediteert bij attributie.

Bronnen

1. WebKit: Tracking Prevention in WebKit
2. WebKit: Intelligent Tracking Prevention 2.2
3. WebKit: CNAME Cloaking and Bounce Tracking Defense
4. WebKit: Private Browsing 2.0
5. Apple Developer: Prepare your network or web server for iCloud Private Relay

In ROASaurus

• Server-side tracking in ROASaurus
• Attributie in ROASaurus
• Funnels en gekoppelde domeinen

Lees verder