Két különböző feladat

Amikor egy látogató hozzájárulási döntést hoz, két különálló dolognak kell megtörténnie. Először is a böngészőnek meg kell jegyeznie a döntést, hogy a banner ne jelenjen meg minden oldalon, és a tagek tudják, mit tehetnek. Másodszor, később szükség lehet arra, hogy bizonyítsa, a döntés megszületett, mit mutattak a látogatónak, és mikor. Ezeket a feladatokat gyakran különböző tárolási mechanizmusok látják el, és összekeverésük valódi gondokat okoz: újra és újra megjelenő bannereket, egyes böngészőkben eltűnő döntéseket, vagy bizonyíték nélküli helyzetet, amikor valaki rákérdez.

Ez az összehasonlítás a három gyakori lehetőséget vizsgálja — first-party cookie-k, böngészőtár, például a localStorage, és szerveroldali hozzájárulási rekordok — és azt, hogy melyik hová illik.

1. lehetőség: first-party cookie-k

A cookie-k a hozzájárulási állapot hagyományos otthona. A TCF CMP-k gyakran first-party cookie-ban tárolják a hozzájárulási stringet, és sok CMP a saját beállítási adatait is ott tárolja.

Erősségek

• A szerver olvashatja. A cookie minden kéréssel együtt elmegy, így a szerveroldali kód, az edge-logika és a szerveroldali tagelés JavaScriptre várakozás nélkül olvashatja a döntést.
• Megosztható aldomainek között. A regisztrálható domainen beállított cookie lefedheti a www, blog és shop aldomaineket.
• Széles körben elvárt. Sok ad tech integráció a cookie-kban keresi a hozzájárulást.

Gyengeségek

• Méretkorlátok. A böngészők körülbelül 4 KB-ban korlátozzák a cookie méretét, és sok szállítót tartalmazó TCF-string plusz más értékek megközelíthetik ezt.
• Kéréstöbbletterhelés. A domainjére irányuló minden kérés viszi a cookie-t, a kép- és scriptkéréseket is.
• Élettartam-korlátok egyes böngészőkben. A Safari Intelligent Tracking Preventionje a JavaScripttel létrehozott cookie-k maximális élettartamát hét napra korlátozza. A saját szervere által HTTP-válaszban beállított cookie-kat általában nagyvonalúbban kezelik, bár vannak kivételek.

2. lehetőség: localStorage és más böngészőtár

Egyes CMP-k a részletes beállításokat localStorage-ban tárolják, néha egy kisebb cookie mellett.

Erősségek

• Több hely. Originenként több megabájt, elég a részletes, szállítószintű döntésekhez.
• Nincs kéréstöbbletterhelés. Semmi sem megy automatikusan a szerverre.

Gyengeségek

• A szerver számára láthatatlan. A szerveroldali kód és az edge-logika nem tudja olvasni, így minden szerveroldali döntésnek meg kell várnia a böngészőt.
• Egy originhez kötött. A www.example.com tárhelye nem érhető el a shop.example.com-on, így a látogató minden aldomainen újra láthatja a bannert.
• Törlésnek kitett. A Safari törölheti a scriptek által írható tárat, a localStorage-ot is, azoknál a webhelyeknél, amelyekkel a felhasználó hét napnyi böngészőhasználat alatt nem lépett interakcióba, és a privát böngészési módok általában a munkamenet végén kiürítik.

3. lehetőség: szerveroldali hozzájárulási rekordok

A szerveroldali rekord olyan bejegyzés, amelyet Ön vagy a CMP-szolgáltatója tárol minden alkalommal, amikor döntés születik. Általában tartalmaz egy álnevesített azonosítót, az időbélyeget, a döntéseket, a megjelenített banner vagy szabályzat verzióját, valamint olyan kontextust, mint a régió.

Erősségek

• Tartós bizonyíték. Túléli a cookie-k törlését és a böngészőkorlátozásokat, ezért ez a megfelelő eszköz annak igazolására, hogy a hozzájárulást megszerezték.
• Auditálható. Időben jelentést készíthet a döntésekről, és válaszolhat konkrét eseményekre vonatkozó kérdésekre.
• Eszközök közötti lehetőség. Bejelentkezett olvasóknál a szerveroldali rekord szinkronizálhatja a döntéseket az eszközök között, ha ezt elmagyarázza nekik.

Gyengeségek

• Nem helyettesíti a helyi állapotot. A böngészőben lévő tageknek továbbra is gyors, helyi jelre van szükségük; ha minden oldalmegtekintésnél a szervert hívja a hozzájárulás kikereséséhez, az késleltetést ad.
• Maga is személyes adat. A rekordokhoz megőrzési idő, hozzáférés-szabályozás és az adatvédelmi tájékoztatóban való említés kell.
• Azonosítófüggőség. Az anonim látogatók csak az eszközükön tárolt azonosítón keresztül párosíthatók rekorddal, ami visszavezet a helyi tárhoz.

Összefoglaló egymás mellett

• A döntés megjegyzésére a weben a legjobb: first-party cookie-k, ideális esetben a szerver által beállítva, stabil élettartammal.
• Részletes beállítási adatokhoz a böngészőben a legjobb: localStorage, egy a szerver által olvasható cookie mellett.
• A döntés bizonyítására a legjobb: szerveroldali rekordok.
• A legrosszabb egyetlen lehetőség: kizárólag a localStorage-ra támaszkodni, ami vakon hagyja a szervert, és egyes böngészőkben törékennyé teszi a döntést.

Gyakorlati kombinált megközelítés

1. A mértékadó helyi jelet — például a TCF-stringet és egy tömör beállítási rekordot — first-party cookie-ban tárolja, a regisztrálható domainre szűkítve.
2. A localStorage-ot csak olyan kiegészítő adatokra használja, amelyeknek nem kell eljutniuk a szerverre.
3. Minden döntéshez írjon szerveroldali rekordot, a megjelenített banner és szabályzat verziójával együtt.
4. Ha egy eltárolt döntés eltűnik, jelenítse meg újra a bannert ahelyett, hogy egy korábbi választ feltételezne.
5. Állítson be újrakérdezési időszakot az eltárolt döntésekhez, és rögzítse a szabályzatában.

A látogató hozzájárulási döntésének tárolását általában a látogató által kért szolgáltatás nyújtásához szükségesnek tekintik — a döntésének megjegyzése —, de ellenőrizze a fő piacain érvényes iránymutatásokat.

Legfontosabb tanulságok

• A döntés megjegyzése és a döntés bizonyítása különböző feladatok, amelyek különböző tárat igényelnek.
• A cookie-kat a szerver olvashatja és aldomainek között megoszthatók, de méretükben korlátozottak, a Safariban pedig élettartamukban is, ha scripttel állítják be őket.
• A localStorage helyet kínál, de a szerver számára láthatatlan, és a böngészők törölhetik.
• A szerveroldali rekordok a bizonyítékréteg, nem a helyi jel helyettesítői.
• Kombinálja a szerver által beállított first-party cookie-t, az opcionális böngészőtárat és a szerveroldali rekordokat.