- Safari ITP blokkerer alle tredjepartscookies og begrenser cookies satt av JavaScript til 7 dager, eller til 24 timer på en landingsside som nås gjennom en dekorert lenke fra et domene den klassifiserer som en tracker.
- Cookies satt av et trackingunderdomene som peker til et annet domene via en CNAME, eller som WebKit ser som en tredjeparts IP-adresse, begrenses også til 7 dager, så et trackingunderdomene unngår ikke begrensningen.
- En Safari-kunde som kjøper mer enn 7 dager etter det siste besøket, ser vanligvis ny ut for nettleserbasert tracking, noe som forkorter attribusjonsvinduer og remarketing-målgrupper.
- Kjøp som sendes fra bestillingsdata, click id-er som lagres på serveren ved landing, og hashede kundedata fortsetter å fungere, fordi de ikke avhenger av en cookie i Safari.
Safaris Intelligent Tracking Prevention (ITP) begrenser hvor lenge et nettsted kan gjenkjenne en tilbakevendende besøkende. Den blokkerer alle tredjepartscookies og begrenser cookies satt av JavaScript til 7 dager, eller til 24 timer etter enkelte annonseklikk. Kjøp som sendes server-side fra bestillingsdataene dine, click id-er som lagres når kunden lander, og hashede kundedata fungerer fortsatt.
Denne guiden forklarer hver ITP-regel slik WebKit dokumenterer den, hva reglene gjør med attribusjonsvinduer og remarketing, og hvilke trackingmetoder som fortsatt fungerer for en nettbutikk. Den avsluttes med en måte å sjekke hvor mye Safari påvirker din egen butikk.
Hva er Safari ITP?
Intelligent Tracking Prevention er et sett med personvernbeskyttelser i WebKit, nettlesermotoren bak Safari på Mac, iPhone og iPad. WebKit har utvidet den mange ganger, og dokumenterer de gjeldende reglene på siden Tracking Prevention.
Noen ITP-regler gjelder for alle nettsteder. Andre gjelder bare for domener som ITP har klassifisert som å ha muligheter for sporing på tvers av nettsteder, basert på hvordan disse domenene oppfører seg på tvers av nettstedene en person besøker. ITP er på som standard, så den påvirker alle Safari-besøkende i nettbutikken din, ikke bare de som er opptatt av personvern.
Hva er cookiebegrensningene i Safari ITP?
| Det som lagres | Eksempel | Begrensning i Safari |
|---|---|---|
| Tredjepartscookies | En annonseplattforms egne cookies, sendt med forespørslene den gjør fra siden din | Blokkert |
| Cookies og lagring skrevet av JavaScript | En pixels førsteparts nettleser-ID, en cookie med besøks-ID, localStorage | Slettes etter 7 dager uten brukerinteraksjon |
| Cookies skrevet av JavaScript etter en dekorert lenke | Landingssiden, når et klassifisert domene sendte den besøkende med en query string eller et fragment i URL-en | Begrenset til 24 timer |
| Cookies satt av en server via et kamuflert underdomene | Et trackingunderdomene som peker til et annet domene via en CNAME, eller kjører på en tredjeparts IP-adresse | Begrenset til 7 dager |
| Cookies satt av nettserveren til nettstedet ditt | En økt- eller handlekurvcookie satt i HTTP-svaret fra nettbutikken din | Ikke begrenset av disse reglene |
7-dagersgrensen for skriptcookies
De fleste pixler og analyseverktøy skriver sine egne førstepartscookies med JavaScript. Meta-pixelen holder for eksempel en nettleser-ID i en cookie som heter _fbp. I Safari sletter ITP cookies og annen lagring som er opprettet av JavaScript etter 7 dager uten brukerinteraksjon på nettstedet ditt. WebKit definerer brukerinteraksjon som et klikk, et trykk eller et tastetrykk. Scrolling teller ikke.
I praksis beholder en kunde som kommer tilbake og bruker nettstedet ditt innen 7 dager, vanligvis cookien. En kunde som holder seg borte i mer enn 7 dager, kommer tilbake uten den og ser ut som en ny besøkende.
24-timersgrensen etter en dekorert lenke
Annonseplattformer legger click id-er til i lenkene i annonsene sine. WebKit kaller dette lenkedekorering. Når et domene som ITP har klassifisert som en tracker, sender den besøkende til siden din, og den endelige URL-en har en query string eller et fragment, begrenses cookies som JavaScript skriver på den landingssiden, til 24 timer. Begrensningen gjelder siden som nås gjennom den navigasjonen, ikke nettstedet som helhet.
Tredjepartscookies
Safari blokkerer alle tredjepartscookies som standard, og WebKit sier at det ikke finnes unntak fra denne blokkeringen. En tredjepart kan bare be om tilgang gjennom mekanismer som Storage Access API. En annonseplattform kan derfor ikke lese sin egen cookie fra innsiden av sidene dine. Den er avhengig av førstepartscookiene pixelen skriver, som faller under 7-dagers- og 24-timersreglene.
Kamuflering med CNAME og IP-adresse
En vanlig omvei er et trackingunderdomene, som t.yourstore.com, som peker til en trackingserver. Cookies fra det underdomenet settes i HTTP-svaret, så de er ikke skriptcookies. WebKit behandler underdomenet som kamuflert når det peker via en CNAME til et annet domene. Siden Safari 17 behandler den også underdomenet som kamuflert når IP-adressen ser ut som en annen part enn nettstedet ditt, for eksempel når de to adressene ligger i tydelig forskjellige nettverksområder. I begge tilfeller begrenser ITP cookies satt i svaret til 7 dager. Hvem som eier serveren, spiller ingen rolle for disse reglene.
Hvordan håndterer Safari click id-er i lenker?
En click id som fbclid eller gclid er en del av landings-URL-en. Ved vanlig surfing laster Safari URL-en med parameterne, så et skript på landingssiden kan lese click id-en. 24-timersgrensen ovenfor begrenser hvor lenge en cookie skrevet på den siden varer. Den fjerner ikke click id-en fra URL-en.
Privat surfing går lenger. Siden Safari 17 gjelder Link Tracking Protection når den besøkende navigerer fra ett nettsted til et annet, for eksempel fra en annonse til nettbutikken din. Safari fjerner et sett med query-parametere som WebKit har identifisert som brukt til sporing av brukere eller klikk på tvers av nettsteder. WebKits kunngjøring lister ikke opp parameterne. Eksemplet deres fjerner en sporingsparameter og beholder en kampanjeparameter. På landingssiden får tredjepartsskript som leser URL-en, den også uten query string. De samme beskyttelsene er tilgjengelige ved vanlig surfing for folk som slår på avansert beskyttelse mot sporing og fingerprinting for all surfing.
Hva med Private Relay og IP-adresser?
Ifølge WebKit har Safari skjult IP-adresser fra kjente trackere som standard siden Safari 15. Folk som betaler for iCloud+ kan også slå på iCloud Private Relay. Den sender Safari-trafikk gjennom to separate relayer, drevet av ulike operatører, så nettsteder ser en relay-IP-adresse i stedet for den besøkendes egen. Apple sier at relay-adressen beholder den besøkendes grove plassering på bynivå, og at flere brukere i det samme området kan dele én adresse.
Dette svekker tracking som baserer seg på IP-adressen, som å matche en besøkende på IP-adresse og nettleser. Det påvirker ikke click id-er, hashede e-postadresser eller bestillingsdata. ROASaurus bruker en IP-match bare som siste utvei, og bare når nøyaktig én nylig besøkende med den IP-adressen og nettleseren passer. En delt relay-adresse fører da vanligvis til ingen match.
Hva betyr ITP for attribusjonsvinduer?
Et attribusjonsvindu er antall dager etter et klikk der et kjøp fortsatt kan krediteres det klikket. I ROASaurus velger du et attribusjonsvindu fra 1 til 90 dager, med 7 dager som standard. Annonseplattformer har sine egne innstillinger. I Safari kan et oppsett som bare bygger på nettlesercookies koble et kjøp til et klikk bare så lenge cookien lever.
Day 0 landing ?fbclid=IwAR...Click id lagret på serveren med besøks-ID v-81f2Day 0 _fbp, visitor idCookies skrevet av JavaScript, begrenset til 7 dager på det mesteDay 4 visitSamme besøkende: cookiene brukes og skrives på nyttDay 13 visitNi dager uten besøk: cookiene er borte, så dette ser ut som en ny besøkendeDay 13 Purchase pixel order-2087Ingen kobling i nettleseren til klikket på dag 0Day 13 Purchase server order-2087Sendt fra bestillingen med hashet e-post, slik at plattformen kan matche kjøperen selvEffekten vokser med vinduet. Et vindu på 1 eller 7 dager er ikke lengre enn de 7 dagene en skriptcookie lever, med mindre 24-timersgrensen gjelder. Med et vindu på 28 dager er kjøp på dag 8 eller senere fra kunder som ikke kom tilbake i mellomtiden, avhengige av andre data.
Slik anslår du omfanget for en butikk. Tallene er et eksempel; bruk dine egne.
| Eksempelbutikk, 30 dager | Verdi |
|---|---|
| Bestillinger fra annonseklikk | 1,000 |
| Lagt inn i Safari | 400 (40%) |
| Safari-bestillinger lagt inn mer enn 7 dager etter klikket | 72 (18% av 400) |
| Andel annonsedrevne bestillinger i fare for et oppsett kun med nettleser | 72 ÷ 1,000 = 7.2% |
Hva betyr ITP for remarketing?
Remarketing-målgrupper bygges fra nettleser-events, for eksempel folk som har sett på et produkt eller lagt det i handlekurven. I Safari kan ikke plattformen bruke tredjepartscookiene sine, og pixelens førstepartscookie slettes etter 7 dager uten besøk. En Safari-besøkende som kommer tilbake etter 8 dager, ser ny ut for pixelen. De tidligere produktvisningene deres er ikke lenger koblet til dem i nettleseren.
To effekter følger av dette. Målgrupper med lang varighet, som 30 eller 180 dager, beholder færre Safari-besøkende enn varigheten tilsier. Analyseverktøyet ditt viser også flere nye besøkende og færre tilbakevendende enn du egentlig har. Kundelistemålgrupper bygget fra hashede e-postadresser i butikken eller e-postverktøyet ditt, er ikke avhengige av cookies, så de påvirkes ikke på samme måte.
Hva fungerer fortsatt i Safari?
- Tredjepartscookies fra annonseplattformer
- Pixelcookies etter 7 dager uten besøk
- Pixelcookies etter 24 timer på enkelte annonselandinger
- Servercookies via en CNAME eller en tredjeparts IP-adresse: 7 dager
- IP-adressen som matchenøkkel, med Private Relay
- Kjøp sendt fra bestillingsdata
- Click id-er lagret på serveren ved landing
- Hashet e-post og telefon i server-events
- Click id-er og UTM-er i landings-URL-en til bestillingen
- Svar fra en undersøkelse etter kjøp
Server-side events fra bestillinger
Et kjøp som sendes fra bestillingsdataene i butikken din, avhenger ikke av noen cookie i Safari. Butikken registrerer bestillingen, en server sender den til plattformens API, og plattformen mottar den. Eventen inneholder den hashede e-posten og det hashede telefonnummeret fra bestillingen. Plattformen kan matche dem med en av sine brukere og sjekke sine egne registreringer av annonseklikk og visninger, innenfor sitt eget attribusjonsvindu. Les hva server-side tracking er for hele datastien.
Click id-er fanget ved landing
Click id-en står i URL-en til den første siden. Et skript kan lese den der og sende den til serveren din, der den lagres sammen med besøks-ID-en. Serverkopien utløper ikke etter 7 dager. Det som utløper, er nettlesercookien som kobler et tilbakevendende besøk til den lagrede besøkende. Andre data kan fortsatt koble en bestilling til et lagret klikk, som en e-postadresse kunden har oppgitt tidligere i et registreringsskjema, eller click id-en i landings-URL-en til økten som la inn bestillingen.
Førsteparts innsamling, med 7-dagersgrensen
Å kjøre trackingskriptet og forespørslene via ditt eget domene holder innsamlingen førsteparts, noe som også hjelper mot annonseblokkere. Det gjør ikke cookies mer langlivede i seg selv. Et trackingunderdomene som peker via en CNAME til et annet domene, eller som WebKit ser som en tredjeparts IP-adresse, faller under 7-dagersgrensen. Et ROASaurus-trackingunderdomene utsteder besøks-ID-en på nytt som en HTTP-cookie, men Safari kan fortsatt begrense den cookien til 7 dager. Shopifys app proxy holder forespørslene på butikkdomenet ditt, men Shopify fjerner cookies fra forespørsler og svar via app proxy, så besøks-ID-en der skrives av JavaScript, og 7-dagersregelen gjelder.
Det kunden forteller deg
Kunder kan fortelle deg hvordan de fant deg, og det svaret er ikke avhengig av cookies. En undersøkelse etter kjøp spør etter checkout. I ROASaurus kombinerer Total Impact-modellen svaret med klikkdataene, og gir undersøkelsen 50% av kreditten når det også finnes klikk.
Slik sjekker du hvor mye Safari påvirker nettbutikken din
- Finn Safaris andel av bestillingene dine
Grupper kjøp etter nettleser i analyseverktøyet ditt. Tell Safari på Mac, iPhone og iPad.
- Mål tiden fra klikk til kjøp
Finn ut hvor mange bestillinger som kommer mer enn 7 dager etter annonseklikket. I attribusjonsrapporten i ROASaurus sammenligner du vinduene på 7, 14 og 28 dager og ser hvor mye kreditt som flyttes.
- Sammenlign pixelkjøp med bestillinger
Tell Purchase-eventene pixelen din sendte, delt etter nettleser hvis plattformen din tillater det, og sammenlign dem med bestillingene dine for samme periode.
- Sjekk server-eventene dine
Sørg for at hver betalte bestilling sendes server-side med hashet e-post og telefon, og at nettleser- og serverkopiene deler én event-ID.
Hvis en stor andel av bestillingene dine kommer fra Safari, og mange av dem kommer mer enn 7 dager etter klikket, vil nettlesercookies alene underrapportere annonsene dine. Kjøp som sendes fra bestillingsdata, med hashede kundedata, gir annonseplattformene en annen måte å matche disse bestillingene på. Du kan se hvordan ROASaurus gjør dette på siden om server-side tracking, og hvordan klikk krediteres i attribusjon.
Kilder
- WebKit: Tracking Prevention in WebKit
- WebKit: Intelligent Tracking Prevention 2.2
- WebKit: CNAME Cloaking and Bounce Tracking Defense
- WebKit: Private Browsing 2.0
- Apple Developer: Prepare your network or web server for iCloud Private Relay