Що робить нативний банер файлів cookie Squarespace і де він зупиняється

Нативний Cookie Banner Squarespace — доступний у Settings, Cookies & Visitor Data — підтримує конфігурований UI банера, відкриває вибір стилю згоди оператора та інтегрується з власною аналітикою та маркетинговими поверхнями Squarespace. Коли оператор вмикає банер і налаштовує параметри даних відвідувачів, внутрішні інтеграції Squarespace поважають вибір відвідувача без додаткових налаштувань: Squarespace Analytics обмежується аналітичним сигналом, пікселі ретаргетингу Pinterest, Facebook та Google Ads поважають маркетинговий сигнал, а збір поведінкових даних платформи пригнічується для відвідувачів, які відмовляються.

Що банер не робить, і де трапляється найпоширеніша помилка відповідності на Squarespace, — це блокування сторонніх скриптів, що додаються оператором через Code Injection. Панель Code Injection — у Settings, Advanced — дозволяє оператору вставляти довільний HTML та JavaScript у заголовок сторінки, нижній колонтитул або місця на кожній сторінці. Скрипти, впроваджені таким чином, запускаються до того, як відвідувач побачить банер, тобто будь-який сторонній тег, вставлений у Code Injection, спрацьовує незалежно від згоди. Hotjar, власні контейнери Google Tag Manager, додаткові Facebook Pixels, віджети чату, відеопровайдери — все, що не включено до списку нативних інтеграцій Squarespace, не буде заблоковано нативним банером, якщо оператор не загорне скрипт у перевірку згоди.

Стиль згоди за замовчуванням: opt-in проти неявного

Банер Squarespace підтримує обидва стилі згоди — opt-in та неявний, і неявний варіант залишається доступним, хоча він був джерелом повторних висновків регуляторів щодо сайтів, розміщених Squarespace, по всій EEA. Оператор повинен вибрати варіант opt-in, перевірити, що збір даних відвідувачів за замовчуванням вимкнено до прийняття відвідувачем, і забезпечити, щоб можливість відмови була принаймні так само помітна, як можливість прийняття в UI банера. Ці три налаштування — явна згода, вимкнено за замовчуванням, помітна відмова — є мінімумом, необхідним сайту Squarespace для подолання порогу, встановленого EDPB у рекомендаціях щодо банерів файлів cookie 2023 року.

Поверхня Code Injection та як її заблокувати

Шаблон інтеграції, що працює на Squarespace, має три частини. По-перше, правильно налаштуйте нативний банер. По-друге, ідентифікуйте кожен скрипт у Code Injection та оцініть, до якої категорії згоди він належить. По-третє, загорніть кожен скрипт Code Injection у перевірку згоди перед його виконанням — або зчитуючи відкритий стан згоди Squarespace під час виконання, або умовно вставляючи елемент скрипту лише після того, як банер поверне позитивний сигнал для відповідної категорії.

Найчистіший шаблон для скриптів, впроваджених у заголовок, — перетворити їх на форму-заповнювач: змініть атрибут type з text/javascript на text/plain, додайте атрибут data-category, що ідентифікує шлюз згоди, та включіть невеликий скрипт bootstrap, який прослуховує подію зміни згоди Squarespace і перезаписує атрибут type, коли категорія надається. Шаблон bootstrap — той самий, що використовують Webflow, Drupal та Cloudflare Zaraz; внесок Squarespace — об'єкт стану згоди, який читає bootstrap.

Поверхня сторонніх віджетів, яку оператори Squarespace регулярно пропускають

Оператори Squarespace значною мірою покладаються на вбудовані блоки для багатого контенту, що формує більшу частину привабливості платформи. Кожен з цих блоків вводить окрему поверхню згоди, яку нативний банер автоматично не блокує.

• Відеоблоки — Фонові відео YouTube та Vimeo завантажують сторонні скрипти провайдера при кожному рендерингу сторінки. Режим вбудовування YouTube з покращеною конфіденційністю та режим do-not-track Vimeo є варіантами, але безпечніший шаблон — загорнути відеоблок у заповнювач клік-для-завантаження, який отримує iframe провайдера лише коли відвідувач явно активує його.
• Соціальні блоки — Блоки Instagram, Twitter, TikTok та Pinterest кожен отримує скрипт вбудовування провайдера та встановлює куки на стороні провайдера. Шаблон той самий: замініть живий блок статичним попереднім переглядом, що завантажує вбудовування лише при взаємодії користувача, за шлюзом маркетингової згоди.
• Форми підписки на розсилку — Вбудована форма Squarespace враховує згоду, але вбудовування форм сторонніх розробників Mailchimp, Klaviyo, ConvertKit та подібних — ні, а вбудований провайдер форм зазвичай завантажує власну аналітику при рендерингу форми. Кожне має бути загорнуте у перевірку згоди.
• Віджети чату — Вбудовування чату Drift, Intercom, Tidio та подібних встановлює власні куки сесії та ідентичності і завантажує власний JavaScript. Вони належать принаймні за шлюзом функціональної згоди, а за маркетинговим шлюзом, якщо платформа чату інтегрується з CRM, що поширює дані відвідувачів.

Squarespace Commerce та поверхня кошика

Squarespace Commerce вводить суворо необхідні куки для стану кошика, ідентифікації сесії та оплати, які не потребують згоди, оскільки є необхідними для послуги, що запитується відвідувачем. Ускладнення виникають навколо маркетингових поверхонь, що вводяться Commerce: електронні листи про покинутий кошик, рушії рекомендацій товарів, інтеграція Facebook Conversions API, ретаргетинг Google Ads та інтеграція Klaviyo або Mailchimp, яку активує більшість магазинів. Вони не є необхідними і мають бути заблоковані. Нативний банер Squarespace обробляє власні інтеграції Conversions платформи; Klaviyo та Mailchimp та будь-яке власне налаштування Conversions потребують блокування на стороні оператора.

Валідація та позиція аудиту для 2026 року

Захищуване розгортання Squarespace у 2026 році має пройти чотири технічні перевірки. По-перше, чиста сесія браузера, що обслуговується з IP-адреси EEA, має створити нуль необов'язкових файлів cookie до того, як банер буде задіяно — охоплюючи куки, керовані Squarespace, скрипти Code Injection, вбудовані відео- та соціальні блоки та будь-які віджети розсилки або чату на сторінці. По-друге, шлях відмови має зберегти цей стан. По-третє, шлях прийняття має створити лише теги, на які відвідувач дав згоду, а куки та стан згоди Squarespace повинні містити відповідний запис. По-четверте, відкликання має негайно припинити подальше спрацьовування тегів, завершити строк дії файлів cookie, встановлених під час сеансу зі згодою, та поширити відмову на сторонніх одержувачів нижче за течією. Питання аудиторського сліду — це місце, де нативний банер Squarespace наразі демонструє свої обмеження. Банер записує стан згоди відвідувача у файл cookie першої сторони, який читають власні інтеграції Squarespace, але платформа не веде серверний журнал аудиту, доступний для запиту за ідентифікатором відвідувача або ідентифікатором сесії, як це робить сторонній CMP. Для розгортань, що діють переважно в юрисдикціях з легшими вимогами до аудиторського сліду, нативного банера достатньо при правильному налаштуванні. Для розгортань, яким потрібен журнал згоди з можливістю запиту — звітування в кількох юрисдикціях, записи згоди на постачальника, інтеграція з очікуваним стандартом документації EDPB — правильною відповіддю є сторонній CMP, накладений на нативний банер, з вимкненим нативним банером та встановленими Cookiebot, OneTrust, Usercentrics або Iubenda через Code Injection. Сайт Squarespace, який свідомо обрав між двома шляхами, заблокував кожну поверхню Code Injection, вирішив шаблон вбудованих віджетів та врахував специфічні для Commerce маркетингові інтеграції, — це сайт Squarespace, який перетворив зручну для дизайнерів простоту платформи на захищувану частину позиції згоди оператора, а не на приховану заборгованість з дотримання вимог.