← Усі статті На головну
Реклама

Що таке Cookiebot ? Як встановити та налаштувати Cookiebot ?

Опубліковано: 07.03.2026 Оновлено: 07.03.2026 Перегляди: 399
Що таке Cookiebot ? Як встановити та налаштувати Cookiebot ?

Що таке Cookiebot і навіщо він потрібен у 2024-2026 роках

Вступ. Чому тема Cookiebot зараз критично важлива

Починаючи з 2023-2024 років питання cookies, персональних даних і згоди користувачів перестало бути "рекомендованим" і стало обов’язковим для більшості сайтів.
Це пов’язано одразу з кількома факторами:

  • посиленням GDPR та ePrivacy Directive в ЄС;

  • набранням чинності Digital Markets Act (DMA);

  • новими вимогами Google до реклами та аналітики;

  • обов’язковим використанням Google Consent Mode v2.

У результаті сайт без коректної системи керування згодою:

  • може порушувати законодавство;

  • може втратити аналітичні дані;

  • може отримати блокування рекламних акаунтів;

  • може показувати попередження в Google Analytics та Google Ads.

Саме тут і з’являється Cookiebot.

Що таке Cookiebot простими словами

Cookiebot - це Consent Management Platform (CMP), тобто система керування згодою користувачів на використання cookies та інших технологій зберігання даних.

Простими словами, Cookiebot:

  • показує банер cookies користувачу;

  • дозволяє йому прийняти, відхилити або налаштувати cookies;

  • зберігає це рішення;

  • передає інформацію про згоду в:

    • Google Tag Manager

    • Google Analytics

    • Google Ads

    • інші сторонні сервіси;

  • блокує non-necessary cookies до згоди.

Які задачі вирішує Cookiebot

Cookiebot не просто "банер". Це ціла система, яка закриває одразу кілька критичних задач.

1. Юридична відповідність (compliance)

Cookiebot допомагає сайту відповідати вимогам:

  • GDPR

  • ePrivacy Directive

  • DMA

  • CCPA (для США, якщо налаштовано відповідні регіони)

Без CMP сайт формально порушує закон, якщо:

  • використовує Google Analytics;

  • використовує рекламу;

  • має Facebook Pixel, YouTube, Maps, Chat, iframe, трекери тощо.

2. Контроль cookies до згоди

Ключовий принцип GDPR:

Non-necessary cookies не можуть встановлюватися до згоди користувача.

Cookiebot:

  • автоматично блокує сторонні скрипти;

  • або керує запуском тегів через Google Tag Manager;

  • або комбінує обидва підходи.


3. Інтеграція з Google Consent Mode v2

Cookiebot є Google-certified CMP і повністю підтримує Consent Mode v2, включаючи нові параметри:

  • ad_user_data

  • ad_personalization

Це критично, бо з 2024 року Google:

  • показує попередження "Consent mode installation out of order";

  • може обмежувати передачу рекламних даних;

  • може знижувати ефективність реклами.

Cookiebot автоматично передає сигнали згоди у Google, якщо все налаштовано правильно.


4. Збереження аналітики навіть без згоди (Advanced mode)

Важливий момент.

З Consent Mode:

  • Google Analytics та Google Ads можуть працювати у cookieless-режимі;

  • передаються агреговані сигнали без персональних cookies;

  • аналітика не "обривається повністю".

Це дозволяє:

  • дотримуватись закону;

  • не втрачати повністю дані;

  • будувати коректні звіти.


Cookiebot і Google Consent Mode - як вони пов’язані

Cookiebot не замінює Google Consent Mode.
Вони працюють разом.

Розподіл ролей такий:

  • Cookiebot:

    • отримує вибір користувача;

    • зберігає його;

    • показує банер;

  • Google Consent Mode:

    • керує поведінкою Google-тегів;

    • визначає, що дозволено до і після згоди.

Cookiebot передає сигнали у Consent Mode автоматично, якщо:

  • увімкнено Consent Mode в адмінці Cookiebot;

  • використовується GTM або inline-скрипт;

  • налаштовані default consent states.


Які cookies вважаються necessary, а які ні

Cookiebot працює з категоріями cookies. Це важливо розуміти ще до налаштування.

Necessary (обов’язкові)

  • безпека

  • авторизація

  • кошик

  • захист від шахрайства

Ці cookies:

  • завжди дозволені;

  • не вимагають згоди;

  • але повинні бути описані у Cookie Declaration.


Preferences (функціональні)

  • мова сайту;

  • тема (light/dark);

  • регіон;

  • збережені налаштування.

Потребують згоди.


Statistics (аналітика)

  • Google Analytics

  • внутрішні трекери

  • лічильники відвідувань

Потребують згоди.


Marketing (реклама)

  • Google Ads

  • Facebook Pixel

  • ремаркетинг

  • персоналізована реклама

Потребують згоди і мають найжорсткіші вимоги.


Чому Cookiebot, а не просто "банер"

Проста кнопка "Приймаю cookies" НЕ є юридично коректною.

Cookiebot:

  • зберігає consent log;

  • фіксує дату і регіон;

  • дозволяє granular choice;

  • підтримує регіональні правила;

  • інтегрується з GTM, Google, TCF 2.2.

Тому Cookiebot - це інфраструктурне рішення, а не декоративний елемент.


ЧАСТИНА 2. Способи встановлення Cookiebot - який вибрати і чим вони відрізняються

У Cookiebot є кілька правильних способів інтеграції. Вибір залежить не від "як простіше", а від того:

  • чи використовуєш Google Tag Manager;

  • чи хочеш автоматичне блокування скриптів у коді сайту;

  • чи всі трекери керуються через GTM, чи частина вставлена напряму в шаблон;

  • чи потрібна мультимовність і складні правила (регіони, різні банери, різні дефолти).

Офіційно Cookiebot описує ручне (inline) впровадження як базовий шлях: додати домен, налаштувати банер, вставити скрипт у сайт, дочекатися скану.

Нижче - 3 основні варіанти.


Варіант A. Встановлення Cookiebot напряму в код сайту (inline, Manual implementation)

Цей варіант найпростіший технічно і найнадійніший для автоматичного блокування.

Коли обирати inline

Обирай inline якщо:

  • у тебе сайт без GTM або GTM мінімальний;

  • багато сторонніх скриптів вставлено прямо в шаблон (iframe, віджети, чати, карти, пікселі);

  • ти хочеш, щоб Cookiebot сам блокував усе non-necessary до згоди.

Cookiebot прямо підкреслює важливість вставки скрипта як першого в head, щоб нічого не "проскочило" до consent.

Як ставити

Класичний код Cookiebot банера виглядає так (потрібно підставити свій data-cbid):

<script id="Cookiebot" src="https://consent.cookiebot.com/uc.js" data-cbid="ВАШ_DOMAIN_GROUP_ID" data-blockingmode="auto" type="text/javascript"></script>
  • data-blockingmode="auto" - вмикає Automatic cookie blocking (автоблокування)

  • скрипт має бути першим у <head> (до GA/GTM/Ads/пікселів)

Плюси inline

  • максимально надійне prior-consent блокування;

  • простіше дебажити;

  • не залежить від GTM.

Мінуси inline

  • якщо всі теги живуть у GTM, керувати ними може бути зручніше через GTM;

  • для складних схем з десятками тегів частіше обирають GTM-варіант.


Варіант B. Встановлення Cookiebot через Google Tag Manager (GTM Template)

Це популярний варіант для маркетингових сайтів, де:

  • всі трекери/пікселі/теги ставляться через GTM;

  • потрібно централізовано керувати запуском тегів через Consent Mode.

Cookiebot має офіційний гайд по GTM deployment і чітко вказує тригер: Consent Initialization - All Pages.

Коли обирати GTM-варіант

  • GTM є головним центром керування тегами;

  • мінімум сторонніх скриптів вставлено напряму в шаблон;

  • хочеш керувати згодою через Consent Mode + налаштування тегів в GTM.

Ключова логіка

У цьому варіанті Cookiebot банер додається як тег у GTM.
А далі ти налаштовуєш, які теги можуть працювати:

  • або в Advanced Consent Mode (Google теги можуть завантажуватись, але працювати по consent),

  • або в Basic Consent Mode (теги взагалі не запускаються до згоди).

Про те, що Cookiebot інтегрується з Google consent mode і автоматично надсилає сигнали в Google після consent, Cookiebot пише прямо в документації. Але default state все одно треба забезпечити коректно.

Правильний тригер для Cookiebot CMP у GTM

У GTM потрібно поставити Cookiebot CMP tag на:

  • Consent Initialization - All Pages

Це робиться, щоб consent-стани з’явились максимально рано, до того як GTM почне оцінювати інші теги.

Важлива правда про автоблокування

Коли Cookiebot завантажується як GTM tag, автоблокування контенту в HTML-шаблоні не буде надійним, бо GTM підвантажує все асинхронно. Сам Cookiebot теж підводить до того, що авто-блокінг краще робити напряму через script у head, а GTM використовувати для керування тегами. 


Варіант C. Комбінований: GTM + auto blocking (best of both worlds)

Це найкращий варіант для більшості сучасних сайтів, якщо:

  • ти хочеш керувати тегами через GTM;

  • але при цьому маєш сторонні скрипти/iframe/img, вставлені напряму в шаблон;

  • і хочеш, щоб вони не завантажувались до згоди.

Суть схеми:

  1. Google Consent Mode default script - першим

  2. GTM snippet - другим

  3. Cookiebot script з data-blockingmode="auto" - третім

Чому порядок скриптів критичний

Google прямо каже: consent mode потрібно налаштувати коректно, включаючи оновлення до v2 з новими параметрами.
Cookiebot окремо має статтю про помилку "Consent mode installation out of order" і пояснює, що default consent має бути до Google скриптів, і що у v2 обов’язково мають бути ad_user_data та ad_personalization.


Суперважливо: Consent Mode v2 - що міняється для Cookiebot

Google Consent Mode v2 додав 2 нові параметри:

  • ad_user_data

  • ad_personalization

Google офіційно пише, що consent mode оновлено (листопад 2023) і треба перейти на v2.
Cookiebot окремо пояснює, що саме ці два параметри є ключовими змінами v2.
Google Analytics також прямо очікує ці параметри для ads measurement / ads personalization consent.


ЧАСТИНА 3. Google Consent Mode v2 і default consent state - основа всієї логіки Cookiebot

Цю частину варто читати дуже уважно.
Саме тут виникає 90% помилок, через які:

  • Google Analytics показує попередження;

  • Google Ads не передає конверсії;

  • Consent Mode працює некоректно;

  • з’являється помилка Consent mode installation out of order.


Що таке Google Consent Mode простими словами

Google Consent Mode - це механізм, який дозволяє Google-тегам адаптувати свою поведінку залежно від того, дав користувач згоду чи ні.

Важливо зрозуміти головне:

  • Consent Mode не питає згоду;

  • Consent Mode не показує банер;

  • Consent Mode не зберігає рішення користувача.

Це робить Cookiebot.

Consent Mode лише отримує сигнали:

  • що дозволено;

  • що заборонено;

  • і відповідно поводить Google-теги.


Чому з’явився Consent Mode v2 і чим він відрізняється

Раніше (v1) Consent Mode мав базові параметри:

  • ad_storage

  • analytics_storage

З кінця 2023 року Google запровадив Consent Mode v2, додавши ще два обов’язкові параметри:

  • ad_user_data

  • ad_personalization

Навіщо вони потрібні

Ці параметри визначають:

  • чи можна використовувати дані користувача для реклами;

  • чи дозволена персоналізація оголошень;

  • чи можна передавати сигнали ремаркетингу.

Без них:

  • реклама працює некоректно;

  • Google може вважати інтеграцію неповною;

  • з’являються попередження в аналітиці.


Що таке default consent state і чому він критично важливий

Default consent state - це стан згоди ДО того, як користувач щось натиснув у банері.

Саме тут ключова юридична логіка:

Поки користувач не дав згоду, система повинна вважати, що згоди немає.

Тобто:

  • non-necessary cookies - заборонені;

  • реклама - заборонена;

  • аналітика - заборонена;

  • персоналізація - заборонена.

Якщо default state не заданий:

  • Google теги можуть стартувати без обмежень;

  • це вважається порушенням;

  • Google показує помилки.


Строгий (правильний) default consent state

Для GDPR-сумісного сайту default state виглядає так:

  • ad_storage - denied

  • ad_user_data - denied

  • ad_personalization - denied

  • analytics_storage - denied

  • functionality_storage - denied

  • personalization_storage - denied

  • security_storage - granted

Чому security_storage завжди granted

Тому що:

  • безпека;

  • авторизація;

  • захист від шахрайства;

  • ці cookies є necessary.

Вони не потребують згоди, але мають бути описані у Cookie Declaration.


Inline default consent script - базовий шаблон

Якщо Cookiebot встановлений напряму в коді сайту, default consent задається через inline-скрипт до Google тегів.

Базовий приклад:

<script data-cookieconsent="ignore"> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('consent','default',{ ad_storage:'denied', ad_user_data:'denied', ad_personalization:'denied', analytics_storage:'denied', functionality_storage:'denied', personalization_storage:'denied', security_storage:'granted', wait_for_update:500 }); gtag('set','ads_data_redaction',true); gtag('set','url_passthrough',false); </script>

Важливі моменти

  • цей скрипт має бути раніше за GTM або gtag;

  • data-cookieconsent="ignore" не дає Cookiebot заблокувати його;

  • wait_for_update дає час Cookiebot передати оновлення згоди.


Default consent при встановленні Cookiebot через GTM

Якщо Cookiebot встановлений через GTM, inline-скрипт зазвичай не потрібен, бо:

  • Cookiebot CMP tag сам реєструє default consent states;

  • Consent Mode активується автоматично.

Але важливо:

  • тег Cookiebot має стояти на Consent Initialization - All Pages;

  • у налаштуваннях CMP повинні бути задані всі параметри v2.


Регіональні default consent rules

Consent Mode дозволяє задавати різні default значення для різних регіонів.

Приклад логіки:

  • ЄС - все denied до згоди;

  • США (не Каліфорнія) - можна дозволити за замовчуванням;

  • Каліфорнія (CCPA) - інша схема.

Приклад регіональної логіки

  • EU - denied

  • US - granted

  • US-CA - denied

Більш специфічний регіон завжди має пріоритет.


Чому виникає помилка "Consent mode installation out of order"

Це одна з найпоширеніших проблем.

Вона з’являється, якщо:

  1. default consent script завантажився після GTM або gtag

  2. не задані ad_user_data або ad_personalization

  3. Cookiebot CMP tag завантажується занадто пізно

  4. використовується застаріла версія Consent Mode

Як мислить Google

Google очікує:

  • спочатку default state;

  • потім Google теги;

  • потім update від Cookiebot після вибору користувача.

Якщо порядок порушений - система не може гарантувати compliance.


Що відбувається після того, як користувач зробив вибір

Після натискання кнопки в банері Cookiebot:

  1. зберігає рішення;

  2. передає consent update;

  3. Consent Mode оновлює значення:

    • denied → granted (для дозволених категорій);

  4. Google теги:

    • або починають працювати повноцінно;

    • або залишаються заблокованими.

Цей момент супроводжується подією cookie_consent_update, яка критично важлива для GTM.



ЧАСТИНА 4. Advanced Consent Mode vs Basic Consent Mode - як реально працюють теги після згоди

У цій частині ми розберемо реальну поведінку тегів, а не маркетингові описи.
Після цього розділу стане зрозуміло:

  • чому аналітика "зникає";

  • чому реклама працює дивно;

  • чому теги не запускаються після згоди;

  • і як цього уникнути.


Два режими роботи Consent Mode

Google Consent Mode має два принципово різні підходи до роботи тегів:

  1. Advanced Consent Mode

  2. Basic Consent Mode

Вони не конфліктують, але працюють по-різному.


Advanced Consent Mode - що це насправді

Коротко

Advanced Consent Mode означає:

Google-теги можуть завантажуватися до згоди, але працюють в обмеженому режимі.

Тобто:

  • cookies не ставляться;

  • персональні дані не зберігаються;

  • але теги існують і відправляють сигнали.


Як це виглядає на практиці

До згоди користувача:

  • Google Analytics:

    • не створює _ga cookie;

    • відправляє анонімні пінги;

    • фіксує події без ідентифікації;

  • Google Ads:

    • не персоналізує рекламу;

    • але може використовувати агреговані сигнали;

  • Conversion Linker:

    • працює в обмеженому режимі.

Після згоди:

  • cookies дозволяються;

  • персоналізація вмикається;

  • аналітика стає повноцінною.


Плюси Advanced Consent Mode

  • не втрачається вся аналітика;

  • Google може моделювати конверсії;

  • реклама працює стабільніше;

  • немає "провалу" першої сторінки.


Мінуси Advanced Consent Mode

  • теги все одно завантажуються до згоди;

  • для деяких юрисдикцій це може бути небажано;

  • складніше пояснити юристам;

  • не всі сторонні теги підтримують такий режим.


Basic Consent Mode - жорстка логіка

Коротко

Basic Consent Mode означає:

Тег взагалі не запускається, доки немає згоди.

Нема згоди - нема тегу.
Крапка.


Як це виглядає

До згоди:

  • тег не завантажений;

  • код не виконується;

  • жодних запитів;

  • жодних cookies.

Після згоди:

  • тег запускається;

  • cookies ставляться;

  • аналітика починається з цього моменту.


Плюси Basic Consent Mode

  • максимальна відповідність GDPR;

  • ідеально для суворих вимог;

  • легко пояснити юристам;

  • повний контроль.


Мінуси Basic Consent Mode

  • втрачається перша сторінка;

  • немає даних до кліку по банеру;

  • якщо тригер налаштований неправильно - тег може не запуститись взагалі.


Найбільша пастка: "All Pages"

Це класична помилка, яка ламає Basic Consent Mode.

Що відбувається

  1. Користувач заходить на сайт

  2. GTM одразу оцінює тригери

  3. "All Pages" відпрацьовує

  4. Згоди ще немає

  5. Тег не запускається

  6. Користувач дає згоду

  7. Але тег не переоцінюється

Результат:

  • тег не запускається взагалі;

  • аналітики немає;

  • виглядає як "не працює".


Подія cookie_consent_update - ключ до Basic Consent Mode

Cookiebot після вибору користувача відправляє подію:

cookie_consent_update

Саме вона сигналізує GTM:

"Згода є, можна запускати теги"


Правильна схема для Basic Consent Mode

  1. Тег НЕ має тригер "All Pages"

  2. Тег має тригер:

    • Custom Event

    • Event name: cookie_consent_update

  3. У тегу увімкнено Additional Consent Checks

  4. Вказані потрібні storage типи

Тільки так тег:

  • не стартує до згоди;

  • стартує одразу після згоди;

  • не вимагає перезавантаження сторінки.


Additional Consent Checks - що це і навіщо

Additional Consent Checks - це спосіб сказати GTM:

"Цей тег може запускатись тільки якщо є конкретна згода"

Наприклад:

  • ad_storage - для реклами;

  • analytics_storage - для аналітики;

  • functionality_storage - для функціоналу.

Типова конфігурація

  • Facebook Pixel:

    • ad_storage

  • Google Analytics:

    • analytics_storage

  • Chat widget:

    • functionality_storage


Чи можна змішувати Advanced і Basic

Так.
І це нормальна практика.

Типова реальна схема

  • Google Analytics - Advanced

  • Google Ads - Advanced

  • Facebook Pixel - Basic

  • Chat / Maps / YouTube - Basic

Таким чином:

  • Google зберігає аналітику;

  • сторонні сервіси не завантажуються без згоди;

  • сайт залишається compliant.


Чому часто здається, що Consent Mode "не працює"

Основні причини:

  • неправильний default consent state;

  • відсутні параметри v2;

  • використовується All Pages замість cookie_consent_update;

  • тег має Additional Consent Checks, але неправильний тригер;

  • Cookiebot завантажується занадто пізно.

У 90% випадків проблема не в Cookiebot, а в логіці GTM.


ЧАСТИНА 5. Налаштування тегів у Google Tag Manager з Cookiebot - як зробити правильно і не зламати аналітику

У цій частині ми зведемо все докупи і розберемо реальні сценарії налаштування тегів.
Саме тут зазвичай виникають питання типу:

  • чому GA4 не стріляє;

  • чому Ads не бачить конверсії;

  • чому теги не запускаються після згоди;

  • чому Consent Mode ніби є, але не працює.


Загальна логіка перед налаштуванням тегів

Перед тим як лізти у конкретні теги, важливо зафіксувати базову архітектуру:

  1. Cookiebot встановлений і показує банер

  2. Consent Mode v2 увімкнений

  3. Default consent state заданий

  4. Cookiebot передає consent update

  5. GTM отримує подію cookie_consent_update

Якщо будь-який пункт не виконаний - налаштування тегів не має сенсу.


Google Analytics 4 - правильні сценарії

Варіант 1. GA4 в Advanced Consent Mode (рекомендовано)

Це найпопулярніший і найзбалансованіший варіант.

Як працює

  • GA4 тег завантажується одразу;

  • до згоди - без cookies;

  • після згоди - повноцінно.

Налаштування

  • НЕ вмикати Additional Consent Checks;

  • тригер - All Pages;

  • analytics_storage керується Consent Mode автоматично.

Що отримуєш

  • немає провалу першої сторінки;

  • коректна аналітика;

  • мінімум ризиків.


Варіант 2. GA4 в Basic Consent Mode (строго)

Цей варіант має сенс, якщо потрібен максимально строгий підхід.

Налаштування

  • Увімкнути Additional Consent Checks;

  • Обрати analytics_storage;

  • Тригер:

    • Custom Event

    • cookie_consent_update

Наслідки

  • перша сторінка втрачається;

  • GA стартує тільки після кліку по банеру;

  • все юридично чисто, але менш інформативно.


Google Ads і Conversion Linker

Conversion Linker - завжди Advanced

Conversion Linker:

  • має бути на All Pages;

  • не має Additional Consent Checks;

  • працює разом з Consent Mode.

Причина проста:

  • він потрібен для коректної атрибуції;

  • Google очікує його присутність.


Google Ads Conversion Tag

Рекомендована схема

  • Advanced Consent Mode;

  • без Additional Consent Checks;

  • Consent Mode сам обмежує поведінку.

Що важливо

  • ad_storage

  • ad_user_data

  • ad_personalization

Ці параметри мають існувати, інакше реклама працює некоректно.


Сторонні пікселі (Facebook, TikTok, LinkedIn)

Тут майже завжди Basic Consent Mode.

Чому

  • ці теги не мають повноцінної cookieless-логіки;

  • часто одразу ставлять cookies;

  • можуть порушувати GDPR.

Як налаштовувати

  • Увімкнути Additional Consent Checks;

  • Обрати ad_storage;

  • Тригер:

    • cookie_consent_update

Результат:

  • тег не завантажується до згоди;

  • стартує одразу після кліку.


Чати, карти, iframe, відео

Рекомендований підхід

  • Basic Consent Mode;

  • functionality_storage або personalization_storage;

  • запуск тільки після consent.

Типові приклади

  • Google Maps

  • YouTube embed

  • онлайн-чати

  • сторонні віджети


Масове налаштування тегів через Consent Overview

Якщо тегів багато, GTM дозволяє:

  • відкрити Consent Overview;

  • обрати кілька тегів;

  • задати Additional Consent Checks одразу для всіх.

Це значно зменшує час налаштування і кількість помилок.


Найчастіші помилки при налаштуванні тегів

Помилка 1. Additional Consent Checks + All Pages

Результат:

  • тег ніколи не запускається.

Помилка 2. Basic Consent без cookie_consent_update

Результат:

  • тег запускається тільки після перезавантаження.

Помилка 3. Зайвий Basic для Google тегів

Результат:

  • втрата аналітики;

  • проблеми з Ads.

Помилка 4. Відсутні параметри v2

Результат:

  • попередження;

  • обмеження реклами.


Швидкий чеклист для кожного тегу

Перед публікацією перевір:

  • Який тип тегу?

  • Advanced чи Basic?

  • Чи потрібні Additional Consent Checks?

  • Який тригер?

  • Який storage тип?

Якщо на всі питання є чітка відповідь - тег налаштований правильно.


ЧАСТИНА 6. Як перевірити, що Cookiebot і Consent Mode працюють правильно

Можна ідеально все налаштувати - і все одно помилитися.
Тому перевірка обов’язкова частина впровадження.

У цій частині розберемо:

  • як перевіряти consent у GTM;

  • як читати consent-стани;

  • як зрозуміти, що теги реально поводяться правильно;

  • як швидко знайти проблему.


1. Перевірка через Google Tag Manager Preview

Це перший і головний інструмент.

Як перевіряти

  1. Увімкни Preview у GTM

  2. Відкрий сайт у новій вкладці

  3. Перейди у вкладку Consent

Що має бути видно ДО згоди

  • On-page Defaults присутні

  • У списку є:

    • ad_storage

    • analytics_storage

    • ad_user_data

    • ad_personalization

  • Значення:

    • denied (для non-necessary)

    • granted (для security_storage)

Якщо хоча б одного параметра немає - Consent Mode v2 налаштований неправильно.


2. Перевірка оновлення згоди після кліку

Тепер натисни в банері:

  • Allow all

  • або вибери категорії вручну

У GTM Preview має з’явитись:

  • подія cookie_consent_update

  • Consent Update зі значеннями granted або denied відповідно до вибору

Типова проблема

Подія є, але:

  • теги не запускаються;

  • або запускаються не ті.

Це означає:

  • неправильний тригер;

  • або неправильні Additional Consent Checks.


3. Перевірка consent-станів у браузері (console)

Навіщо це потрібно

Іноді GTM Preview не показує повну картину.
Тоді дивимось, що реально бачить Google.

Що перевіряти

У консолі браузера перевіряють:

  • чи зареєстровані default consent states;

  • чи з’явився consent update.

Результат має виглядати логічно:

  • спочатку default (denied);

  • після згоди - update (granted).

Якщо update не з’являється - Cookiebot не передає сигнал.


4. Перевірка dataLayer

Коли це актуально

  • якщо Consent Mode підключений inline;

  • або через плагін;

  • або ти хочеш глибше зрозуміти, що відбувається.

Що дивитись

У dataLayer мають бути події:

  • consent default

  • consent update

  • cookie_consent_update

Якщо dataLayer порожній або без consent-подій:

  • default consent не підключений;

  • або підключений неправильно.


5. Google Tag Assistant

Це допоміжний інструмент.

Що він показує

  • чи є CMP на сайті;

  • чи бачить Google consent-сигнали;

  • чи є попередження.

Важливо

Інформаційне повідомлення про CMP не завжди означає помилку.
Орієнтуйся на:

  • порядок завантаження;

  • поведінку тегів;

  • cookies до згоди.


6. Consent Mode Checker у Cookiebot

Cookiebot має власний автоматичний чекер, який:

  • сканує сторінку;

  • перевіряє default consent;

  • перевіряє оновлення;

  • показує ризики.

Як трактувати результат

  • "No risk" - базові вимоги виконані

  • "At risk" - є потенційні проблеми

Це sanity check, а не юридичний висновок.


7. Типові сценарії проблем і рішення

Проблема: Consent Mode installation out of order

Ознаки:

  • попередження в GA4;

  • помилки в Tag Assistant.

Причина:

  • default consent підключений після GTM;

  • або відсутні параметри v2.

Рішення:

  • перенести default script вище;

  • додати ad_user_data та ad_personalization.


Проблема: Теги не запускаються після згоди

Ознаки:

  • cookie_consent_update є;

  • теги не firing.

Причина:

  • All Pages + Additional Consent Checks.

Рішення:

  • замінити All Pages на cookie_consent_update.


Проблема: Cookies з’являються до згоди

Ознаки:

  • cookies в Application до кліку.

Причина:

  • сторонній скрипт у шаблоні;

  • відсутній auto blocking;

  • відсутній manual markup.

Рішення:

  • auto blocking;

  • або ручна розмітка.


8. Чеклист фінальної перевірки

Перед публікацією переконайся:

  • банер з’являється;

  • default consent - denied;

  • consent update працює;

  • теги поводяться правильно;

  • cookies не ставляться до згоди;

  • немає критичних попереджень


ЧАСТИНА 7. Cookie Declaration, відкликання згоди, мультимовність і UX банера

Навіть якщо Consent Mode і теги налаштовані ідеально, сайт все одно може бути некоректним, якщо:

  • користувач не може переглянути cookies;

  • не може змінити або відкликати згоду;

  • не розуміє, на що саме він погоджується;

  • банер виглядає або поводиться неправильно.


1. Cookie Declaration - обов’язкова сторінка

Що це таке

Cookie Declaration - це сторінка, де користувач бачить:

  • список cookies;

  • їхню категорію;

  • призначення;

  • термін зберігання;

  • хто їх встановлює (first-party / third-party);

  • і може змінити або відкликати згоду.

Без цієї сторінки сайт не відповідає GDPR, навіть якщо банер є.


Як вона працює

Cookiebot автоматично:

  • сканує сайт;

  • визначає cookies;

  • групує їх за категоріями;

  • оновлює декларацію.

Тобто:

  • не потрібно писати список вручну;

  • він актуалізується автоматично.


Де розміщувати

Найкраща практика:

  • окрема сторінка (наприклад, /cookie-declaration або /cookies);

  • посилання у футері;

  • посилання з банера cookies.


2. Відкликання та зміна згоди

GDPR вимагає:

Користувач має мати можливість у будь-який момент змінити або відкликати свою згоду.

Cookiebot це забезпечує двома способами:

1) Через Cookie Declaration

На сторінці є кнопка:

  • Change consent

  • Withdraw consent

Після кліку:

  • банер відкривається знову;

  • користувач може змінити вибір;

  • Cookiebot надсилає consent update.


2) Через окрему кнопку на сайті

Часто додають кнопку типу:

  • Cookie settings

  • Privacy settings

Вона відкриває банер повторно.

Це дуже хороша UX-практика.


3. Мультимовність банера Cookiebot

Чому це важливо

GDPR вимагає:

  • зрозумілої інформації;

  • мовою, яку розуміє користувач.

Якщо сайт мультимовний, банер також має бути мультимовним.


Як працює мультимовність

Cookiebot:

  • має вбудовані переклади;

  • дозволяє додавати власні тексти;

  • дозволяє вибирати мову автоматично.


Типові схеми визначення мови

  • за URL (/en/, /de/, /pl/);

  • за піддоменом (en.site.com);

  • за доменною зоною (.de, .fr);

  • за браузером (fallback).

Головне:

  • щоб мова банера відповідала мові сторінки.


4. Регіональні правила показу банера

Не всім користувачам потрібен банер

Cookiebot дозволяє:

  • показувати банер тільки в ЄС;

  • або всім користувачам;

  • або окремим країнам.

Типові сценарії

  • ЄС + ЄЕЗ - показувати банер;

  • США - показувати або ні, залежно від політики;

  • Каліфорнія - окремі правила;

  • решта світу - без банера або з auto-consent.

Це налаштовується в адмінці і напряму впливає на default consent.


5. Типи банера і UX-нюанси

Типи банера

Cookiebot підтримує кілька форматів:

  • dialog (по центру);

  • bar (зверху або знизу);

  • inline.

Формат не впливає на юридичну коректність, але сильно впливає на UX.


Кнопки банера

Типові варіанти:

  • Allow all

  • Reject all

  • Customize / Selection

GDPR вимагає:

  • щоб Reject був не менш доступним, ніж Allow;

  • щоб не було dark patterns.


Overlay чи ні

Overlay блокує сайт до вибору.

Плюси:

  • користувач точно зробить вибір.

Мінуси:

  • гірший UX;

  • більше відмов.

Вибір залежить від стратегії сайту.


6. Default checked чекбокси - небезпечна зона

Найбезпечніший варіант:

  • нічого не pre-checked.

Pre-checked маркетингові cookies:

  • часто вважаються порушенням;

  • особливо в ЄС.


7. Типові UX-помилки

Помилка 1

Банер з’являється, але:

  • не має Reject all.

Помилка 2

Cookie Declaration захована або відсутня.

Помилка 3

Мова банера не відповідає сторінці.

Помилка 4

Неможливо змінити згоду після кліку.


8. Що перевіряють аудитори і юристи

Зазвичай дивляться:

  • чи є банер;

  • чи є granular choice;

  • чи є Reject;

  • чи є Cookie Declaration;

  • чи можна відкликати згоду;

  • чи cookies не ставляться до згоди;

  • чи логічний default consent


ЧАСТИНА 8. Питання та відповіді про Cookiebot, міфи і що робити після впровадження

Ця частина відповідає на ті питання, які виникають після налаштування.
Саме тут зазвичай з’являються сумніви, страхи і міфи.


Часті питання (FAQ)

Чи можна використовувати Cookiebot без Google Tag Manager

Так.
Cookiebot може працювати:

  • напряму через script у head;

  • без GTM взагалі;

  • з автоматичним блокуванням.

GTM - це інструмент керування тегами, а не обов’язкова умова.


Чи обов’язково використовувати Google Consent Mode

Для сайтів, які:

  • використовують Google Analytics;

  • використовують Google Ads;

  • працюють у ЄС або з європейським трафіком,

Consent Mode фактично обов’язковий.

Без нього:

  • Google може обмежити вимірювання;

  • з’являються попередження;

  • реклама працює гірше.


Чи можна просто заблокувати всі теги до згоди і не морочитись

Можна, але:

  • ти втратиш першу сторінку;

  • аналітика буде неповною;

  • Ads втратить моделювання;

  • бізнес-дані стануть менш точними.

Тому в реальних проєктах:

  • Google теги - Advanced;

  • сторонні теги - Basic.


Чи законно використовувати Advanced Consent Mode

Так, якщо:

  • cookies не ставляться до згоди;

  • персональні дані не обробляються;

  • користувач поінформований.

Саме для цього Advanced Mode і був створений.


Чи потрібен Cookiebot, якщо є WordPress-плагін

Плагін і є Cookiebot, просто у формі WordPress-інтеграції.

Важливо:

  • плагін має бути оновлений;

  • Consent Mode має бути увімкнений;

  • порядок скриптів має бути правильний.


Чи можна використовувати Cookiebot тільки для ЄС

Так.

Можна налаштувати:

  • показ банера тільки в ЄС;

  • auto-consent для інших регіонів;

  • різні default правила.

Але:

  • якщо сайт глобальний, часто безпечніше показувати банер всім.


Чи потрібен Cookiebot для маленького сайту

Якщо сайт:

  • має аналітику;

  • має рекламу;

  • має сторонні віджети,

розмір сайту не має значення.


Поширені міфи

Міф 1. Cookiebot = просто банер

Ні.

Cookiebot:

  • зберігає лог згод;

  • передає consent у Google;

  • керує блокуванням;

  • забезпечує юридичну логіку.


Міф 2. Consent Mode замінює CMP

Ні.

Consent Mode:

  • не питає згоду;

  • не показує банер;

  • не зберігає рішення.

Без CMP він безкорисний.


Міф 3. Якщо є Cookiebot, можна не думати

Ні.

Cookiebot:

  • інструмент;

  • але логіку і порядок налаштовуєш ти.

90% проблем - це неправильна інтеграція.


Міф 4. Reject знижує аналітику до нуля

Ні.

Advanced Consent Mode:

  • зберігає агреговані сигнали;

  • дозволяє моделювання;

  • зменшує втрати.


Що робити після впровадження

1. Регулярно перевіряти

Рекомендовано:

  • після кожної зміни тегів;

  • після редизайну;

  • після додавання нового сервісу.


2. Слідкувати за новими тегами

Будь-який новий тег:

  • має бути оцінений;

  • віднесений до категорії;

  • правильно підключений.


3. Оновлювати тексти банера

Особливо якщо:

  • міняється бізнес-модель;

  • додаються сервіси;

  • змінюється законодавство.


4. Перевіряти Cookie Declaration

Cookiebot сканує сайт автоматично, але:

  • нові cookies можуть з’являтись;

  • треба періодично переглядати список.


Типова стратегія для сучасного сайту

Оптимальна схема виглядає так:

  • Cookiebot як CMP;

  • Consent Mode v2 увімкнений;

  • default consent - denied;

  • Google теги - Advanced;

  • сторонні теги - Basic;

  • cookie_consent_update для Basic;

  • мультимовний банер;

  • Cookie Declaration у футері.

Це золота середина між compliance і аналітикою.


Фінальний висновок всієї статті

Cookiebot - це не про "галочку для GDPR".
Це про:

  • контроль даних;

  • довіру користувачів;

  • стабільну аналітику;

  • безпечну рекламу;

  • спокій у разі перевірок.

Правильно налаштований Cookiebot:

  • не заважає бізнесу;

  • не ламає аналітику;

  • не дратує користувачів;

  • і реально працює.