Посібник з інтеграції банера згоди з файлами cookie Wix: вбудований CMP, Velo та вбудовування третіх сторін у 2026 році
Wix є стандартною веб-платформою для сотень мільйонів малих підприємств, творців та операторів, які не мають інженерної команди і не хочуть її мати. Сила платформи полягає саме в цьому — розміщений конструктор сайтів, де основна інфраструктура, обробка платежів, управління контентом і все більше маркетингова платформа абстраговані від людини, яка насправді керує сайтом. Саме в цій абстракції концентруються ризики щодо згоди Wix. Платформа постачає вбудований банер згоди з файлами cookie, який оператор може увімкнути за кілька кліків; банер задовольняє поверхневе питання про те, чи існує банер; і оператор рухається далі. Більш складні питання — чи банер насправді запобігає спрацьовуванню тегів до отримання згоди, чи вбудовані елементи HTML третіх сторін та код Velo правильно заблоковані, чи журнал згоди підлягає аудиту, чи розкриття інформації про транскордонну передачу є точним — рідко задаються, а сайт Wix, який їх не задав, не є сайтом Wix, що відповідає вимогам GDPR, ePrivacy або регіональним режимам, які до них приєдналися. Цей посібник пояснює, що потрібно налаштувати і що потрібно додати, щоб розгортання Wix у 2026 році досягло захищеної позиції.
Що насправді робить вбудований банер згоди з файлами cookie Wix
Wix Cookie Consent Banner — доступний для кожного сайту Wix у розділі Settings, Privacy & Compliance — є одним з найбільш функціональних вбудованих інструментів згоди, які постачає будь-яка розміщена платформа. Він підтримує opt-in для кожної категорії Essential, Functional, Analytics та Advertising, може бути налаштований для вимоги явної підтверджувальної дії, підтримує багатомовний контент через шар перекладу сайту та нативно інтегрується з політикою згоди, яку Wix's own Marketing Apps поважають. Коли оператор налаштовує банер для вимоги згоди та вмикає контроль по категоріях, власні інтеграції Wix — Wix Analytics, інтеграція Facebook Pixel, інтеграція Google Ads, інтеграція Google Tag Manager, інтеграція Hotjar — поважають вибір користувача без додаткового підключення.
Те, що банер не робить, і де виникає найпоширеніша невідповідність, — це блокування сторонніх скриптів, які оператор додав через функцію Custom Code Wix, код Velo або вбудовані HTML-віджети. Банер фіксує вибір користувача; завдання оператора — зчитати цей вибір з політики згоди та умовно виконати логіку третьої сторони, яка перебуває поза списком керованих інтеграцій Wix. Шаблон працює після встановлення, але він не є автоматичним.
Стандартної конфігурації недостатньо
Стандартна конфігурація банера, коли оператор вперше його вмикає, передбачає неявну згоду — відвідування сайту трактується як згода, доки відвідувач не відмовиться. Ця позиція була джерелом повторних висновків регуляторів проти сайтів, розміщених на Wix, у всьому EEA, UK та режимах, які приєдналися до GDPR. Оператор повинен змінити конфігурацію, щоб вимагати явної підтверджувальної згоди до встановлення неосновних файлів cookie, повинен за замовчуванням встановити перемикачі для кожної категорії у положення off, і повинен переконатися, що варіант відмови принаймні так само помітний, як варіант прийняття в UI банера. Ці три налаштування — явна згода, вимкнено за замовчуванням, помітна відмова — є мінімумом, який потрібен сайту Wix для проходження порогу, встановленого EDPB у настановах щодо банерів файлів cookie 2023 року та підтвердженого в пріоритетах робочої групи 2026 року.
Як Wix управляє згодою під капотом
Wix розкриває стан згоди відвідувача через об'єкт політики згоди, який читають внутрішні інтеграції платформи і який може читати код оператора через платформу для розробників Velo. Velo API розкриває політику згоди в розділі wixWindow.consentPolicy на фронтенді та еквівалентний модуль на бекенді. Політика згоди повертає структурований об'єкт з булевими прапорами для кожної категорії та мітку часу; код Velo оператора або Custom Code зчитує ці прапори перед ініціалізацією будь-якої неосновної логіки третьої сторони.
Категорії згоди, які Wix розкриває, відповідають стандартній таксономії. Essential охоплює файли cookie сеансу, кошика, безпеки та балансування навантаження і не вимагає згоди. Functional охоплює налаштування, списки нещодавно переглянутих елементів та подібне неосновне, але не відстежувальне сховище. Analytics охоплює Wix Analytics, Google Analytics 4, Microsoft Clarity та подібні інструменти вимірювання. Advertising охоплює Facebook Pixel, Google Ads, TikTok Pixel, LinkedIn Insight та ширший інвентар маркетингових пікселів. Рідні Wix Marketing Apps автоматично блокують за цими категоріями; все, що додав оператор, потребує ручного блокування.
Шаблон інтеграції для вбудованих елементів третіх сторін та Custom Code
Шаблон, який працює в Wix, має чотири частини. По-перше, налаштуйте вбудований Cookie Consent Banner для вимоги явної згоди, встановіть перемикачі для кожної категорії у вимкнене положення за замовчуванням та переконайтеся, що варіант відмови є принаймні так само помітним, як і прийняття. По-друге, визначте кожен сторонній скрипт, який сайт додає поза нативним списком інтеграцій Wix — зазвичай вони містяться в Settings, Custom Code, у модулях коду Velo або у вбудованих HTML-віджетах — та складіть перелік з вказанням, до якої категорії згоди кожен з них належить. По-третє, загорніть кожен сторонній скрипт у перевірку згоди, яка зчитує політику згоди перед виконанням. По-четверте, переконайтеся, що повідомлення про конфіденційність, показане в банері, відображає фактичних одержувачів третіх сторін, а не загальну шаблонну мову Wix.
- Custom Code у розділі Settings — оператори зазвичай додають Google Tag Manager, додаткові Facebook Pixel, додаткові теги конверсії Google Ads, фрагменти Hotjar та скрипти відстеження дзвінків через Custom Code. Кожен з них повинен бути налаштований з відповідним параметром Consent Mode в UI Custom Code — Wix розкриває вибір категорії згоди на рівні фрагмента — щоб фрагмент завантажувався лише за умови надання відповідної категорії.
- Код Velo — код Velo бекенду та фронтенду може зчитувати wixWindow.consentPolicy і умовно звертатися до сторонніх API. Будь-який модуль Velo, який викликає сторонній ендпоінт для реєстрації подій, запуску пікселів або синхронізації даних із CRM, повинен перевіряти відповідну категорію перед виконанням.
- Вбудовані HTML-віджети — вбудовані HTML iFrame від третіх сторін (чат-віджети, віджети календаря, соціальні вбудовування) зазвичай завантажують власні скрипти, які встановлюють власні файли cookie. Шаблон полягає у відображенні iFrame у Velo-контрольованому обгортанні, яке умовно вставляє елемент iFrame лише після надання відповідного дозволу.
- Сайти Wix Studio — Wix Studio успадковує той самий механізм політики згоди, але додає адаптивний дизайн та функції режиму розробника, які полегшують підтримку блокування згоди у стилі Velo. Шаблон інтеграції є ідентичним; ергономіка обслуговування краща.
Типові пастки відповідності для Wix
Три шаблони повторюються на розгортаннях Wix і складають більшість проблем, позначених регуляторами. Перша — контейнер Google Tag Manager під управлінням оператора — оператор встановлює GTM через Custom Code, а потім додає десятки тегів через UI GTM без налаштування Consent Mode v2 всередині самого GTM. Банер Wix правильно блокує завантажувач GTM, але після завантаження GTM теги всередині спрацьовують без додаткових перевірок згоди, якщо GTM не налаштовано для підтримки Consent Mode. Виправлення полягає у вмиканні Consent Mode v2 у контейнері GTM та прив'язці тригера кожного тегу до відповідного сигналу згоди.
Друга — вбудований постачальник форм — Typeform, JotForm, Calendly та подібні — який завантажує власні файли cookie для аналітики та попереднього заповнення. Банер Wix за замовчуванням не блокує вбудований віджет; оператор повинен заблокувати сам елемент віджету через Velo або використовувати шаблон-заповнювач «натисни для завантаження», який відкладає завантаження iFrame до взаємодії користувача з ним.
Третя — розкриття інформації про транскордонну передачу. Хостингова інфраструктура Wix працює в різних регіонах, включаючи США, і багато сторонніх одержувачів оператора працюють в інших місцях; шаблон повідомлення про конфіденційність, який постачає Wix, не називає конкретно ці юрисдикції, і оператор повинен відредагувати повідомлення, щоб назвати кожен регіон-одержувач. Настанова EDPB 2023 року чітко вказала, що загальна мова дані, оброблені постачальниками послуг, є недостатньою, і той самий стандарт застосовується до сайтів, розміщених на Wix.
Валідація та позиція аудиту на 2026 рік
Захищене розгортання Wix у 2026 році повинно пройти чотири технічні перевірки. По-перше, чистий сеанс браузера, поданий з IP-адреси EEA, повинен створити нульову кількість неосновних файлів cookie до обробки банера — не лише нульову кількість файлів cookie, керованих Wix, але й нульову кількість файлів cookie від кожного фрагмента Custom Code, модуля Velo та вбудованого віджету. По-друге, шлях відхилення повинен зберігати цей стан. По-третє, шлях прийняття повинен створювати лише теги, на які користувач надав згоду, а журнал згоди Wix разом із будь-яким журналом на стороні оператора повинен містити відповідний запис. По-четверте, відкликання повинно негайно зупинити подальше спрацьовування тегів, закінчити строк дії файлів cookie, встановлених під час сеансу зі згодою, та поширити відмову на всіх нижчих сторонніх одержувачів, що підтримують власний стан.
Очікування журналу аудиту — це місце, де Wix покращується, але все ще вимагає зусиль з боку оператора. Платформа фіксує рішення щодо згоди у власному журналі, доступному власнику сайту, якого достатньо для багатьох запитів регуляторів. Для розгортань, що потребують більш повного журналу аудиту — версії банера, стану категорії, мовної версії та стану нижчих одержувачів — оператор повинен додати код Velo, який записує події згоди у зовнішнє сховище, доступне для запиту. Сайт Wix, який правильно налаштував вбудований банер, заблокував кожен шлях Custom Code та Velo, відредагував повідомлення про конфіденційність із зазначенням кожного транскордонного одержувача та додав журнал аудиту, є сайтом Wix, який перетворив простоту розміщеного конструктора платформи з зобов'язання щодо відповідності на захищену частину позиції щодо згоди видавця.