Чому Optimizely Web Experimentation потребує згоди

Стандартна ініціалізація Optimizely виконує кілька дій під час першого відображення сторінки: встановлює файл cookie першої сторони під ключем optimizelyEndUserId, що містить постійний ідентифікатор відвідувача; оцінює відвідувача відносно активних експериментів; записує призначення варіанта у другий файл cookie під ключем 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 записує до отримання згоди – що потрібно пригнічувати

Стандартний фрагмент Optimizely встановлює JavaScript SDK безпосередньо у розділ head сторінки і ініціалізує його негайно під час завантаження. Це задокументований quickstart і найпоширеніша причина порушень відповідності. SDK виконується до відображення банера файлів cookie: файл cookie optimizelyEndUserId записується за мілісекунди, виконуються призначення варіантів і надсилаються події рішень – незалежно від того, що відвідувач вирішить пізніше. Кожен європейський регуляторний орган, який оцінював цю схему, дійшов одного висновку: файли cookie, встановлені до отримання згоди, є незаконними; призначення варіантів, зафіксовані до отримання згоди, є незаконною обробкою; і видавець несе відповідальність.

Відповідна інтеграція повинна запобігати записуванню Optimizely постійних ідентифікаторів у файли cookie та надсиланню подій рішень до надання відповідної категорії згоди. 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, що публікує події зміни згоди в реальному часі; відкладений bootstrap, що ініціалізує SDK Optimizely з увімкненою відмовою або активним анонімним режимом; слухач згоди, що перемикає SDK з відмови на постійну ідентифікацію, коли аналітичний шлюз відкривається; і шлях відкликання, що повертає SDK у режим відмови, закінчує термін дії файлів cookie optimizely через document.cookie і поширює відкликання до аналітичних інтеграцій нижнього потоку.

Веб-реалізація з відкладеним bootstrap

У веб-середовищі найчистіша схема – завантажити фрагмент 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 2023 року щодо банерів файлів cookie та оновлених пріоритетів робочої групи 2026 року полягають у тому, що видавці можуть довести, що відвідувач надав дійсну згоду на момент показу для конкретних експериментальних показів у проекті Optimizely. Стандартна схема – встановити версію згоди та мітку часу як спеціальні атрибути в профілі відвідувача Optimizely через API атрибутів SDK, щоб кожен показ можна було простежити до конкретного запису в журналі згод. Правильно захищене розгортання в поєднанні з анонімним режимом для рішень відображення до отримання згоди та шляхом відкликання, що поширюється вниз, перетворює Optimizely з прихованого боргу шару експериментів на захищувану частину стека продукту та зростання видавця.