Зашто Optimizely Web Experimentation захтева сагласност

Подразумевана иницијализација Optimizely ради неколико ствари при првом приказивању странице: поставља колачић прве стране под кључем optimizelyEndUserId који садржи трајни идентификатор посетиоца; вреднује посетиоца у односу на активне експерименте; записује додељивање варијанта у други колачић под кључем optimizelyOptOut; покреће догађај одлуке ка logx.optimizely.com; и примењује измене варијанта на приказаној страници. Ако оператери повежу аналитичке интеграције – Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap или Optimizely Data Platform – SDK такође покреће догађаје приказа варијанта ка аналитичком слоју, везујући варијант за шири аналитички профил посетиоца.

Свака од ових активности активира засебан услов сагласности. Трајност идентификатора посетиоца је операција складиштења и приступа у складу са чланом Article 5(3) Директиве ePrivacy, која захтева претходну, слободно дату, специфичну, информисану и недвосмислену сагласност у EEA, UK и свим јурисдикцијама које су усвојиле исте стандарде. Везивање додељивања експерименталног варијанта за тај идентификатор током сесије је обрада личних података у складу са GDPR-ом, јер је комбинација идентификатора, IP адресе и приказа варијанта довољна за идентификацију појединца и карактеризацију њихових интеракција са програмом експеримената. Ширење података варијанта између алата – на пример кад Optimizely преноси варијант у Google Analytics – додаје аналитичку капију у ланац. EDPB смернице из 2023. године изричито наводе да су експерименти који укључују трајну идентификацију подложни истим правилима сагласности као аналитика. CNIL је био најгласнији регулаторни орган по овом питању, али не и једини.

Шта Optimizely записује пре сагласности – шта треба сузбити

Стандардни snippet Optimizely инсталира JavaScript SDK директно у head странице и иницијализује га одмах при учитавању. Ово је документовани quickstart и најчешћи узрок неусаглашености. SDK се извршава пре приказивања банера колачића: колачић optimizelyEndUserId се записује у милисекундама, врше се додељивања варијаната и покрећу се догађаји одлуке – без обзира на то шта посетилац касније одлучи. Сваки европски регулаторни орган који је оценио овај образац дошао је до истог закључка: колачићи постављени пре сагласности су незаконити; додељивања варијаната снимљена пре сагласности су незаконита обрада; и издавач је одговоран.

Усаглашена интеграција мора спречити Optimizely да записује трајне идентификаторе у колачиће и покреће догађаје одлуке све до доделе релевантне категорије сагласности. Optimizely подржава два обрасца за то. Први је посвећени атрибут сагласности: прослеђивање OPTIMIZELY_OPT_OUT=true као query string или постављање колачића optimizely.opt_out пре иницијализације SDK поставља SDK у режим одустајања – нема записивања идентификатора, нема покретања догађаја. Други је само анонимни режим, подржан у конфигурацији SDK: SDK ради у режиму без сесије, додељујући варијанте само на основу локалних идентификатора сесије без трајне идентификације кроз посете. Анонимни режим омогућава програму експеримената да ради на бази легитимног интереса за одлуке приказивања, одлажући трајну идентификацију до доделе сагласности.

Колачићи и складиштење које Optimizely записује

SDK Optimizely Web Experimentation записује следеће идентификаторе при иницијализацији – сви су неосновни и захтевају сагласност: optimizelyEndUserId, трајни идентификатор посетиоца са роком истека од неколико година; маркер optimizelyOptOut који прати статус одустајања; optimizelyDomainTestCookie за експерименте међу поддоменима; и додатне колачиће именског простора ако је оператер омогућио идентификацију међу доменима. Опозив сагласности мора обавити и истек колачића и постављање SDK у режим одустајања путем optimizely.push({ type: 'user', attributes: { opt_out: true } }), заустављајући даље прикупљање догађаја.

Мапирање Optimizely на оквире сагласности

Optimizely не имплементира нативно IAB TCF или IAB Global Privacy Platform – то је платформа за експериментисање прве стране, а не добављач адтеха. Али излаже нативни API за одустајање, подржава документовану интеграцију Consent Mode преко Optimizely Data Platform и поштује CMP издавача преко атрибута OPTIMIZELY_OPT_OUT. Образац који преживљава регулаторни надзор третира сваку Optimizely функцију као засебну капију везану за одређени CMP сигнал.

• Анонимни експерименти могу да раде на бази легитимног интереса са локалним идентификаторима сесије. Ово је погодно за одлуке приказивања које не захтевају трајну идентификацију кроз посете и не шире се на аналитику низводно. Овај режим је везан за строго неопходну или функционалну категорију.
• Трајни експерименти са стабилним идентификаторима су везани за аналитичке сврхе. У TCF терминологији ово се мапира на Сврху 8 у комбинацији са Сврхом 1. У Consent Mode-у се мапира на analytics_storage.
• Интеграције међу алатима (догађаји приказа варијанта проширени на Google Analytics, Amplitude или Optimizely Data Platform) наслеђују аналитичку капију од алата примаоца и не би требало да се покрећу ако капија тог алата није дата.
• Персонализација и циљање засновано на публици изграђени на експериментима покрећу маркетиншку капију кад прелазе са експерименталног мерења на циљање на нивоу корисника.

Обрасци интеграције који функционишу

Референтна имплементација има четири дела: CMP који објављује догађаје промена сагласности у реалном времену; одложени bootstrap који иницијализује SDK Optimizely са омогућеним одустајањем или активним анонимним режимом; слушалац сагласности који пребацује SDK из одустајања на трајну идентификацију кад се аналитичка капија отвори; и пут опозива који враћа SDK у режим одустајања, истиче колачиће optimizely преко document.cookie и шири опозив на аналитичке интеграције низводно.

Веб имплементација са одложеним bootstrapом

На вебу, најчистији образац је учитати snippet Optimizely са постављеним window.optimizelyOptOut = true пре иницијализације SDK. Претплатите се на догађаје промена сагласности CMP-а. Кад аналитичка категорија пређе на true, позовите window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) и пустите SDK да се иницијализује нормално. Кад се капија опозове, вратите атрибут одустајања на true, истекните колачић optimizelyEndUserId и проширите промену на интегрисане аналитичке платформе преко њихових одговарајућих API-ја за сагласност.

Серверски експерименти преко Decision Service

Optimizely такође подржава серверске експерименте преко Decision Service API-ја. Серверске одлуке нису изузете од сагласности – правна основа прати податке. Али серверско извршавање омогућава издавачима да имају потпуну контролу над тим који идентификатори се шире. Образац који функционише је прослеђивање ефемерног идентификатора сесије Decision Service-у кад је аналитичка капија затворена, и прелазак на трајни идентификатор само кад је капија отворена. Додељивања варијаната које Decision Service враћа и даље се могу применити на приказаној страници – шта се мења је да ли су везана за стабилни запис посетиоца.

Верификација интеграције и траг ревизије

Кораци верификације су оно што регулаторни органи проверавају, и оно што издавачи најчешће прескачу у алатима за експериментисање. Правилно интегрисана Optimizely имплементација мора да прође четири теста редом. Прво, чиста сесија прегледача са видљивим банером али без извршеног избора мора да покаже нулти саобраћај ка logx.optimizely.com осим преузимања SDK датотеке, и нула колачића optimizely у document.cookie. Друго, одбијање аналитике мора да одржи то стање: нема трајних идентификатора, нема догађаја одлуке, нема додељивања варијаната везаних за стабилне записе. Треће, прихватање аналитике би требало да произведе очекиване колачиће optimizelyEndUserId и саобраћај догађаја одлуке, са правилно примењеним додељивањима варијаната. Четврто, опозив сагласности би требало одмах да заустави даље догађаје одлуке, истекне колачиће и прошири одустајање на аналитичке интеграције низводно.

Очекивања трага ревизије под EDPB смерницама за банере колачића из 2023. и ажурираним приоритетима радне групе из 2026. су да издавачи могу доказати да је посетилац пружио важећу сагласност у тренутку приказа за специфичне експерименталне приказе у Optimizely пројекту. Стандардни образац је постављање верзије сагласности и временске ознаке као прилагођених атрибута у Optimizely профилу посетиоца преко API-ја атрибута SDK, тако да сваки приказ може бити праћен уназад до одређеног уноса у евиденцији сагласности. Правилно заштићена имплементација, у комбинацији са анонимним режимом за одлуке приказивања пре сагласности и путем опозива који шири низводно, трансформише Optimizely из скривеног дуга слоја експеримената у одбрањиви део стека производа и раста издавача.