Почему Optimizely Web Experimentation требует согласия

Инициализация Optimizely по умолчанию делает несколько вещей в первой отрисовке страницы. Она устанавливает первичный cookie под optimizelyEndUserId, содержащий постоянный идентификатор посетителя, оценивает посетителя относительно активных экспериментов, записывает назначения вариантов во второй cookie под маркерами пространства имён optimizelyOptOut, излучает событие решения на logx.optimizely.com и применяет изменения варианта к отображённой странице. Когда оператор подключил интеграцию аналитики — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap или Optimizely Data Platform — SDK также излучает события экспозиции варианта в слой аналитики, который затем привязывает вариант к более широкому аналитическому профилю посетителя.

Каждая из этих деятельностей задействует отдельные ворота согласия. Сохранение идентификатора посетителя — это операция хранения и доступа по статье 5(3) Директивы ePrivacy, требующая предварительного, свободно данного, конкретного, информированного и однозначного согласия в ЕЭП, Великобритании и любой юрисдикции, импортировавшей тот же стандарт. Привязка назначений экспериментальных вариантов к этому идентификатору через сессии является обработкой персональных данных по GDPR, потому что комбинация идентификатора, IP-адреса и экспозиции варианта достаточна для выделения лица и характеристики его взаимодействия с программой экспериментирования. Кросс-инструментальное распространение данных варианта — Optimizely, раскрывающий назначение варианта для Google Analytics, например — добавляет ворота аналитики к цепочке. Руководство EDPB 2023 года было явным, что экспериментирование, задействующее постоянную идентификацию, подчиняется тем же правилам согласия, что и аналитика; CNIL был самым выразительным регулятором по этому пункту, но не единственным.

Что Optimizely записывает до согласия — и что должно быть подавлено

Стандартный фрагмент Optimizely устанавливает JavaScript SDK напрямую в head страницы и инициализируется немедленно при загрузке. Это документированный быстрый старт и источник наиболее распространённого сбоя соответствия: SDK запускается до того, как баннер cookie отобразился, cookie optimizelyEndUserId записывается в течение миллисекунд, назначение варианта делается, и событие решения излучается независимо от того, что посетитель позже решит. Каждый европейский регулятор, принявший решение по этому шаблону, принял одно и то же решение: cookie, установленные до согласия, незаконны, назначение варианта, захваченное до согласия, является незаконной обработкой, и издатель несёт ответственность.

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

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

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

Веб-реализация с отложенной загрузкой

В вебе самый чистый шаблон — загрузить фрагмент Optimizely с установленным window.optimizelyOptOut = true до инициализации SDK. Подпишитесь на событие изменения согласия CMP. Когда категория аналитики переходит в true, вызовите window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) и дайте SDK инициализироваться нормально. Когда ворота отзываются, передайте атрибут отказа обратно в true, истеките cookie optimizelyEndUserId и распространите изменение на любые интегрированные платформы аналитики через их соответствующие API согласия.

Серверное экспериментирование через Decision Service

Optimizely также поддерживает серверное экспериментирование через API Decision Service. Серверные решения не освобождены от согласия — правовое основание идёт за данными — но серверное выполнение даёт издателю полный контроль над тем, какие идентификаторы распространяются. Шаблон, который работает, — передать эфемерный идентификатор сессии в Decision Service, когда ворота аналитики закрыты, и переключиться на постоянный идентификатор только когда ворота открыты. Назначения вариантов, возвращённые Decision Service, всё ещё могут быть применены к отображённой странице; что меняется — это то, привязаны ли они к стабильной записи посетителя.

Проверка интеграции и аудиторский след

Шаг проверки — это то, что проверяют регуляторы и что издатели чаще всего пропускают на инструментах экспериментирования. Правильно интегрированное развёртывание Optimizely должно пройти четыре теста в последовательности. Во-первых, чистая сессия браузера с показанным баннером, но без сделанного выбора, должна производить ноль запросов к logx.optimizely.com, кроме выборки файла SDK, и ноль cookie optimizely в document.cookie. Во-вторых, отказ от аналитики должен сохранять это состояние — без постоянного идентификатора, без события решения, без назначения варианта, привязанного к стабильной записи. В-третьих, принятие аналитики должно производить ожидаемый cookie optimizelyEndUserId и трафик событий решения, с правильно применённым назначением варианта. В-четвёртых, отзыв согласия должен немедленно остановить дальнейшие события решения, истечь cookie и распространить отказ на любые аналитические интеграции вниз.

Ожидание аудиторского следа по руководству EDPB по баннерам cookie 2023 года и обновлённым приоритетам целевой группы 2026 года в том, что издатель может доказать для любой конкретной экспериментальной экспозиции в проекте Optimizely, что посетитель дал действительное согласие в момент экспозиции. Стандартный шаблон — установить версию согласия и временную метку как пользовательский атрибут в профиль посетителя Optimizely через API атрибутов SDK, так чтобы любая отдельная экспозиция была отслеживаемой назад к конкретной записи журнала согласия. Правильно обусловленное развёртывание в сочетании с обработкой анонимного режима для решений об отрисовке до согласия и путём отзыва, распространяющимся вниз, — это то, что превращает Optimizely из скрытой ответственности уровня экспериментирования в защитимую часть продуктового стека и стека роста издателя.