Miért igényel hozzájárulást az Optimizely Web Experimentation

Az alapértelmezett Optimizely inicializálás az oldal első kirajzolásakor több dolgot is elvégez. Beállít egy first-party sütit az optimizelyEndUserId alatt, amely tartalmazza a tartós látogatói azonosítót, értékeli a látogatót az aktív kísérletek alapján, a változat-hozzárendeléseket egy második sütibe írja az optimizelyOptOut névtér-jelölők alá, döntési eseményt küld a logx.optimizely.com felé, és a változatmódosításokat alkalmazza a megjelenített oldalra. Amikor az üzemeltető analitikai integrációt csatlakoztatott — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap vagy az Optimizely Data Platform —, az SDK változat-megjelenítési eseményeket is küld az analitikai rétegbe, amely aztán a változatot a látogató szélesebb analitikai profiljához köti.

Mindegyik tevékenység külön hozzájárulási kaput aktivál. A látogatói azonosító megőrzése tárolási és hozzáférési művelet az ePrivacy-irányelv Article 5(3) cikke szerint, amely az EEA-ban, az Egyesült Királyságban és minden olyan joghatóságban előzetes, szabadon adott, konkrét, tájékoztatáson alapuló és egyértelmű hozzájárulást követel meg, amely átvette ugyanazt a standardot. A kísérleti változat-hozzárendelések munkameneteken átívelő azonosítóhoz kötése a GDPR szerinti személyes adatok feldolgozása, mert az azonosító, az IP-cím és a változat-megjelenítés kombinációja elegendő egy személy azonosításához és a kísérletezési programmal való interakciójuk jellemzéséhez. A változatadatok eszközök közötti terjesztése — például az Optimizely feltárja a változat-hozzárendelést a Google Analytics felé — hozzáadja az analitikai kaput a lánchoz. Az EDPB 2023-as útmutatása explicit volt: a tartós azonosítást felölelő kísérletezés ugyanolyan hozzájárulási szabályok alá esik, mint az analitika; a CNIL volt a leghangosabb szabályozó ebben a kérdésben, de nem az egyetlen.

Mit ír az Optimizely a hozzájárulás előtt — és mit kell elnyomni

A szabványos Optimizely-kódrészlet közvetlenül az oldal fejlécébe telepíti a JavaScript SDK-t, és azonnal inicializálódik betöltéskor. Ez a dokumentált gyors indítás és a leggyakoribb megfelelési hiba forrása: az SDK még a cookie-banner megjelenítése előtt fut, az optimizelyEndUserId süti milliszekundumok alatt kerül megírásra, megtörténik a változat-hozzárendelés, és a döntési esemény elküldésre kerül, függetlenül attól, mit dönt később a látogató. Minden európai szabályozó hatóság, amely állást foglalt ebben a mintában, ugyanúgy döntött: a hozzájárulás előtt beállított sütik jogellenesek, a hozzájárulás előtt rögzített változat-hozzárendelés jogellenes feldolgozás, és a kiadó viseli a felelősséget.

Egy megfelelő integrációnak ezért meg kell akadályoznia az Optimizelyt abban, hogy a tartós azonosítót megírja és döntési eseményeket küldjön, amíg a vonatkozó hozzájárulási kategóriát meg nem adták. Az Optimizely két mintát támogat erre. Az első a dedikált hozzájárulási attribútum — adja át az OPTIMIZELY_OPT_OUT=true értéket lekérdezési karaktersorozatként, vagy állítsa be az optimizely.opt_out sütit az SDK inicializálása előtt — ami az SDK-t kijelentkezési módba helyezi, ahol nem íródik azonosító és nem küldenek eseményeket. A második az SDK-konfigurációban támogatott csak névtelen mód, ahol az SDK egy munkamenet nélküli módban fut, amely változatokat rendel hozzá kizárólag munkamenet-helyi azonosítás alapján, tartós azonosítás nélkül a látogatások között. A névtelen mód lehetővé teszi a kísérletezési program jogos érdek alapján való futtatását a megjelenítési döntéshez, miközben a tartós azonosítást a hozzájárulás megadásáig elhalasztja.

Az Optimizely által írt sütik és tárolók

Az Optimizely Web Experimentation SDK az inicializáláskor a következő azonosítókat írja, amelyek mind nem elengedhetetlenek és hozzájárulást igényelnek: optimizelyEndUserId több éves lejárattal, amely tartalmazza a tartós látogatói azonosítót, optimizelyOptOut jelölők a kijelentkezési állapot nyomon követéséhez, optimizelyDomainTestCookie az aldomének közötti kísérletezéshez, és további névtér-sütik, ha az üzemeltető engedélyezte a domainek közötti azonosítást. A hozzájárulás visszavonásának ezért mind a sütik lejártatását, mind az SDK kijelentkezési módba helyezését el kell végeznie a optimizely.push({ type: 'user', attributes: { opt_out: true } }) segítségével az újabb eseménygyűjtés leállításához.

Az Optimizely leképezése hozzájárulási keretrendszerekre

Az Optimizely natívan nem implementálja az IAB TCF-et vagy az IAB Global Privacy Platformot — első féltől származó kísérletezési platform, nem hirdetéstechnológiai szállító —, de natív kijelentkezési API-t biztosít, dokumentált Consent Mode integrációt támogat az Optimizely Data Platformon keresztül, és tiszteletben tartja a kiadó CMP-jét az OPTIMIZELY_OPT_OUT attribútumon keresztül. A hatósági felülvizsgálaton átjutó minta minden Optimizely-képességet külön kapuként kezel, amely egy adott CMP-jelhez van kötve.

• Névtelen kísérletezés futtatható jogos érdek alapján munkamenet-helyi azonosítással, ami megfelelő olyan megjelenítési döntésekhez, amelyek nem igényelnek tartós azonosítást a látogatások között, és nem terjednek ki az alsóbb analitikára. Ez a mód a szigorúan szükséges vagy funkcionális kategóriához kötődik.
• Tartós kísérletezés stabil azonosítóval az analitikai célhoz kötődik. TCF-feltételekben ez a 8. célhoz van leképezve, az 1. céllal kombinálva; a Consent Mode esetén ez az analytics_storage-hoz van leképezve.
• Eszközök közötti integráció — változat-megjelenítési események, amelyeket a Google Analyticsbe, az Amplitudeba vagy az Optimizely Data Platformba terjesztenek — az analitikai kaput a fogadó eszköztől örökli, és nem szabad tüzelnie, ha az adott eszköz kapuját nem adták meg.
• A kísérletezésre épített személyre szabás és közönségalapú célzás aktiválja a marketing kaput, mert kísérleti mérésből felhasználói szintű célzásba csap át.

A működő integrációs minta

A referencia-bevezetés négy részből áll: egy CMP, amely valós idejű hozzájárulás-változási eseményt tesz elérhetővé, egy késleltetett bootstrap, amely az Optimizely SDK-t engedélyezett kijelentkezéssel vagy aktív névtelen módban inicializálja, egy hozzájárulás-figyelő, amely az SDK-t kijelentkezési módból vált és tartós azonosítást indít az analitikai kapu megnyílásakor, és egy visszavonási útvonal, amely az SDK-t visszahelyezi kijelentkezési módba, document.cookie-n keresztül lejáratja az optimizely sütiket, és a visszavonást terjeszti az összes alsóbb analitikai integrációba.

Webes implementáció a késleltetett bootstrappal

A weben a legtisztább minta az Optimizely-kódrészlet betöltése window.optimizelyOptOut = true beállítással az SDK inicializálása előtt. Iratkozzon fel a CMP hozzájárulás-változási eseményére. Amikor az analitikai kategória true értékre vált, hívja a window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) funkciót, és hagyja az SDK-t normálisan inicializálódni. A kapu visszavonásakor a kijelentkezési attribútumot tolja vissza true értékre, járassa le az optimizelyEndUserId sütit, és terjesztje a változást az integrált analitikai platformokra a hozzájárulási API-jaikon keresztül.

Szerveroldali kísérletezés a Decision Service segítségével

Az Optimizely támogatja a szerveroldali kísérletezést a Decision Service API-n keresztül is. A szerveroldali döntések nem mentesülnek a hozzájárulás alól — a jogi alap az adatokat követi —, de a szerveroldali végrehajtás teljes ellenőrzést ad a kiadónak afelett, hogy mely azonosítókat terjesztik. A működő minta az, hogy az analitikai kapu zárása esetén átmeneti munkamenet-azonosítót adjunk át a Decision Service-nek, és csak a kapu megnyílásakor váltsunk a tartós azonosítóra. A Decision Service által visszaadott változat-hozzárendelések még mindig alkalmazhatók a megjelenített oldalra; ami változik, az az, hogy stabil látogatói rekordhoz vannak-e kötve.

Az integráció és az auditnyom érvényesítése

Az érvényesítési lépés az, amit a hatóságok ellenőriznek, és amit a kiadók a leggyakrabban kihagynak a kísérletezési eszközöknél. Egy helyesen integrált Optimizely-bevezetésnek sorban négy teszten kell átmennie. Először, egy tiszta böngésző-munkamenetnek, amelyen a banner látható, de nem történt választás, nulla kérést kell produkálnia a logx.optimizely.com felé az SDK-fájl lekérésén túl és nulla optimizely sütit a document.cookie-ban. Másodszor, az analitika elutasításának meg kell tartania ezt az állapotot — nem tartós azonosító, nem döntési esemény, nem stabil rekordhoz kötött változat-hozzárendelés. Harmadszor, az analitika elfogadásának elő kell állítania a várt optimizelyEndUserId sütit és döntési esemény-forgalmat, helyesen alkalmazott változat-hozzárendeléssel. Negyedszer, a hozzájárulás visszavonásának azonnal le kell állítania a további döntési eseményeket, le kell járatnia a sütiket, és terjesztenie kell a kijelentkezést az összes alsóbb analitikai integrációba.

Az EDPB 2023-as cookie-banner iránymutatásai és a 2026-os megújított munkacsoport-prioritások szerinti auditnyom-elvárás az, hogy a kiadó bármely konkrét kísérleti megjelenítésre az Optimizely-projektben bizonyítani tudja, hogy a látogató a megjelenítés pillanatában érvényes hozzájárulást adott. A szabványos minta az, hogy az SDK attribútum API-ján keresztül a hozzájárulás verzióját és időbélyegét egyéni attribútumként állítják be az Optimizely látogatói profilján, hogy bármely egyéni megjelenítés visszakövethető legyen egy meghatározott hozzájárulási naplóbejegyzésig. Egy megfelelően lezárt bevezetés, párosítva névtelen-mód kezeléssel a hozzájárulás előtti megjelenítési döntésekhez és egy lefelé terjedő visszavonási útvonallal, az, ami az Optimizelyt egy rejtett kísérletezési szintű felelősségből a kiadó termékének és növekedési stackjének védhető részévé alakítja.