Защо 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, Обединеното кралство и всяка юрисдикция, внедрила същия стандарт. Свързването на присвояванията на експериментални варианти с този идентификатор в различни сесии е обработка на лични данни съгласно GDPR, тъй като комбинацията от идентификатор, IP адрес и показване на вариант е достатъчна, за да идентифицира отделно лице и да характеризира взаимодействието му с програмата за експерименти. Разпространението на данните за варианти между инструменти — например Optimizely разкрива присвояването на варианта към Google Analytics — добавя аналитичната порта към веригата. Насоките на EDPB от 2023 г. изрично заявиха, че експериментирането, ангажиращо постоянна идентификация, е обект на същите правила за съгласие като анализите; CNIL беше най-гласовитият регулатор по този въпрос, но не е единственият.

Какво записва Optimizely преди съгласие — и какво трябва да бъде потиснато

Стандартният фрагмент на Optimizely инсталира JavaScript SDK директно в заглавната секция на страницата и се инициализира незабавно при зареждане. Това е документираното бързо начало и източникът на най-честата грешка в съответствието: SDK работи преди банерът с бисквитките да е рендиран, бисквитката optimizelyEndUserId се записва в рамките на милисекунди, присвояването на варианта се прави и събитието за решение се изпраща независимо от това, което посетителят решава по-късно. Всеки европейски регулатор, произнесъл се по този модел, е постановил по един и същ начин: бисквитките, зададени преди съгласие, са незаконни, присвояването на вариант, записано преди съгласие, е незаконна обработка, а издателят носи отговорността.

Следователно съответстваща интеграция трябва да предотврати записването на постоянния идентификатор от Optimizely и изпращането на събития за решение до предоставянето на съответната категория съгласие. Optimizely поддържа два модела за това. Първият е специалният атрибут за съгласие — предаване на OPTIMIZELY_OPT_OUT=true като низ от заявка или задаване на бисквитката optimizely.opt_out преди инициализацията на SDK — което поставя SDK в режим на отказ, при който не се записва идентификатор и не се изпращат събития. Вторият е режимът само за анонимни, поддържан в конфигурацията на SDK, при който SDK работи в режим без сесии, присвоявайки варианти само въз основа на локална за сесията идентификация, без постоянна идентификация между посещенията. Анонимният режим позволява на програмата за експерименти да работи на основата на законен интерес за решението за рендиране, отлагайки постоянната идентификация до предоставяне на съгласие.

Бисквитките и хранилището, записвани от Optimizely

Optimizely Web Experimentation SDK записва следните идентификатори при инициализация, всички от които са несъществени и изискват съгласие: 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, излагащ събитие за промяна на съгласие в реално време, отложена начална зареждане, инициализираща Optimizely SDK с активиран отказ или активен анонимен режим, слушател за съгласие, превключващ SDK от режим на отказ и стартиращ постоянна идентификация, когато аналитичната порта се отваря, и път за оттегляне, поставящ SDK обратно в режим на отказ, изтичащ бисквитките optimizely чрез document.cookie и разпространяващ оттеглянето към всякакви последващи аналитични интеграции.

Уеб имплементация с отложеното начално зареждане

В уеб средата най-чистият модел е да се зареди фрагментът на 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 чрез attribute API на SDK, така че всяко индивидуално показване да може да бъде проследено обратно до конкретен запис в дневника за съгласие. Правилно ограденото внедряване, съчетано с обработка в анонимен режим за решенията за рендиране преди съгласие и път за оттегляне, разпространяващ се надолу по веригата, е това, което превръща Optimizely от скрита отговорност на ниво слой за експерименти в защитима част от продукта и стека за растеж на издателя.