Optimizely Web Experimentation slapukų sutikimo integravimo vadovas: A/B testavimas pagal GDPR 2026 m.

Optimizely užima keistą poziciją sutikimo diskusijose. Protingas žmogus, žvelgiantis į eksperimentavimo įrankį, gali manyti, kad tai yra mažos rizikos kategorija – juk testai skirti tam, kokios spalvos mygtukas sulaukia daugiau paspaudimų, o ne tam, kas yra lankytojas. Tačiau tikrovė pagal GDPR nustatytą ir EDPB nuo 2023 m. aktyviai taikomą sistemą yra tokia, kad kiekvieną kartą, kai platforma įrašo nuolatinį identifikatorių ir susieja su juo eksperimentinį variantą, eksperimentas apima lygiai tas pačias apdorojimo kategorijas kaip analizė ar rinkodara. Optimizely Web Experimentation SDK daro būtent tai: sumaišo nuolatinį identifikatorių, kad priskirtų lankytojus variantams, įrašo priskyrimą į pirmos šalies slapuką, kad lankytojai matytų tą patį variantą per visą sesiją, ir skleidžia rodymų bei konversijų įvykius, susietus su tuo identifikatoriumi. Kiekvienas iš šių žingsnių suaktyvina sutikimo sąlygą. Geroji žinia – Optimizely turi vieną apgalvotiausių sutikimo integravimų eksperimentavimo kategorijoje: specialų sutikimo atributą ir galimybę veikti tik anoniminiu režimu. Iššūkis yra tai, kad reikia iš tikrųjų jais naudotis.

Kodėl Optimizely Web Experimentation reikalauja sutikimo

Numatytoji Optimizely inicijavimo procedūra atlieka keletą veiksmų pirmajame puslapio atvaizdavime: nustato pirmos šalies slapuką su raktu optimizelyEndUserId, kuriame yra nuolatinis lankytojo identifikatorius; įvertina lankytoją aktyvių eksperimentų atžvilgiu; įrašo varianto priskyrimą į antrą slapuką su raktu optimizelyOptOut; suaktyvina sprendimo įvykį į logx.optimizely.com; ir taiko varianto pakeitimus atvaizduotame puslapyje. Jei operatoriai sujungia analizės integracijas – Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap arba Optimizely Data Platform – SDK taip pat suaktyvina varianto rodymo įvykius į analizės sluoksnį, siejant variantą su platesniais lankytojo analizės profiliais.

Kiekviena iš šių veiklų suaktyvina atskirą sutikimo sąlygą. Nuolatinio identifikatoriaus saugojimas yra saugojimo ir prieigos operacija pagal ePrivacy direktyvos Article 5(3), reikalaujanti išankstinio, laisvo, konkretaus, informuoto ir nedviprasmiško sutikimo EEA, UK ir visose jurisdikcijose, priėmusiose tuos pačius standartus. Eksperimentinio varianto priskyrimo susiejimas su tuo identifikatoriumi per sesiją yra asmens duomenų tvarkymas pagal GDPR, nes identifikatoriaus, IP adreso ir varianto rodymo derinys yra pakankamas asmeniui identifikuoti ir apibūdinti jo sąveiką su eksperimentų programa. Varianto duomenų perdavimas tarp įrankių – pavyzdžiui, kai Optimizely perduoda variantą į Google Analytics – prideda analizės sąlygą į grandinę. EDPB 2023 m. rekomendacijos aiškiai teigia, kad eksperimentai su nuolatiniu identifikavimu patenka į tas pačias sutikimo taisykles kaip analizė. CNIL buvo garsiausia institucija šiuo klausimu, bet ne vienintelė.

Ką Optimizely įrašo prieš sutikimą – ką reikia slopinti

Standartinis Optimizely fragmentas įdiegia JavaScript SDK tiesiogiai puslapio antraštėje ir inicijuoja jį iš karto įkeliant. Tai yra dokumentuotas greito pradžios metodas ir dažniausia atitikties klaida. SDK vykdomas prieš slapukų juostos atvaizdavimą: optimizelyEndUserId slapukas įrašomas per milisekundes, vykdomi varianto priskyrimai ir suaktyvinami sprendimo įvykiai – neatsižvelgiant į tai, ką lankytojas vėliau nusprendžia. Kiekviena Europos reguliavimo institucija, nagrinėjusi šį modelį, priėjo prie tos pačios išvados: slapukai, nustatyti prieš sutikimą, yra neteisėti; varianto priskyrimai, užfiksuoti prieš sutikimą, yra neteisėtas apdorojimas; ir leidėjas yra atsakingas.

Atitinkama integracija turi užkirsti kelią Optimizely įrašyti nuolatinius identifikatorius į slapukus ir suaktyvinti sprendimo įvykius, kol nesuteikiama atitinkama sutikimo kategorija. Optimizely palaiko du šiam tikslui skirtus modelius. Pirmas yra specialus sutikimo atributas: perduodant OPTIMIZELY_OPT_OUT=true kaip užklausos eilutę arba nustatant optimizely.opt_out slapuką prieš SDK inicijavimą, SDK nustatomas atsisakymo režimas – identifikatoriai neįrašomi, įvykiai nesuaktyvinami. Antras yra tik anoniminis režimas, palaikomas SDK konfigūracijoje: SDK veikia be sesijos režimo, priskirdamas variantus tik pagal sesijos lokalius identifikatorius be nuolatinio identifikavimo per visus apsilankymus. Anoniminis režimas leidžia eksperimentų programai veikti teisėto intereso pagrindu atvaizdavimo sprendimams, atidedant nuolatinį identifikavimą iki suteikiamo sutikimo.

Optimizely įrašomi slapukai ir saugykla

Optimizely Web Experimentation SDK inicijavimo metu įrašo šiuos identifikatorius – visi jie yra neprivalomi ir reikalauja sutikimo: optimizelyEndUserId, nuolatinis lankytojo identifikatorius su kelerių metų galiojimo laiku; optimizelyOptOut žymeklis, sekantis atsisakymo būseną; optimizelyDomainTestCookie kryžminio subdomeno eksperimentams; ir papildomi vardų srities slapukai, jei operatorius įgalino kryžminio domeno identifikavimą. Sutikimo atšaukimas turi tiek ištrinti slapukus, tiek nustatyti SDK į atsisakymo režimą per optimizely.push({ type: 'user', attributes: { opt_out: true } }), sustabdant tolesnį įvykių rinkimą.

Optimizely susiejimas su sutikimo sistemomis

Optimizely nesavaimingai įgyvendina IAB TCF ar IAB Global Privacy Platform – tai nėra reklamos technologijų tiekėjas, o pirmos šalies eksperimentavimo platforma. Tačiau ji atskleidžia savąją atsisakymo API, palaiko dokumentuotą Consent Mode integraciją per Optimizely Data Platform ir gerbia leidėjo CMP per OPTIMIZELY_OPT_OUT atributą. Modelis, išgyvenantis reguliavimo patikrinimą, kiekvieną Optimizely funkciją traktuoja kaip atskirą sąlygą, susietą su konkrečiu CMP signalu.

Veikiantys integravimo modeliai

Referencinis diegimas turi keturias dalis: CMP, skelbiantis realaus laiko sutikimo pakeitimų įvykius; atidėtas bootstrap, inicijuojantis Optimizely SDK su įgalintu atsisakymu arba aktyviu anoniminiu režimu; sutikimo klausytojas, perjungiantis SDK iš atsisakymo į nuolatinį identifikavimą, kai atsidaro analizės sąlyga; ir atšaukimo kelias, grąžinantis SDK į atsisakymo režimą, ištrinantis optimizely slapukus per document.cookie ir perduodantis atšaukimą žemiau esančioms analizės integracijos.

Žiniatinklio diegimas su atidėtu bootstrap

Žiniatinklyje švaresnis modelis yra įkelti Optimizely fragmentą su window.optimizelyOptOut = true, nustatytu prieš SDK inicijavimą. Prenumeruokite CMP sutikimo pakeitimų įvykius. Kai analizės kategorija pereina į true, iškvieskite window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) ir leiskite SDK inicijuotis įprastai. Kai sąlyga atšaukiama, grąžinkite atsisakymo atributą į true, ištrinkite optimizelyEndUserId slapuką ir perduokite pakeitimą integruotoms analizės platformoms per jų atitinkamas sutikimo API.

Serverio pusės eksperimentai per Decision Service

Optimizely taip pat palaiko serverio pusės eksperimentus per Decision Service API. Serverio pusės sprendimai nėra atleisti nuo sutikimo – teisinė bazė seka duomenis. Tačiau serverio pusės vykdymas suteikia leidėjams visišką kontrolę, kurie identifikatoriai perduodami. Veikiantis modelis yra perduoti efemerišką sesijos identifikatorių į Decision Service, kai analizės sąlyga uždaryta, ir perjungti į nuolatinį identifikatorių tik tada, kai sąlyga atidaryta. Varianto priskyrimai, grąžinami iš Decision Service, vis tiek gali būti taikomi atvaizduotame puslapyje – keičiasi tik tai, ar jie susieti su stabiliu lankytojo įrašu.

Integravimo patvirtinimas ir audito pėdsakas

Patvirtinimo veiksmai yra tai, ką tikrina reguliavimo institucijos, ir tai, ką leidėjai dažniausiai praleidžia eksperimentavimo įrankiuose. Teisingai integruotas Optimizely diegimas turi sėkmingai išlaikyti keturis testus iš eilės. Pirma, švari naršyklės sesija su rodoma juosta, bet be atlikto pasirinkimo, turi rodyti nulinę srautą į logx.optimizely.com, išskyrus SDK failo paimdymą, ir nulius optimizely slapukų document.cookie. Antra, analizės atsisakymas turi išlaikyti tą būseną: jokių nuolatinių identifikatorių, jokių sprendimo įvykių, jokių varianto priskyrimų, susietų su stabiliais įrašais. Trečia, analizės priėmimas turi sukurti tikėtinus optimizelyEndUserId slapukus ir sprendimo įvykių srautą, o varianto priskyrimai turi būti teisingai pritaikyti. Ketvirta, sutikimo atšaukimas turi nedelsdamas sustabdyti tolesnius sprendimo įvykius, ištrinti slapukus ir perduoti atsisakymą žemiau esančioms analizės integracijos.

Audito pėdsako lūkesčiai pagal EDPB 2023 m. slapukų juostos gaires ir 2026 m. atnaujintus darbo grupės prioritetus yra tokie, kad leidėjai gali įrodyti, jog lankytojas pateikė galiojantį sutikimą rodymo momentu konkretiems eksperimentiniams rodymams Optimizely projekte. Standartinis modelis yra nustatyti sutikimo versiją ir laiko žymą kaip pasirinktinius atributus Optimizely lankytojo profilyje per SDK atributų API, kad kiekvienas rodymas būtų atsekamas iki konkretaus sutikimo žurnalo įrašo. Teisingai užblokuotas diegimas, derinamas su anoniminiu režimu, skirtu ikisutikimo atvaizdavimo sprendimams, ir atšaukimo keliu, perduodančiu žemiau, paverčia Optimizely iš paslėptos eksperimentų sluoksnio skola į gynybinę leidėjo produkto ir augimo krūvos dalį.

← Tinkladevlaraderegistris Skaityti viską →