Ha a webhelyed forgalmának jelentős része iPhone-ról érkezik, a GA4 új és visszatérő felhasználókra vonatkozó számai jó eséllyel torzítanak. Az ok az Apple Intelligent Tracking Prevention (ITP) nevű védelme, amely a Safari böngészőben lerövidíti a sütik élettartamát. Ebben a cikkben végigmegyünk azon, mit korlátoz pontosan az ITP, hogyan látod meg a hatását a saját adataidban, meddig segít a szerveroldali süti, és hogyan érdemes mindezt úgy leírni a riportban, hogy a vezető jó döntést hozzon belőle. A fontosabb állításoknál jelöljük, hogy hivatalosan igazolt információról, saját tapasztalatról vagy szakmai feltételezésről van szó.
Mit korlátoz pontosan a Safari ITP a sütik élettartamán?
A Safari a JavaScripttel beállított első féltől származó sütiket legfeljebb 7 napig őrzi meg, bizonyos hirdetési kattintások után pedig csak 24 óráig. A korlát akkor is érvényes, ha a süti saját lejárati ideje ennél jóval hosszabb.
Hivatalosan igazolt (a WebKit fejlesztői blogja és a WebKit követésvédelmi dokumentációja alapján):
- Az ITP 2.1 óta minden olyan süti, amelyet a böngészőben futó szkript a
document.cookiehívással ír, legfeljebb 7 napos lejáratot kaphat. - Az ITP 2.2 óta a korlát 24 óra, ha a látogató olyan domainről érkezik, amelyet a Safari követésre képesnek minősített, és a cél URL-ben paraméter vagy horgony szerepel (ezt hívja a WebKit link decorationnek).
- A szkriptből írható egyéb tárolókra, például a
localStoragetartalmára is 7 napos törlési szabály vonatkozik, ha a látogató közben nem lép interakcióba az oldallal. - A harmadik féltől származó sütiket a Safari alapértelmezés szerint teljesen blokkolja.
A GA4 azonosítója, a _ga süti alapbeállítás szerint két évig élne, és a Google címkéje JavaScripttel írja. Safari alatt ebből 7 nap marad. A számláló minden újabb látogatáskor újraindul, vagyis aki hetente legalább egyszer visszanéz, azt a rendszer továbbra is felismeri. Aki nyolc nap vagy annál hosszabb szünet után jön vissza, annak a böngészőjében már nincs meg a korábbi azonosító.
Egy részletet sokan elnéznek. iOS-en és iPadOS-en a böngészők gyakorlatilag mind a WebKit motorra épülnek, így az iPhone-on futó Chrome és Firefox is ugyanezeket a korlátokat örökli. Az Európai Unióban az Apple elvileg már megengedi más motor használatát, a gyakorlatban azonban ez eddig nem változtatott érdemben a képen (ez utóbbi szakmai feltételezés, a saját forgalmadon érdemes ellenőrizned).
Miért fújja fel ez az új felhasználók számát iPhone-os forgalomnál?
Azért, mert a GA4 az azonosító süti alapján dönti el, ki új. Ha a süti lejárt, ugyanaz az ember új azonosítót kap, és új felhasználóként jelenik meg.
Vegyünk egy általános példát. Valaki hétfőn megnyitja a webáruházadat iPhone-on, körülnéz, majd tíz nappal később visszatér és vásárol. Chrome-ot használó androidos telefonon a GA4 egyetlen felhasználót lát két munkamenettel, a második látogatást visszatérőként könyveli. Safari alatt a hétfői süti a hetedik nap után megszűnik, a tizedik napon új azonosító jön létre. A riportban két felhasználó szerepel, mindkettő újként, és a vásárlás olyan emberhez kerül, akinek a rendszer szerint ez volt az első látogatása.
Ennek négy következménye van, amelyekkel a napi munkában találkozol.
- Nő az összes felhasználó száma. Ugyanazt a személyt többször számolod, így az elérésed nagyobbnak látszik a valósnál.
- Csökken a visszatérők aránya. A hűség és a megtartás gyengébbnek tűnik iOS-en, mint amilyen valójában.
- Rövidülnek a konverziós utak. A több érintésből álló vásárlási folyamat eleje levágódik, ezért az első érintést adó csatornák (tartalom, közösségi média, organikus keresés) kevesebb elismerést kapnak.
- A hirdetési kattintások még rosszabbul járnak. A kattintási azonosítóval érkező látogatóknál a 24 órás szabály léphet életbe, így a másnap visszatérő érdeklődő már nem köthető a kattintáshoz.
Az utolsó ponthoz tartozik egy megszorítás. Azt, hogy a Safari pontosan mely domaineket minősíti követőnek, az eszközön futó besorolás dönti el, és ez nem nyilvános lista. Az, hogy a nagy hirdetési rendszerek domainjei rendszerint ide tartoznak, széles körben elfogadott szakmai feltételezés, de eszközönként eltérhet.
Saját tapasztalat: a torzítás ott a legfeltűnőbb, ahol a vásárlási ciklus hosszabb egy hétnél, például szolgáltatásoknál, nagyobb értékű termékeknél és B2B ajánlatkérésnél. Napi rendszerességgel látogatott oldalaknál (hírek, közösségi felületek) alig érzékelhető.
Hogyan nézed meg a GA4-ben, mekkora a torzítás?
Hasonlítsd össze platformonként az új felhasználók arányát és a heti megtartást. Az eltérés megmutatja a torzítás irányát és nagyságrendjét, pontos értéket viszont nem ad.
A gyors nézethez elég a beépített jelentés.
- Nyisd meg a Jelentések alatt a technológiai részleteket tartalmazó riportot (Tech details).
- Az elsődleges dimenziót állítsd böngészőre, majd egy második lépésben operációs rendszerre.
- Olvasd le soronként az összes felhasználót és az új felhasználókat, és számold ki a kettő hányadosát.
A részletesebb képhez a Felfedezés (Explore) menüben építs szabad formátumú táblát.
- Dimenziónak vedd fel az operációs rendszert, a böngészőt és az eszközkategóriát.
- Mutatónak add hozzá az összes felhasználót, az új felhasználókat, a visszatérő felhasználókat és a munkameneteket.
- Sorokba tedd az operációs rendszert, alá a böngészőt, és szűrj mobil eszközkategóriára.
- Az időszak legyen legalább 60-90 nap, mert rövid ablakban a 7 napos korlát hatása nem válik el a természetes ingadozástól.
- Készíts kohorsz elemzést is heti bontásban, külön szegmenssel az iOS-re és az Androidra, majd nézd meg, a második héttől hogyan alakul a megtartás.
Ha az iOS-es kohorsz megtartása a második héttől látványosan az androidos alá esik, miközben az első héten a két görbe közel fut egymáshoz, az erősen az ITP hatására utal.
Három buktatóra figyelj az értelmezésnél. Az első, hogy az iPhone-os és az androidos közönség összetétele eltér, tehát a különbség egy része valódi viselkedés. A második, hogy az iOS-es Chrome és az iOS-es Safari összevetése szinte semmit nem mutat, hiszen mindkettő WebKit alatt fut. A harmadik, hogy a hozzájárulási mód és a süti-sáv elfogadási aránya platformonként más lehet, ami szintén mozgatja a számokat. Emiatt a kapott érték becslés. A riportban is így nevezd.
Saját tapasztalat: hasznos kontroll a bejelentkezett forgalom. Ha van User-ID mérésed, a belépett felhasználóknál az új és visszatérő arány platformok között sokkal közelebb áll egymáshoz, és ez jó viszonyítási pontot ad a süti alapú számokhoz.
Mit old meg a szerveroldali, első féltől származó süti?
A szerver által, HTTP-válaszfejlécben beállított sütire a 7 napos és a 24 órás JavaScript-korlát nem vonatkozik, ezért az azonosító tovább megmaradhat. Ez hivatalosan igazolt, a WebKit dokumentációja a korlátot kifejezetten a szkriptből írt sütikre mondja ki.
A gyakorlatban ezt jellemzően szerveroldali címkekezelővel oldják meg. A mérési kérés a saját domainedre fut be, a szerver pedig válaszként állítja be az azonosítót, például így.
Set-Cookie: FPID=FPID2.2.abc123; Max-Age=63072000; Domain=pelda.hu; Path=/; Secure; HttpOnly; SameSite=Lax
A HttpOnly jelző miatt a sütit a böngészőben futó szkript nem tudja olvasni, ami biztonsági szempontból is előny. A Google szerveroldali címkézésének dokumentációja ezt a megoldást FPID néven írja le.
Van azonban egy feltétel, amelyen sok bevezetés elcsúszik. A WebKit 2020-ban védekezést vezetett be a CNAME-álcázás ellen, vagyis ha az aldomained egy CNAME rekordon keresztül harmadik fél szerverére mutat, az onnan érkező süti is 7 napos korlátot kap (hivatalosan igazolt). A Safari 16.4 óta a szakmai közösség megfigyelései szerint hasonló korlát él akkor is, ha a sütit beállító szerver IP-címének első fele nem egyezik a webhelyet kiszolgáló szerverével. Ez utóbbiról az Apple szűkszavúan kommunikált, ezért kezeld szakmai feltételezésként, és mérd ki magad.
A tartósabb megoldás az, ha a mérési végpontot a fő domain alól, azonos infrastruktúrán keresztül szolgálod ki, például fordított proxyval vagy a CDN-ed útvonal-szabályával egy /meres jellegű útvonalon. A beállítás után Safari fejlesztői eszközökkel nézd meg a süti lejáratát, mert csak ebből derül ki, hogy a böngésző elfogadta-e a hosszabb élettartamot.
Mit nem old meg a szerveroldali beállítás?
A szerveroldali süti egyetlen böngészőn belül hosszabbítja meg a felismerést. A hozzájárulást, az eszközök közötti azonosítást és a böngésző további védelmeit nem pótolja.
- Hozzájárulás. A süti jogi megítélése nem változik attól, hogy honnan állítod be. Ha a látogató elutasítja a mérést, a szerveroldali azonosító sem használható (ez jogi kérdés, a saját helyzetedre adatvédelmi szakértővel egyeztess).
- Több eszköz, több böngésző. A telefonon böngésző, majd laptopon vásárló ember továbbra is két felhasználó, hacsak be nem jelentkezik.
- Alkalmazáson belüli böngészők. A közösségi alkalmazásokból megnyitott oldalak külön süti-tárolót használnak, így a hirdetésre kattintó, majd később Safariban visszatérő látogató új felhasználóként jelenik meg.
- Privát böngészés és kézi törlés. Ezeknél a süti a munkamenet végén vagy a törléskor elvész.
- Múltbeli adatok. A bevezetés előtti időszak számai nem javíthatók utólag, ezért a két időszak között törés lesz az idősorban.
- Jövőbeli szigorítás. Az Apple évek óta fokozatosan zárja a kiskapukat. Az, hogy a mai beállítás meddig működik, szakmai feltételezés kérdése, hosszú távú ígéretet senki nem tehet rá.
Saját tapasztalat: a szerveroldali mérés bevezetése után az új felhasználók aránya iOS-en jellemzően közelebb kerül a többi platformhoz, de ritkán simul teljesen rájuk. Aki hibátlan számot vár tőle, csalódni fog.
Hogyan jelezd ezt a riportban a döntéshozónak?
A visszatérő látogatók számát alsó becslésként, az új felhasználókét felső becslésként mutasd, és írd oda egy mondatban, hogy miért. A vezetőnek a technikai háttér kevésbé érdekes, azt viszont tudnia kell, mennyire támaszkodhat a számra.
A mi nézőpontunk szerint a mérési bizonytalanság elhallgatása nagyobb kockázat, mint a kimondása. Ha a riport pontosnak tünteti fel az új és visszatérő arányt, a vezető könnyen arra jut, hogy gyenge a megtartás, és olyan területre csoportosít forrást, ahol valójában nincs baj. A következő gyakorlatot ajánljuk.
- Tegyél megjegyzést a mutató mellé. Például így: „Az iOS-es forgalomnál a böngésző 7 nap után törli az azonosítót, ezért a visszatérők tényleges száma ennél magasabb.”
- Mutasd meg a platformok arányát. Ha a forgalom nagyobb része iPhone-ról jön, a bizonytalanság is nagyobb, és ezt a vezetőnek látnia kell.
- Trendet mutass, abszolút számot csak óvatosan. A torzítás hónapról hónapra nagyjából hasonló, így a változás iránya megbízhatóbb, mint maga az érték.
- Válassz stabilabb mutatót a döntésekhez. A konverziók száma, a bevétel, az ajánlatkérések és a bejelentkezett felhasználók viselkedése kevésbé függ a süti élettartamától.
- Jelöld a mérési változásokat. Ha szerveroldali mérésre váltasz, a dátumot írd rá a grafikonra, különben a javulást valaki a kampányoknak fogja tulajdonítani.
- Válaszd szét a három szintet. A riportban is jelöld, mi mért tény, mi becslés, és mi a szakmai véleményed.
Egy vezetői összefoglalóban ez elfér két mondatban. Az első kimondja a számot, a második azt, hogy mekkora fenntartással érdemes kezelni és milyen irányban torzít.
Milyen ellenőrzőlistán menj végig, mielőtt következtetést vonsz le?
Mielőtt a visszatérő látogatók számából üzleti következtetést vonsz le, ellenőrizd a platform-megoszlást, a vásárlási ciklus hosszát és a mérés beállításait.
- Mekkora az iOS és a macOS Safari részesedése a munkamenetekből?
- Hosszabb-e a jellemző döntési idő 7 napnál a te piacodon?
- Eltér-e az új felhasználók aránya iOS-en a többi platformtól, és mennyivel?
- Mit mutat a heti kohorsz megtartás a második héttől?
- Van-e User-ID mérésed, amelyhez viszonyíthatsz?
- Ha van szerveroldali mérésed, ellenőrizted-e Safariban a süti tényleges lejáratát?
- Szerepel-e a riportban megjegyzés a mérési korlátról?
- Dokumentáltad-e, mikor változott a mérési beállítás?
Ha ezeken végigmentél, a számaid ugyanazok maradnak, de tudni fogod, mennyit érnek, és ezt a döntéshozónak is el tudod mondani.
Források és további olvasnivalók
- WebKit Blog: Intelligent Tracking Prevention 2.1, 2.2 és 2.3
- WebKit Blog: CNAME Cloaking and Bounce Tracking Defense
- WebKit dokumentáció: Tracking Prevention in WebKit
- Google Analytics Súgó: a Google Analytics sütihasználata, valamint az új és visszatérő felhasználók mutatói
- Google Tag Manager fejlesztői dokumentáció: szerveroldali címkézés és az FPID süti
- MDN Web Docs: Set-Cookie HTTP-válaszfejléc
- A Safari ITP a JavaScripttel írt sütik élettartamát 7 napra, követőnek minősített forrásból érkező, paraméterezett kattintás után 24 órára korlátozza.
- iOS-en gyakorlatilag minden böngésző WebKit motorral fut, ezért a torzítást operációs rendszer szerint érdemes vizsgálni, a böngésző neve kevés hozzá.
- A GA4-ben az új felhasználók aránya és a heti kohorsz megtartás platformonkénti összevetése megmutatja a torzítás irányát, a pontos mértékét viszont csak becsülni lehet.
- A szerveroldali, HTTP-fejlécben beállított süti csak akkor él tovább, ha valóban a saját domainedről és azonos infrastruktúráról érkezik, a hozzájárulást és az eszközök közötti azonosítást pedig nem pótolja.
- A döntéshozónak a visszatérő látogatók számát alsó becslésként mutasd, és a döntéseket inkább konverziókra és bejelentkezett felhasználókra építsd.
Gyakori kérdések
Az iPhone-on futó Chrome-ra is vonatkozik az ITP?
Igen, a gyakorlatban vonatkozik rá. iOS-en a böngészők jellemzően a WebKit motorra épülnek, ezért a Chrome és a Firefox is ugyanazokat a süti-korlátokat örökli, mint a Safari. Emiatt a torzítást operációs rendszer szerint érdemes vizsgálni.
Ha valaki hetente visszajár az oldalamra, őt is újként számolja a GA4?
Jó eséllyel nem. A 7 napos számláló minden látogatáskor újraindul, így a rendszeresen visszatérő látogató azonosítója megmarad. A gond azoknál jelentkezik, akik egy hétnél hosszabb szünet után térnek vissza.
Megoldja a problémát a szerveroldali Google Tag Manager?
Részben. A HTTP-fejlécben beállított süti tovább élhet, ha a végpont valóban a saját domainedről és azonos infrastruktúráról szolgál ki. A hozzájárulás hiányát, a több eszközön történő böngészést és az alkalmazáson belüli böngészőket nem kezeli, és eredményt nem garantál.
Meg lehet pontosan mondani, hány visszatérő látogatót veszítek el a mérésben?
Pontosan nem. A platformok közötti eltérésből és a kohorsz megtartásból becsülni tudod a nagyságrendet, de az iOS-es és androidos közönség viselkedése valóban eltérhet, ezért a kapott érték becslés marad.
Kell hozzájárulás a szerveroldalon beállított sütihez is?
A süti jogi megítélése nem attól függ, hogy JavaScript vagy szerver állítja be. A mérési célú azonosítóhoz jellemzően ugyanúgy hozzájárulás kell, a saját helyzetedre vonatkozóan pedig adatvédelmi szakértő tud biztos választ adni.
Mit írjak a riportba, ha a vezető a visszatérő látogatók arányát kéri?
Add meg a számot, és tedd mellé egy mondatban, hogy az iOS-es forgalom miatt ez alsó becslés. Mutasd meg a trendet és egy stabilabb mutatót is, például a konverziókat vagy a bejelentkezett felhasználók visszatérését.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.