Safari ITP și tracking-ul reclamelor: ce mai funcționează

Intelligent Tracking Prevention (ITP) din Safari limitează cât timp poate recunoaște un site web un vizitator care revine. Blochează toate cookie-urile third-party și limitează cookie-urile setate de JavaScript la 7 zile sau la 24 de ore după unele click-uri pe reclame. Achizițiile trimise server-side din datele comenzii, click id-urile salvate când ajunge cumpărătorul și datele clientului cu hash continuă să funcționeze.

Acest ghid explică fiecare regulă ITP așa cum o documentează WebKit, ce fac regulile cu ferestrele de atribuire și cu remarketingul și ce metode de tracking mai funcționează pentru un magazin online. Se încheie cu o modalitate de a verifica cât de mult îți afectează Safari propriul magazin.

Ce este Safari ITP?

Intelligent Tracking Prevention este un set de protecții de confidențialitate din WebKit, motorul de browser din spatele Safari pe Mac, iPhone și iPad. WebKit l-a extins de multe ori și documentează regulile actuale pe pagina sa Tracking Prevention.

Unele reguli ITP se aplică fiecărui site web. Altele se aplică doar domeniilor pe care ITP le-a clasificat ca având capacități de tracking cross-site, pe baza modului în care se comportă acele domenii pe site-urile pe care le vizitează o persoană. ITP este activat implicit, deci afectează fiecare vizitator Safari al magazinului tău, nu doar pe cei atenți la confidențialitate.

Care sunt limitele pentru cookie-uri în Safari ITP?

Limita de 7 zile pentru cookie-urile scrise de scripturi

Majoritatea pixelilor și a instrumentelor de analiză își scriu propriile cookie-uri first-party cu JavaScript. Pixelul Meta, de exemplu, păstrează un id de browser într-un cookie numit _fbp. În Safari, ITP șterge cookie-urile și alt spațiu de stocare create de JavaScript după 7 zile fără interacțiunea utilizatorului pe site-ul tău. WebKit definește interacțiunea utilizatorului ca un click, o atingere sau o apăsare de tastă. Derularea nu contează.

În practică, un cumpărător care revine și folosește site-ul tău în 7 zile își păstrează de obicei cookie-ul. Un cumpărător care lipsește mai mult de 7 zile revine fără el și arată ca un vizitator nou.

Limita de 24 de ore după un link decorat

Platformele de publicitate adaugă click id-uri la linkurile din reclamele lor. WebKit numește asta decorarea linkurilor. Când un domeniu pe care ITP l-a clasificat drept tracker trimite vizitatorul pe pagina ta, iar URL-ul final are un șir de interogare sau un fragment, cookie-urile pe care JavaScript le scrie pe acea pagină de destinație sunt limitate la 24 de ore. Limita se aplică paginii la care se ajunge prin acea navigare, nu site-ului în ansamblu.

Cookie-uri third-party

Safari blochează implicit toate cookie-urile third-party, iar WebKit spune că această blocare nu are excepții. O parte terță poate cere acces doar prin mecanisme precum Storage Access API. O platformă de publicitate nu își poate deci citi propriul cookie din interiorul paginilor tale. Depinde de cookie-urile first-party pe care le scrie pixelul ei, care intră sub regulile de 7 zile și de 24 de ore.

Mascarea prin CNAME și adresă IP

O soluție ocolitoare frecventă este un subdomeniu de tracking, precum t.yourstore.com, care trimite spre un server de tracking. Cookie-urile de la acel subdomeniu sunt setate în răspunsul HTTP, deci nu sunt cookie-uri scrise de scripturi. WebKit tratează subdomeniul ca mascat când trimite printr-un CNAME spre un alt domeniu. Începând cu Safari 17, îl tratează ca mascat și când adresa lui IP pare a aparține unei alte părți decât site-ul tău, de exemplu când cele două adrese se află în intervale de rețea clar diferite. În ambele cazuri, ITP limitează la 7 zile cookie-urile setate în răspuns. Cine deține serverul nu contează pentru aceste reguli.

Cum tratează Safari click id-urile din linkuri?

Un click id precum fbclid sau gclid face parte din URL-ul paginii de destinație. În navigarea obișnuită, Safari încarcă URL-ul cu parametrii lui, deci un script de pe pagina de destinație poate citi click id-ul. Limita de 24 de ore de mai sus restrânge cât durează un cookie scris pe acea pagină. Nu elimină click id-ul din URL.

Private Browsing merge mai departe. Începând cu Safari 17, Link Tracking Protection se aplică atunci când vizitatorul navighează de pe un site pe altul, de exemplu de la o reclamă la magazinul tău. Safari elimină un set de parametri de interogare pe care WebKit i-a identificat ca fiind folosiți pentru urmărirea cross-site a utilizatorilor sau a click-urilor. Anunțul WebKit nu listează parametrii. Exemplul lui elimină un parametru de urmărire și păstrează un parametru de campanie. Pe pagina de destinație, scripturile third-party care citesc URL-ul îl primesc și ele fără șirul de interogare. Aceleași protecții sunt disponibile și în navigarea obișnuită pentru persoanele care activează protecția avansată împotriva urmăririi și a fingerprinting-ului pentru toată navigarea.

Dar Private Relay și adresele IP?

Potrivit WebKit, Safari ascunde implicit adresele IP față de trackerele cunoscute începând cu Safari 15. Persoanele care plătesc pentru iCloud+ pot activa și iCloud Private Relay. Acesta trimite traficul Safari prin două relee separate, administrate de operatori diferiți, astfel încât site-urile văd o adresă IP de releu în loc de cea proprie a vizitatorului. Apple spune că adresa releului păstrează locația aproximativă a vizitatorului, la nivel de oraș, și că mai mulți utilizatori din aceeași zonă pot folosi aceeași adresă.

Aceasta slăbește tracking-ul care se bazează pe adresa IP, cum ar fi potrivirea unui vizitator după adresa IP și browser. Nu afectează click id-urile, adresele de email cu hash sau datele comenzii. ROASaurus folosește o potrivire după IP doar ca ultimă soluție și doar când se potrivește exact un singur vizitator recent cu acea adresă IP și acel browser. O adresă de releu partajată duce atunci de obicei la lipsa unei potriviri.

Ce înseamnă ITP pentru ferestrele de atribuire?

O fereastră de atribuire este numărul de zile după un click în care o achiziție mai poate fi atribuită acelui click. În ROASaurus alegi o fereastră lookback de la 1 la 90 de zile, cu 7 zile implicit. Platformele de publicitate au propriile setări. În Safari, o configurație care se bazează doar pe cookie-urile din browser poate lega o achiziție de un click doar cât timp trăiește cookie-ul.

Efectul crește odată cu fereastra. O fereastră de 1 zi sau de 7 zile nu este mai lungă decât durata de viață de 7 zile a unui cookie scris de script, cu excepția cazului în care se aplică limita de 24 de ore. Cu o fereastră de 28 de zile, achizițiile din ziua 8 sau mai târziu ale cumpărătorilor care nu au revenit între timp depind de alte date.

Iată cum poți dimensiona asta pentru un magazin. Cifrele sunt un exemplu; folosește-le pe ale tale.

Ce înseamnă ITP pentru remarketing?

Audiențele de remarketing sunt construite din evenimente din browser, precum persoanele care au văzut un produs sau l-au adăugat în coș. În Safari, platforma nu își poate folosi cookie-urile third-party, iar cookie-ul first-party al pixelului este șters după 7 zile fără o vizită. Un vizitator Safari care revine după 8 zile pare nou pentru pixel. Vizualizările lui anterioare de produse nu îi mai sunt asociate în browser.

Rezultă două efecte. Audiențele cu durate lungi, precum 30 sau 180 de zile, păstrează mai puțini vizitatori Safari decât sugerează durata. Analiza ta arată și mai mulți vizitatori noi și mai puțini vizitatori care revin decât ai în realitate. Audiențele din liste de clienți construite din adrese de email cu hash din magazinul sau instrumentul tău de email nu depind de cookie-uri, deci nu sunt afectate în același fel.

Ce mai funcționează în Safari?

Evenimente server-side din comenzi

O achiziție trimisă din datele comenzii magazinului tău nu depinde de niciun cookie din Safari. Magazinul înregistrează comanda, un server o trimite către API-ul platformei, iar platforma o primește. Evenimentul include emailul și numărul de telefon cu hash din comandă. Platforma le poate potrivi cu unul dintre utilizatorii ei și poate verifica propriile înregistrări de click-uri și vizualizări ale reclamelor, în propria fereastră de atribuire. Citește ce este tracking-ul server-side pentru traseul complet al datelor.

Click id-uri captate la aterizare

Click id-ul se află în URL-ul primei pagini. Un script îl poate citi de acolo și îl poate trimite serverului tău, unde este stocat împreună cu id-ul vizitatorului. Copia de pe server nu expiră după 7 zile. Ce expiră este cookie-ul din browser care leagă o vizită care revine de acel vizitator stocat. Alte date pot lega în continuare o comandă de un click stocat, precum o adresă de email dată mai devreme de cumpărător într-un formular de înscriere sau click id-ul din URL-ul paginii de destinație al sesiunii care a plasat comanda.

Colectare first-party, cu limita de 7 zile

Servirea scriptului de tracking și a cererilor lui de pe propriul tău domeniu menține colectarea first-party, ceea ce ajută și împotriva ad blockerelor. Nu face singură cookie-urile să dureze mai mult. Un subdomeniu de tracking care trimite printr-un CNAME spre alt domeniu sau pe care WebKit îl vede ca pe o adresă IP third-party intră sub limita de 7 zile. Un subdomeniu de tracking ROASaurus reemite id-ul vizitatorului ca cookie HTTP, dar Safari poate totuși limita acel cookie la 7 zile. App proxy-ul Shopify păstrează cererile pe domeniul magazinului tău, dar Shopify elimină cookie-urile din cererile și răspunsurile app proxy, așa că id-ul vizitatorului de acolo este scris de JavaScript și se aplică regula de 7 zile.

Ce îți spune cumpărătorul

Cumpărătorii îți pot spune cum te-au găsit, iar acest răspuns nu depinde de cookie-uri. Un sondaj post-achiziție întreabă după checkout. În ROASaurus, modelul Total Impact combină răspunsul cu datele despre click-uri și dă sondajului 50% din merit când există și click-uri.

Cum verifici cât de mult afectează Safari magazinul tău

1. Află ponderea Safari în comenzile tale

   În instrumentul tău de analiză, grupează achizițiile după browser. Numără Safari pe Mac, iPhone și iPad.

2. Măsoară timpul de la click până la achiziție

   Află câte comenzi vin la mai mult de 7 zile după click-ul pe reclamă. În raportul de atribuire ROASaurus, compară ferestrele de 7, 14 și 28 de zile și vezi cât merit se mută.

3. Compară achizițiile din pixel cu comenzile

   Numără evenimentele Purchase trimise de pixelul tău, împărțite pe browser dacă platforma ta permite, și compară-le cu comenzile din aceeași perioadă.

4. Verifică-ți evenimentele de pe server

   Asigură-te că fiecare comandă plătită este trimisă server-side cu email și telefon cu hash și că exemplarele din browser și de pe server au același event id.

Dacă o pondere mare dintre comenzile tale vin din Safari, iar multe dintre ele vin la mai mult de 7 zile după click, doar cookie-urile din browser vor raporta mai puțin decât realitatea pentru reclamele tale. Achizițiile trimise din datele comenzii, cu datele clientului cu hash, oferă platformelor de publicitate un alt mod de a potrivi acele comenzi. Poți vedea cum face asta ROASaurus pe pagina tracking-ului server-side și cum creditează click-urile în atribuire.

Surse

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

În ROASaurus

• Tracking server-side în ROASaurus
• Atribuirea în ROASaurus
• Funnel-uri și domenii conectate

Continuă lectura