Що змінилося після переходу на Consent Mode v2
Тема стала гострою після того, як Google посилив вимоги до роботи рекламних і аналітичних тегів. Тепер Google Consent Mode v2 cookie consent — це не просто банер із кнопками «Прийняти» та «Відхилити», а частина всієї схеми збору сигналів. Якщо сайт працює з рекламою, аналітикою або ремаркетингом, переглядати логіку consent доводиться майже завжди.
Раніше багато хто обмежувався коротким повідомленням про cookie. Цього вже замало. Google Consent Mode v2 змінює саму механіку: сайт має передавати статус згоди до запуску тегів, а не після, і саме тут постає питання, що нового в cookie consent після переходу на Google Consent Mode v2. У команди з’являється більше точок контролю, а у власника сайту — більше місць, де можна помилитися.
На практиці це помітно навіть на простих проєктах. Банер наче той самий, але за ним тепер ховаються правила для GA4, Google Ads і тегів із GTM. Один неправильний сценарій — і частина подій зникає в порожнечі. Або в сірій зоні, що теж погано.
Чим Consent Mode v2 відрізняється від попередньої версії
Головна відмінність — нові сигнали consent. У попередньому підході частіше дивилися лише на аналітику й рекламу загалом, а тепер Google очікує точніші налаштування за типами даних і персоналізації. Це впливає не лише на банер, а й на те, як сайт віддає теги під час першого візиту користувача.
Consent Mode v2 запроваджує суворішу логіку для рекламних сценаріїв. Якщо раніше сайт міг працювати з загальним «дозволено або заборонено», то тепер доводиться розділяти кілька параметрів і передавати їх явно. Інакше рекламні теги поводяться непередбачувано: частина блокується, частина працює в режимі обмеженої передачі сигналів, а звіти в кабінеті виглядають уривчастими.
Базовий cookie-банер показує вибір користувача. Consent Mode v2 робить цей вибір технічно значущим для тегів. У цьому й різниця: банер — це інтерфейс, а Consent Mode v2 — шар правил для аналітики й реклами. Плутають їх часто.
Які дані та дозволи тепер потрібно враховувати
У центрі уваги зазвичай чотири категорії: analytics_storage, ad_storage, ad_user_data та ad_personalization. Вони не рівні між собою, і це не придирка до термінів. analytics_storage відповідає за зберігання даних для аналітики, ad_storage — за рекламні cookies, ad_user_data — за передачу користувацьких даних у рекламні системи, ad_personalization — за персоналізацію реклами.
Якщо сайт збирає лише базову статистику, може здаватися, що достатньо одного дозволу. Насправді ні. Для Google Ads і пов’язаних сценаріїв потрібні інші рівні згоди, а інколи потрібні одразу кілька категорій. В інтернет-магазині це особливо помітно: один користувач відмовився від реклами, але залишив аналітику, і лічильники мають це зрозуміти без здогадок.
Є й практичний нюанс. Тексти в банері мають збігатися з тим, які категорії реально ввімкнені в налаштуваннях consent. Якщо сайт просить «дозволити cookie», але всередині розносить дані по чотирьох режимах, користувачеві важко зрозуміти, на що він погоджується. А потім важко пояснювати аудитору, чому інтерфейс і логіка живуть окремо.
Як це впливає на cookie-банер і UX
Cookie-банер тепер не можна робити надто загальним. Користувач має бачити не лише кнопку згоди, а й зрозумілу відмову, а інколи й вибір за категоріями. Тексти доводиться переписувати, бо формулювання «ми використовуємо cookie для покращення сервісу» вже не покриває вимоги до деталізації.
Кнопки теж змінюються. У нормальній схемі користувач бачить щонайменше дві рівнозначні дії: прийняти й відхилити. Іноді потрібен третій варіант — відкрити налаштування та вибрати категорії вручну. Це не декоративна опція. Якщо на сайті є реклама, аналітика й ретаргетинг, то простий бінарний вибір може не закрити всі сценарії.
Потрібно продумати повторний виклик налаштувань. Люди часто змінюють думку не одразу, а через 2–3 візити. Якщо посилання на налаштування заховане в підвалі й написане мікроскопічним шрифтом, consent перетворюється на формальність. А потім відділ маркетингу дивується, чому відмов багато, а поведінка користувачів у звіті не збігається з очікуваннями.
Для складних проєктів зручно заздалегідь звіряти банер із загальною архітектурою сайту, а не ліпити його в останній момент. Тут корисно подивитися і на безпеку сайту, бо consent-шар часто живе поруч з іншими скриптами, і помилка в одному місці здатна зачепити завантаження в іншому.
Що потрібно перевірити в аналітиці та рекламі
Насамперед перевіряють GA4. Якщо consent передається неправильно, частина подій може не доходити, а частина — втрачати параметри. Для звітів це неприємно: трафік є, конверсії є, але атрибуція починає «плисти».
Google Ads теж чутливий до Consent Mode v2. Помилка в параметрах consent може обрізати аудиторії ремаркетингу, погіршити якість сигналів конверсії та зробити порівняння кампаній менш чесним. Це особливо помітно на сайтах, де трафік іде з кількох джерел, а рекламний кабінет любить акуратні дані.
GTM треба дивитися окремо. Контейнер може бути налаштований правильно, але тригери запускаються раніше, ніж приходить default consent. У підсумку піксель спрацьовує ще до того, як сайт отримав вибір користувача. Формально код є, фактично логіка зламана.
Сторонні пікселі теж варто прогнати вручну. Meta Pixel, TikTok Pixel, сервіси ремаркетингу та віджети аналітики іноді не вміють нормально жити в новій схемі без додаткового обв’язування. На невеликому сайті це дає 1–2 дивні провали в даних, на великому — уже системну дірку.
Типові помилки після впровадження Consent Mode v2
Найчастіша помилка — неправильний порядок завантаження тегів. Спочатку має відпрацювати default consent, і лише потім запускатися аналітика й реклама. Якщо порядок перевернуто, сайт надсилає сигнали без потрібного статусу, а виправити це потім складніше, ніж здається.
Ще одна проблема — взагалі відсутній default consent. Тоді система не знає, як поводитися до вибору користувача. Іноді розробники сподіваються, що банер сам усе «прикриє», але без явного стартового стану Consent Mode v2 працює не так, як очікується.
Часто розходяться налаштування CMP і контейнера GTM. В інтерфейсі користувач відмовився від реклами, а GTM усе одно отримує дозвіл на ad_storage. Такий конфлікт не завжди одразу кидається в очі. Він спливає пізніше, коли команда порівнює цифри з Google Ads і звіти CMP.
Для сайтів, де важлива не лише аналітика, а й загальна стійкість, корисно дивитися на підтримку сайту після запуску: помилки consent рідко живуть ізольовано, вони часто сусідять з іншими проблемами релізів, кешування та скриптів.
Як підготувати сайт до оновлення
Почати краще з аудиту поточного cookie-банера. Потрібно зрозуміти, які категорії згод уже є, які тексти бачить користувач і де зберігається його вибір. Один банер може виглядати акуратно, але всередині не мати потрібних статусів для нового режиму Google.
Наступний крок — перевірити CMP. Якщо платформа керування згодою не вміє передавати analytics_storage, ad_storage, ad_user_data та ad_personalization, оновлення затягнеться. Іноді простіше доопрацювати інтеграцію, ніж перебудовувати весь сайт, але це залежить від стека та кількості трафіку.
Після цього оновлюють теги. У GTM або в коді сайту треба задати default consent, перевірити порядок завантаження й переконатися, що при відмові рекламні теги не стартують раніше часу. Потім тестують усе в режимі попереднього перегляду, а потім ще раз на реальному сайті. Одного тесту в браузері замало.
Корисно перевірити і візуальну частину. Кнопка «Налаштувати» не повинна ховатися за зайвим кліком. Текст на ній краще писати коротко. Довгі формулювання ніхто не читає.
| Крок | Що перевірити | Ризик у разі помилки |
|---|---|---|
| 1 | default consent до всіх тегів | теги стартують без статусу |
| 2 | CMP і GTM | розбіжність логіки |
| 3 | GA4 і Google Ads | втрата подій і аудиторій |
| 4 | відмова та повторний виклик налаштувань | поганий UX і скарги |
Що варто врахувати з погляду прав і документації
Технічна частина не закриває питання повністю. Потрібна політика конфіденційності, cookie policy і текст, де зрозуміло описані категорії даних і порядок відкликання згоди. Якщо користувач обрав відмову, сайт має вміти це зафіксувати та зберегти логіку вибору.
Документи краще звіряти з реальним поведінкою банера. Якщо в політиці написано одне, а банер пропонує інше, це створює зайвий ризик для перевірки та для довіри. І так, довіру тут легко втратити через одну криву фразу.
Для проєктів, де цінують прозорість і передбачуваність роботи сайту, корисно спиратися на як оцінити надійність сайту перед замовленням. Consent-логіка — частина надійності, бо помилка в ній ламає аналітику так само впевнено, як збій у формі заявки.
Якщо сайт уже веде облік користувацьких дій, не зайвим буде перевірити, як зберігаються журнали вибору і хто має доступ до них. Тут спливає не лише техніка, а й організаційний порядок. Коли в компанії 3 підрядники і 2 внутрішні відділи, розмита відповідальність швидко перетворюється на спір.
І нарешті, після запуску оновлення не залишайте cookie consent напризволяще. Перші 7–14 днів варто дивитися на звіти, перевіряти падіння в трафіку та порівнювати поведінку рекламних тегів до і після релізу. У таких завданнях допомагає і платформа аналітики та моніторингу сайтів ·, якщо потрібен регулярний контроль за тим, як сайт передає сигнали і чи не втрачає він дані дорогою.
