Safari ITP och annonstracking: vad som fortfarande fungerar

Safaris Intelligent Tracking Prevention (ITP) begränsar hur länge en webbplats kan känna igen en återkommande besökare. Den blockerar alla tredjepartscookies och begränsar cookies som sätts av JavaScript till 7 dagar, eller till 24 timmar efter vissa annonsklick. Köp som skickas server-side från din orderdata, klick-id:n som sparas när köparen landar och hashad kunddata fungerar fortfarande.

Den här guiden förklarar varje ITP-regel så som WebKit dokumenterar den, vad reglerna gör med attributionsfönster och remarketing, och vilka trackingmetoder som fortfarande fungerar för en webbshop. Den slutar med ett sätt att kontrollera hur mycket Safari påverkar din egen butik.

Vad är Safari ITP?

Intelligent Tracking Prevention är en uppsättning integritetsskydd i WebKit, webbläsarmotorn bakom Safari på Mac, iPhone och iPad. WebKit har utökat det många gånger och dokumenterar de nuvarande reglerna på sin sida Tracking Prevention.

Vissa ITP-regler gäller för alla webbplatser. Andra gäller bara domäner som ITP har klassificerat som att de har möjlighet till spårning över flera webbplatser, utifrån hur de domänerna beter sig på de webbplatser en person besöker. ITP är påslaget som standard, så det påverkar varje Safari-besökare i din butik, inte bara de integritetsmedvetna.

Vilka cookiebegränsningar finns i Safari ITP?

Gränsen på 7 dagar för skriptcookies

De flesta pixlar och analysverktyg skriver sina egna förstapartscookies med JavaScript. Meta-pixeln lägger till exempel ett webbläsar-id i en cookie som heter _fbp. I Safari raderar ITP cookies och annan lagring som skapats av JavaScript efter 7 dagar utan användarinteraktion på din webbplats. WebKit definierar användarinteraktion som ett klick, en tryckning eller ett tangenttryck. Scrollning räknas inte.

I praktiken behåller en köpare som kommer tillbaka och använder din webbplats inom 7 dagar oftast cookien. En köpare som håller sig borta i mer än 7 dagar kommer tillbaka utan den och ser ut som en ny besökare.

Gränsen på 24 timmar efter en dekorerad länk

Annonsplattformar lägger till klick-id:n i länkarna i sina annonser. WebKit kallar det här länkdekoration. När en domän som ITP har klassificerat som en spårare skickar besökaren till din sida och den slutliga URL:en har en query string eller ett fragment, begränsas cookies som JavaScript skriver på den landningssidan till 24 timmar. Begränsningen gäller sidan som nåtts genom den navigeringen, inte webbplatsen som helhet.

Tredjepartscookies

Safari blockerar alla tredjepartscookies som standard, och WebKit säger att det inte finns några undantag från blockeringen. En tredje part kan bara be om åtkomst genom mekanismer som Storage Access API. En annonsplattform kan därför inte läsa sin egen cookie inifrån dina sidor. Den är beroende av de förstapartscookies som dess pixel skriver, vilka omfattas av reglerna på 7 dagar och 24 timmar.

CNAME- och IP-adressmaskering

En vanlig omväg är en trackingsubdomän, som t.yourstore.com, som pekar på en trackingserver. Cookies från den subdomänen sätts i HTTP-svaret, så de är inte skriptcookies. WebKit behandlar subdomänen som maskerad när den pekar via en CNAME till en annan domän. Sedan Safari 17 behandlar det också subdomänen som maskerad när dess IP-adress ser ut att tillhöra en annan part än din webbplats, till exempel när de två adresserna ligger i tydligt olika nätverksintervall. I båda fallen begränsar ITP de cookies som sätts i svaret till 7 dagar. Vem som äger servern spelar ingen roll för de här reglerna.

Hur hanterar Safari klick-id:n i länkar?

Ett klick-id som fbclid eller gclid är en del av landnings-URL:en. Vid normal surfning läser Safari in URL:en med dess parametrar, så ett skript på landningssidan kan läsa klick-id:t. Gränsen på 24 timmar ovan begränsar hur länge en cookie som skrivs på den sidan varar. Den tar inte bort klick-id:t från URL:en.

Privat surfning går längre. Sedan Safari 17 gäller Link Tracking Protection när besökaren navigerar från en webbplats till en annan, till exempel från en annons till din butik. Safari tar bort en uppsättning query-parametrar som WebKit har identifierat som använda för spårning av användare eller klick över webbplatsgränser. WebKits tillkännagivande listar inte parametrarna. Dess exempel tar bort en trackingparameter och behåller en kampanjparameter. På landningssidan får tredjepartsskript som läser URL:en den också utan query string. Samma skydd finns i normal surfning för personer som slår på avancerat skydd mot spårning och fingeravtryck för all surfning.

Hur är det med Private Relay och IP-adresser?

Enligt WebKit har Safari dolt IP-adresser för kända spårare som standard sedan Safari 15. Personer som betalar för iCloud+ kan också slå på iCloud Private Relay. Den skickar Safari-trafik genom två separata reläer, som drivs av olika operatörer, så att webbplatser ser en relä-IP-adress i stället för besökarens egen. Apple säger att relä-adressen behåller besökarens grova platsuppgift på stadsnivå, och att flera användare i samma område kan dela en adress.

Det försvagar tracking som bygger på IP-adressen, som att matcha en besökare på IP-adress och webbläsare. Det påverkar inte klick-id:n, hashade e-postadresser eller orderdata. ROASaurus använder en IP-matchning bara som en sista utväg, och bara när exakt en nyligen aktiv besökare med den IP-adressen och webbläsaren passar. En delad relä-adress leder då oftast till ingen matchning.

Vad betyder ITP för attributionsfönster?

Ett attributionsfönster är antalet dagar efter ett klick då ett köp fortfarande kan tillskrivas det klicket. I ROASaurus väljer du ett lookback-fönster från 1 till 90 dagar, med 7 dagar som standard. Annonsplattformar har egna inställningar. I Safari kan en uppsättning som bara förlitar sig på webbläsarcookies koppla ett köp till ett klick bara så länge cookien lever.

Effekten växer med fönstret. Ett fönster på 1 eller 7 dagar är inte längre än skriptcookiens livslängd på 7 dagar, såvida inte begränsningen på 24 timmar gäller. Med ett fönster på 28 dagar är köp på dag 8 eller senare från köpare som inte kom tillbaka däremellan beroende av andra data.

Så här uppskattar du omfattningen för en butik. Siffrorna är ett exempel; använd dina egna.

Vad betyder ITP för remarketing?

Remarketing-målgrupper byggs från webbläsarhändelser, som personer som tittade på en produkt eller la den i varukorgen. I Safari kan plattformen inte använda sina tredjepartscookies, och pixelns förstapartscookie raderas efter 7 dagar utan besök. En Safari-besökare som kommer tillbaka efter 8 dagar ser ny ut för pixeln. Deras tidigare produktvisningar är inte längre kopplade till dem i webbläsaren.

Två effekter följer. Målgrupper med långa varaktigheter, som 30 eller 180 dagar, behåller färre Safari-besökare än varaktigheten antyder. Din analys visar också fler nya besökare och färre återkommande än du egentligen har. Kundlistmålgrupper som byggs från hashade e-postadresser i din butik eller ditt e-postverktyg är inte beroende av cookies, så de påverkas inte på samma sätt.

Vad fungerar fortfarande i Safari?

Server-side-händelser från ordrar

Ett köp som skickas från din butiks orderdata är inte beroende av någon cookie i Safari. Butiken registrerar ordern, en server skickar den till plattformens API och plattformen tar emot den. Händelsen innehåller den hashade e-postadressen och det hashade telefonnumret från ordern. Plattformen kan matcha dem mot en av sina användare och kontrollera sina egna uppgifter om annonsklick och annonsvisningar, inom sitt eget attributionsfönster. Läs vad server-side tracking är för hela dataflödet.

Klick-id:n som fångas vid landning

Klick-id:t finns i URL:en på den första sidan. Ett skript kan läsa det där och skicka det till din server, där det lagras tillsammans med besökar-id:t. Serverkopian går inte ut efter 7 dagar. Det som går ut är webbläsarcookien som kopplar ett återkommande besök till den lagrade besökaren. Andra data kan fortfarande koppla en order till ett lagrat klick, som en e-postadress som köparen angav tidigare i ett registreringsformulär, eller klick-id:t i landnings-URL:en för den session som lade ordern.

Förstapartsinsamling, med gränsen på 7 dagar

Om du levererar trackingskriptet och dess anrop från din egen domän förblir insamlingen förstaparts, vilket också hjälper mot annonsblockerare. Det gör inte i sig att cookies varar längre. En trackingsubdomän som pekar via en CNAME till en annan domän, eller som WebKit ser som en tredjeparts-IP-adress, omfattas av gränsen på 7 dagar. En ROASaurus-trackingsubdomän utfärdar besökar-id:t på nytt som en HTTP-cookie, men Safari kan ändå begränsa den cookien till 7 dagar. Shopifys app proxy håller anropen på din butiksdomän, men Shopify tar bort cookies från app proxy-anrop och -svar, så besökar-id:t där skrivs av JavaScript och regeln på 7 dagar gäller.

Det köparen berättar för dig

Köpare kan berätta hur de hittade dig, och det svaret är inte beroende av cookies. En enkät efter köp frågar efter kassan. I ROASaurus kombinerar Total Impact-modellen svaret med klickdata och ger enkäten 50% av krediten när det också finns klick.

Så kontrollerar du hur mycket Safari påverkar din butik

1. Ta reda på Safaris andel av dina ordrar

   Gruppera köp efter webbläsare i ditt analysverktyg. Räkna Safari på Mac, iPhone och iPad.

2. Mät tiden från klick till köp

   Ta reda på hur många ordrar som kommer mer än 7 dagar efter annonsklicket. Jämför fönstren på 7, 14 och 28 dagar i ROASaurus attributionsrapport och se hur mycket kredit som flyttas.

3. Jämför pixelköp med ordrar

   Räkna de Purchase-händelser som din pixel skickade, uppdelade efter webbläsare om din plattform tillåter det, och jämför dem med dina ordrar för samma period.

4. Kontrollera dina serverhändelser

   Se till att varje betald order skickas server-side med hashad e-post och hashat telefonnummer, och att webbläsarkopian och serverkopian delar ett händelse-id.

Om en stor andel av dina ordrar kommer från Safari, och många av dem kommer mer än 7 dagar efter klicket, kommer enbart webbläsarcookies att underrapportera dina annonser. Köp som skickas från orderdata, med hashad kunddata, ger annonsplattformarna ett annat sätt att matcha de ordrarna. Hur ROASaurus gör det ser du på sidan server-side tracking, och hur klick krediteras finns i attribution.

Källor

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

I ROASaurus

• Server-side tracking i ROASaurus
• Attribution i ROASaurus
• Funnels och länkade domäner

Läs vidare