Optimizely Web Experimentation sīkdatņu piekrišanas integrācijas rokasgrāmata: A/B testēšana saskaņā ar GDPR 2026. gadā
Optimizely ieņem dīvainu pozīciju piekrišanas diskusijās. Saprātīgs cilvēks, skatoties uz eksperimentēšanas rīku, var domāt, ka tā ir zema riska kategorija – testi ir par to, kuras krāsas poga saņem vairāk klikšķu, nevis par to, kas ir apmeklētājs. Taču realitāte saskaņā ar GDPR noteikto un EDPB aktīvi ieviestu regulējumu kopš 2023. gada ir tāda, ka ikreiz, kad platforma ieraksta pastāvīgu identifikatoru un saista ar to eksperimentālu variantu, eksperiments ietver tieši tās pašas apstrādes kategorijas kā analītika vai mārketings. Optimizely Web Experimentation SDK dara tieši to: jaukts pastāvīgs identifikators, lai piešķirtu apmeklētājus variantiem, ieraksta piešķīrumu pirmās puses sīkdatnē, lai apmeklētāji redzētu vienu un to pašu variantu visā sesijā, un izstaro parādīšanas un konversijas notikumus, kas piesaistīti šim identifikatoram. Katrs no šiem soļiem aktivizē piekrišanas nosacījumu. Labā ziņa ir tā, ka Optimizely ir viena no pārdomātākajām piekrišanas integrācijām eksperimentēšanas kategorijā: īpašs piekrišanas atribūts un iespēja darboties tikai anonīmā režīmā. Izaicinājums ir faktiski to izmantot.
Kāpēc Optimizely Web Experimentation prasa piekrišanu
Noklusējuma Optimizely inicializācija veic vairākas darbības pirmajā lapas renderēšanā: iestata pirmās puses sīkdatni ar atslēgu optimizelyEndUserId, kas satur pastāvīgu apmeklētāja identifikatoru; novērtē apmeklētāju pret aktīvajiem eksperimentiem; ieraksta varianta piešķīrumu otrajā sīkdatnē ar atslēgu optimizelyOptOut; aktivizē lēmuma notikumu uz logx.optimizely.com; un piemēro varianta izmaiņas renderētajai lapai. Ja operatori savieno analītisko integrāciju – Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap vai Optimizely Data Platform – SDK arī aktivizē varianta parādīšanas notikumus analītiskajā slānī, saistot variantu ar apmeklētāja plašāko analītisko profilu.
Katra no šīm aktivitātēm aktivizē atsevišķu piekrišanas nosacījumu. Pastāvīgā identifikatora saglabāšana ir glabāšanas un piekļuves darbība saskaņā ar ePrivacy direktīvas Article 5(3), kas prasa iepriekšēju, brīvprātīgi sniegtu, konkrētu, informētu un nepārprotamu piekrišanu EEA, UK un visās jurisdikcijās, kas pieņēmušas tos pašus standartus. Eksperimentālā varianta piešķīruma saistīšana ar šo identifikatoru visā sesijā ir personas datu apstrāde saskaņā ar GDPR, jo identifikatora, IP adreses un varianta parādīšanas kombinācija ir pietiekama, lai identificētu personu un raksturotu tās mijiedarbību ar eksperimentu programmu. Varianta datu pārnešana starp rīkiem – piemēram, kad Optimizely nodod variantu Google Analytics – pievieno analītiskās nosacīšanas nosacījumu ķēdei. EDPB 2023. gada vadlīnijas skaidri norāda, ka eksperimenti ar pastāvīgu identifikāciju ir pakļauti tiem pašiem piekrišanas noteikumiem kā analītika. CNIL bija visskaiļāk runājošā iestāde šajā jautājumā, bet ne vienīgā.
Ko Optimizely ieraksta pirms piekrišanas – kas jāaptur
Standarta Optimizely koda fragments instalē JavaScript SDK tieši lapas galvenē un inicializē to nekavējoties ielādes laikā. Tas ir dokumentētais ātro sākumu veids un visizplatītākais atbilstības pārkāpums. SDK tiek izpildīts pirms sīkdatņu joslas renderēšanas: optimizelyEndUserId sīkdatne tiek ierakstīta milisekundēs, varianta piešķīrumi tiek veikti un lēmuma notikumi tiek aktivizēti – neatkarīgi no tā, ko apmeklētājs vēlāk nolemj. Katra Eiropas regulatīvā iestāde, kas izskatīja šo modeli, nonāca pie vienas un tās pašas secinājuma: pirms piekrišanas iestatītas sīkdatnes ir nelikumīgas; varianta piešķīrumi, kas fiksēti pirms piekrišanas, ir nelikumīga apstrāde; un izdevējs ir atbildīgs.
Atbilstoša integrācija jānovērš, ka Optimizely ieraksta pastāvīgos identifikatorus sīkdatnēs un aktivizē lēmuma notikumus, līdz tiek piešķirta attiecīgā piekrišanas kategorija. Optimizely atbalsta divus šim nolūkam paredzētus modeļus. Pirmais ir īpašs piekrišanas atribūts: nododot OPTIMIZELY_OPT_OUT=true kā vaicājumu virkni vai iestatot optimizely.opt_out sīkdatni pirms SDK inicializācijas, SDK tiek iestatīts atteikšanās režīmā – identifikatori netiek ierakstīti, notikumi netiek aktivizēti. Otrais ir tikai anonīmais režīms, ko atbalsta SDK konfigurācija: SDK darbojas bez sesijas režīma, piešķirot variantus tikai pamatojoties uz sesijas lokālajiem identifikatoriem bez pastāvīgas identifikācijas visā apmeklējumā. Anonīmais režīms ļauj eksperimentu programmai darboties uz leģitīmo interešu pamata renderēšanas lēmumiem, atliekot pastāvīgu identifikāciju līdz piešķirtajai piekrišanai.
Optimizely ierakstītās sīkdatnes un krātuve
Optimizely Web Experimentation SDK inicializācijas laikā ieraksta šādus identifikatorus – visi tie ir neobligāti un prasa piekrišanu: optimizelyEndUserId, pastāvīgs apmeklētāja identifikators ar vairāku gadu derīguma termiņu; optimizelyOptOut marķieris, kas izseko atteikšanās stāvokli; optimizelyDomainTestCookie starpapakšdomēnu eksperimentiem; un papildu nosaukumtelpas sīkdatnes, ja operators ir iespējojis starpdomēnu identifikāciju. Piekrišanas atsaukšanai jāveic gan sīkdatņu derīguma termiņa beigšanās, gan SDK iestatīšana atteikšanās režīmā, izmantojot optimizely.push({ type: 'user', attributes: { opt_out: true } }), pārtraucot turpmāku notikumu vākšanu.
Optimizely kartēšana piekrišanas ietvariem
Optimizely nevietiskā veidā neīsteno IAB TCF vai IAB Global Privacy Platform – tā nav reklāmas tehnoloģijas piegādātāja, bet gan pirmās puses eksperimentēšanas platforma. Tomēr tā atklāj vietējo atteikšanās API, atbalsta dokumentētu Consent Mode integrāciju, izmantojot Optimizely Data Platform, un respektē izdevēja CMP, izmantojot OPTIMIZELY_OPT_OUT atribūtu. Modelis, kas izdzīvo regulatīvo pārbaudi, katru Optimizely funkciju uzskata par atsevišķu nosacījumu, kas saistīts ar konkrētu CMP signālu.
- Anonīmi eksperimenti var darboties uz leģitīmo interešu pamata ar sesijas lokālajiem identifikatoriem. Tas ir piemērots renderēšanas lēmumiem, kas neprasa pastāvīgu identifikāciju visā apmeklējumā un netiek nodoti pakārtotajai analītikai. Šis režīms ir saistīts ar stingri nepieciešamo vai funkcionālo kategoriju.
- Pastāvīgi eksperimenti ar stabiliem identifikatoriem ir saistīti ar analītikas mērķiem. TCF terminoloģijā tas atbilst 8. mērķim kombinācijā ar 1. mērķi. Consent Mode – analytics_storage.
- Starpinstrumentu integrācijas (varianta parādīšanas notikumi, kas tiek nodoti uz Google Analytics, Amplitude vai Optimizely Data Platform) manto analītikas nosacījumu no saņēmēja rīka un nedrīkst aktivizēties, ja šī rīka nosacījums nav piešķirts.
- Personalizācija un auditorijas mērķēšana, kas veidota uz eksperimentiem, aktivizē mārketinga nosacījumu, jo pārvietojas no eksperimentālā mērījuma uz lietotāja līmeņa mērķēšanu.
Strādājoši integrācijas modeļi
Atsauces izvietojumam ir četras daļas: CMP, kas publicē reāllaika piekrišanas izmaiņu notikumus; atliktais bootstrap, kas inicializē Optimizely SDK ar iespējotu atteikšanos vai aktīvu anonīmo režīmu; piekrišanas klausītājs, kas pārslēdz SDK no atteikšanās uz pastāvīgu identifikāciju, kad analītikas nosacījums tiek atvērts; un atsaukšanas ceļš, kas atgriež SDK atteikšanās režīmā, izbeidz optimizely sīkdatņu derīgumu, izmantojot document.cookie, un nodod atsaukšanu pakārtotajām analītikas integrācijām.
Tīmekļa ieviešana ar atlikto bootstrap
Tīmekļā tīrākais modelis ir ielādēt Optimizely fragmentu ar window.optimizelyOptOut = true, kas iestatīts pirms SDK inicializācijas. Abonējiet CMP piekrišanas izmaiņu notikumus. Kad analītikas kategorija pāriet uz true, izsauciet window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) un ļaujiet SDK inicializēties parasti. Kad nosacījums tiek atsaukts, atgrieziet atteikšanās atribūtu uz true, izbeidziet optimizelyEndUserId sīkdatnes derīgumu un nododiet izmaiņu integrētajām analītikas platformām, izmantojot to attiecīgās piekrišanas API.
Servera puses eksperimenti, izmantojot Decision Service
Optimizely arī atbalsta servera puses eksperimentus, izmantojot Decision Service API. Servera puses lēmumi nav atbrīvoti no piekrišanas – juridiskais pamats seko datiem. Taču servera puses izpilde ļauj izdevējiem pilnībā kontrolēt, kuri identifikatori tiek nodoti. Strādājošais modelis ir nodot efemēru sesijas identifikatoru Decision Service, kad analītikas nosacījums ir aizvērts, un pārslēgties uz pastāvīgu identifikatoru tikai tad, kad nosacījums ir atvērts. Varianta piešķīrumi, ko atgriež Decision Service, joprojām var tikt piemēroti renderētajai lapai – mainās tikai tas, vai tie ir saistīti ar stabilu apmeklētāja ierakstu.
Integrācijas pārbaude un audita pēdas
Pārbaudes soļi ir tas, ko pārbauda regulatīvās iestādes, un tas, ko izdevēji visbiežāk izlaiž eksperimentēšanas rīkos. Pareizi integrētam Optimizely izvietojumam secīgi jāiztur četri testi. Pirmkārt, tīra pārlūkprogrammas sesija ar redzamu joslu, bet bez veiktas izvēles, jāparāda nulles trafiku uz logx.optimizely.com ārpus SDK faila iegūšanas un nulles optimizely sīkdatnes document.cookie. Otrkārt, analītikas atteikšanās jāsaglabā šis stāvoklis: nav pastāvīgu identifikatoru, nav lēmuma notikumu, nav varianta piešķīrumu, kas saistīti ar stabiliem ierakstiem. Treškārt, analītikas pieņemšanai jārada paredzamās optimizelyEndUserId sīkdatnes un lēmuma notikumu trafiks, un varianta piešķīrumiem jābūt pareizi piemērotiem. Ceturtkārt, piekrišanas atsaukšanai nekavējoties jāaptur turpmākie lēmuma notikumi, jāizbeidz sīkdatņu derīgums un jānodod atteikšanās pakārtotajām analītikas integrācijām.
Audita pēdas prasības saskaņā ar EDPB 2023. gada sīkdatņu joslas vadlīnijām un 2026. gada atjauninātajām darba grupas prioritātēm ir tādas, ka izdevēji var pierādīt, ka apmeklētājs sniedza derīgu piekrišanu parādīšanas laikā konkrētiem eksperimentālajiem parādījumiem Optimizely projektā. Standarta modelis ir iestatīt piekrišanas versiju un laika zīmogu kā pielāgotus atribūtus Optimizely apmeklētāja profilā, izmantojot SDK atribūtu API, lai katrs parādījums būtu izsekojams līdz konkrētam piekrišanas žurnāla ierakstam. Pareizi aizsargāts izvietojums, kombinēts ar anonīmo režīmu pirms piekrišanas renderēšanas lēmumiem un atsaukšanas ceļu, kas nodod tālāk, pārveido Optimizely no slēptas eksperimentu slāņa parāda par aizstāvamu izdevēja produkta un izaugsmes kaudzes daļu.