Safari ITP és hirdetéskövetés: mi működik még

A Safari Intelligent Tracking Prevention (ITP) funkciója korlátozza, mennyi ideig ismerhet fel egy weboldal egy visszatérő látogatót. Blokkol minden harmadik féltől származó sütit, a JavaScript által beállított sütiket pedig 7 napra korlátozza, egyes hirdetéskattintások után 24 órára. A rendelési adatokból szerveroldalon küldött vásárlások, a vásárló érkezésekor elmentett kattintásazonosítók és a hashelt ügyféladatok továbbra is működnek.

Ez az útmutató elmagyarázza az egyes ITP-szabályokat úgy, ahogy a WebKit dokumentálja őket, mit tesznek a szabályok az attribúciós ablakokkal és a remarketinggel, és mely követési módszerek működnek még egy webáruháznál. Azzal zárul, hogyan ellenőrizheted, mennyire érinti a Safari a saját webáruházadat.

Mi az a Safari ITP?

Az Intelligent Tracking Prevention a WebKit adatvédelmi védelmi funkcióinak összessége; a WebKit a Safari böngészőmotorja Macen, iPhone-on és iPaden. A WebKit többször is kibővítette, és az aktuális szabályokat a Tracking Prevention oldalán dokumentálja.

Egyes ITP-szabályok minden weboldalra vonatkoznak. Mások csak azokra a domainekre, amelyeket az ITP úgy minősített, hogy webhelyek közötti követési képességgel rendelkeznek, azon alapján, hogyan viselkednek ezek a domainek azokon az oldalakon, amelyeket egy személy meglátogat. Az ITP alapértelmezetten be van kapcsolva, ezért minden Safari-látogatót érint a webáruházadban, nem csak az adatvédelmet fontosnak tartókat.

Milyen sütikorlátok vannak a Safari ITP-ben?

A scriptsütik 7 napos korlátja

A legtöbb pixel és analitikai eszköz a saját first-party sütijeit JavaScripttel írja. A Meta pixel például egy böngészőazonosítót tart egy _fbp nevű sütiben. A Safariban az ITP törli a JavaScript által létrehozott sütiket és más tárhelyet, ha 7 napig nem volt felhasználói interakció az oldaladon. A WebKit a felhasználói interakciót kattintásként, koppintásként vagy billentyűleütésként határozza meg. A görgetés nem számít.

A gyakorlatban az a vásárló, aki visszatér, és 7 napon belül használja az oldaladat, általában megtartja a sütit. Az a vásárló, aki 7 napnál tovább távol marad, süti nélkül tér vissza, és új látogatónak látszik.

A 24 órás korlát megjelölt link után

A hirdetési platformok kattintásazonosítókat adnak a hirdetéseik linkjeihez. A WebKit ezt link decorationnek (linkmegjelölésnek) nevezi. Ha egy olyan domain küldi a látogatót az oldaladra, amelyet az ITP követőnek minősített, és a végső URL-ben van query string vagy fragment, akkor a JavaScript által azon a landing oldalon írt sütik 24 órára korlátozódnak. A korlát az adott navigációval elért oldalra vonatkozik, nem az egész webhelyre.

Harmadik féltől származó sütik

A Safari alapértelmezés szerint blokkol minden harmadik féltől származó sütit, és a WebKit szerint ez alól a blokkolás alól nincs kivétel. Egy harmadik fél csak olyan mechanizmusokon keresztül kérhet hozzáférést, mint a Storage Access API. Egy hirdetési platform ezért nem tudja kiolvasni a saját sütijét az oldalaid belsejéből. A pixele által írt first-party sütikre támaszkodik, amelyekre a 7 napos és a 24 órás szabály vonatkozik.

CNAME- és IP-cím-álcázás

Gyakori kerülőút egy követő aldomain, például t.yourstore.com, amely egy követőszerverre mutat. Ennek az aldomainnek a sütijeit a HTTP-válaszban állítják be, így nem scriptsütik. A WebKit akkor tekinti az aldomaint álcázottnak, ha az egy CNAME-en keresztül egy másik domainre mutat. A Safari 17 óta akkor is álcázottnak tekinti, ha az IP-címe más félnek látszik, mint az oldalad, például ha a két cím egyértelműen különböző hálózati tartományokban van. Mindkét esetben az ITP a válaszban beállított sütiket 7 napra korlátozza. Ezeknél a szabályoknál nem számít, ki a szerver tulajdonosa.

Hogyan kezeli a Safari a linkekben lévő kattintásazonosítókat?

Egy olyan kattintásazonosító, mint az fbclid vagy a gclid, a landing URL része. Normál böngészésben a Safari a paramétereivel együtt tölti be az URL-t, így a landing oldalon futó script ki tudja olvasni a kattintásazonosítót. A fenti 24 órás korlát azt szabja meg, meddig él egy azon az oldalon írt süti. A kattintásazonosítót nem távolítja el az URL-ből.

A privát böngészés (Private Browsing) ennél is tovább megy. A Safari 17 óta a Link Tracking Protection akkor lép életbe, amikor a látogató egyik webhelyről egy másikra navigál, például egy hirdetésről a webáruházadba. A Safari eltávolít egy sor query paramétert, amelyet a WebKit úgy azonosított, hogy a felhasználók vagy kattintások webhelyek közötti követésére használják. A WebKit közleménye nem sorolja fel a paramétereket. A példája egy követőparamétert eltávolít, egy kampányparamétert viszont megtart. A landing oldalon az URL-t kiolvasó harmadik féltől származó scriptek is query string nélkül kapják meg. Ugyanezek a védelmek a normál böngészésben is elérhetők azoknak, akik a haladó követés- és ujjlenyomat-védelmet minden böngészésre bekapcsolják.

Mi a helyzet a Private Relay-jel és az IP-címekkel?

A WebKit szerint a Safari a Safari 15 óta alapértelmezés szerint elrejti az IP-címeket az ismert követők elől. Az iCloud+ előfizetői bekapcsolhatják az iCloud Private Relay-t is. Ez a Safari-forgalmat két külön, különböző üzemeltetők által működtetett relén keresztül küldi, így a webhelyek a látogató saját IP-címe helyett egy relé IP-címét látják. Az Apple szerint a relécím megőrzi a látogató durva, városszintű tartózkodási helyét, és ugyanazon a területen több felhasználó is osztozhat egy címen.

Ez gyengíti az IP-címre támaszkodó követést, például azt, ha egy látogatót IP-cím és böngésző alapján párosítanak. A kattintásazonosítókat, a hashelt e-mail-címeket és a rendelési adatokat nem érinti. A ROASaurus az IP-egyezést csak végső megoldásként használja, és csak akkor, ha pontosan egy friss, azzal az IP-címmel és böngészővel rendelkező látogató illik. Egy megosztott relécím ekkor általában azt eredményezi, hogy nincs egyezés.

Mit jelent az ITP az attribúciós ablakokra nézve?

Az attribúciós ablak azon napok száma egy kattintás után, amelyeken belül egy vásárlás még jóváírható az adott kattintásnak. A ROASaurusban 1 és 90 nap közötti visszatekintési ablakot választhatsz, alapértelmezetten 7 nappal. A hirdetési platformoknak saját beállításaik vannak. A Safariban az a megoldás, amely csak böngészősütikre támaszkodik, csak addig tud egy vásárlást egy kattintáshoz kötni, amíg a süti él.

A hatás az ablak méretével nő. Az 1 napos vagy 7 napos ablak nem hosszabb, mint egy scriptsüti 7 napos élettartama, kivéve, ha a 24 órás korlát érvényes. 28 napos ablaknál a 8. napon vagy később történő vásárlások azoktól a vásárlóktól, akik közben nem tértek vissza, más adatokra támaszkodnak.

Így méretezheted ezt egy webáruházra. A számok példák; használd a sajátjaidat.

Mit jelent az ITP a remarketingre nézve?

A remarketing-közönségeket böngészőeseményekből építik, például azokból, akik megtekintettek egy terméket vagy kosárba tették. A Safariban a platform nem tudja használni a harmadik féltől származó sütijeit, a pixel first-party sütije pedig 7 nap látogatás nélkül törlődik. Az a Safari-látogató, aki 8 nap után tér vissza, újnak látszik a pixel számára. A korábbi termékmegtekintései a böngészőben már nem kapcsolódnak hozzá.

Két hatás következik ebből. A hosszú időtartamú közönségek, például a 30 vagy 180 napos, kevesebb Safari-látogatót tartanak meg, mint amennyit az időtartam sugall. Az analitikád is több új és kevesebb visszatérő látogatót mutat, mint amennyi valójában van. A webáruházadban vagy az e-mail-eszközödben hashelt e-mail-címekből épített ügyféllista-közönségek nem függnek a sütiktől, ezért őket ez nem érinti hasonlóan.

Mi működik még a Safariban?

Szerveroldali események a rendelésekből

A webáruházad rendelési adataiból küldött vásárlás nem függ a Safariban lévő semmilyen sütitől. A webáruház rögzíti a rendelést, egy szerver elküldi a platform API-jának, és a platform megkapja. Az esemény tartalmazza a rendelésből származó hashelt e-mailt és telefonszámot. A platform ezeket párosítani tudja az egyik felhasználójával, és a saját attribúciós ablakán belül ellenőrizheti a hirdetéskattintásokról és -megtekintésekről vezetett saját nyilvántartását. A teljes adatútvonalért olvasd el, mi a szerveroldali követés.

A landoláskor rögzített kattintásazonosítók

A kattintásazonosító az első oldal URL-jében van. Egy script ott ki tudja olvasni, és elküldheti a szerveredre, ahol a látogatóazonosítóval együtt tárolódik. A szerveren lévő másolat nem jár le 7 nap után. A böngészősüti jár le, amely egy visszatérő látogatást az eltárolt látogatóhoz köti. Más adatok még mindig összeköthetnek egy rendelést egy eltárolt kattintással, például egy e-mail-cím, amelyet a vásárló korábban megadott egy feliratkozási űrlapon, vagy a rendelést leadó munkamenet landing URL-jében lévő kattintásazonosító.

First-party gyűjtés, a 7 napos korláttal

Ha a követőscriptet és annak kéréseit a saját domainedről szolgálod ki, a gyűjtés first-party marad, ami a reklámblokkolók ellen is segít. Ettől a sütik még nem élnek tovább. Egy olyan követő aldomain, amely CNAME-en keresztül egy másik domainre mutat, vagy amelyet a WebKit harmadik féltől származó IP-címként lát, a 7 napos korlát alá esik. A ROASaurus követő aldomainje a látogatóazonosítót HTTP-sütiként újra kiadja, de a Safari ezt a sütit is korlátozhatja 7 napra. A Shopify app proxyja a kéréseket a webáruházad domainjén tartja, de a Shopify eltávolítja a sütiket az app proxy kéréseiből és válaszaiból, így ott a látogatóazonosítót JavaScript írja, és a 7 napos szabály érvényes.

Amit a vásárló elmond neked

A vásárlók el tudják mondani, hogyan találtak rád, és ez a válasz nem függ a sütiktől. Egy vásárlás utáni felmérés a fizetés után kérdez. A ROASaurusban a Total Impact modell a választ összekeveri a kattintási adatokkal, és a felmérésnek a jóváírás 50%-át adja, ha kattintások is vannak.

Hogyan ellenőrizd, mennyire érinti a Safari a webáruházadat

1. Keresd meg a rendeléseid Safari-arányát

   Az analitikai eszközödben csoportosítsd a vásárlásokat böngésző szerint. Számold a Safarit Macen, iPhone-on és iPaden.

2. Mérd meg a kattintástól a vásárlásig eltelt időt

   Nézd meg, hány rendelés érkezik a hirdetéskattintás után több mint 7 nappal. A ROASaurus attribúciós riportjában hasonlítsd össze a 7, 14 és 28 napos ablakokat, és nézd meg, mennyi jóváírás mozdul el.

3. Hasonlítsd össze a pixelvásárlásokat a rendelésekkel

   Számold meg a pixeled által küldött Purchase eseményeket, böngésző szerint bontva, ha a platform engedi, és hasonlítsd össze őket az ugyanazon időszak rendeléseivel.

4. Ellenőrizd a szervereseményeidet

   Győződj meg róla, hogy minden kifizetett rendelés szerveroldalon, hashelt e-maillel és telefonszámmal kerül elküldésre, és hogy a böngészős és a szerveres példány ugyanazt az eseményazonosítót használja.

Ha a rendeléseid nagy része Safariból jön, és sok közülük a kattintás után több mint 7 nappal érkezik, a böngészősütik egyedül alulmérik a hirdetéseid eredményét. A rendelési adatokból, hashelt ügyféladatokkal küldött vásárlások egy másik módot adnak a hirdetési platformoknak ezeknek a rendeléseknek a párosítására. Hogyan csinálja ezt a ROASaurus, a szerveroldali követés oldalon láthatod, azt pedig, hogyan írja jóvá a kattintásokat, az attribúciónál.

Források

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

A ROASaurusban

• Szerveroldali követés a ROASaurusban
• Attribúció a ROASaurusban
• Értékesítési tölcsérek és összekapcsolt domainek

Olvass tovább