Перейти до основного вмісту

Опубліковано: 15 лип. 2026 р.

·

Оновлено: 1 жовт. 2026 р.

· 10 хв читання
Інші мовні версії: Deutsch · English · Русский

Google Consent Mode v2 у ЄС: чим Basic відрізняється від Advanced

Що передають ad_user_data та ad_personalization, як перевірити CMP і чому Consent Mode не є автоматичною гарантією GDPR-compliance.

ON
Oleksandr Nikitin
Історія оновлень

Український переклад російської редакції, технічні відомості якої перевірено 28 вересня 2026 року; нової фактологічної або юридичної оцінки під час перекладу не проводили.

Google Consent Mode v2 у ЄС: чим Basic відрізняється від Advanced

Коротко: Google Consent Mode v2 передає Google вибір користувача через чотири основні consent-сигнали. Basic mode повністю блокує Google tags до згоди. Advanced mode завантажує їх із початковим станом denied і може надсилати обмежені cookieless measurements для моделювання. Вибір режиму має відповідати фактичній CMP-логіці та юридичній оцінці; сам Consent Mode не робить сайт автоматично відповідним GDPR.

Cookie banner може виглядати правильно, а дані все одно надсилаються не так, як вибрав користувач. Наприклад, людина відхиляє marketing cookies, але старий GTM container продовжує передавати ad_user_data: granted. Для бізнесу це одночасно ризик обробки без очікуваного дозволу та поганий вхідний сигнал для Google Ads.

Наша позиція: Consent Mode — не кнопка «зберегти дані». Спочатку він має точно передати вибір людини. Моделювання та Smart Bidding ідуть після цього, а не замість цього.

Технічні відомості перевірено 28 вересня 2026. Перевірка конкретного акаунта та юридична оцінка його потоків даних виконуються окремо.

Google додав до наявних станів ad_storage і analytics_storage два сигнали:

  • ad_user_data — чи дозволено надсилати дані користувача Google для рекламних цілей;
  • ad_personalization — чи дозволена персоналізована реклама.

ad_storage стосується рекламного зберігання, analytics_storage — аналітичного. Дозвіл зберігання не означає дозволу всіх рекламних цілей. Попередня версія також не була лише бінарним перемикачем запуску тега.

Для трафіку з Європейської економічної зони Google вимагає збирати та передавати consent-сигнали, щоб продовжувати використовувати відповідні можливості вимірювання, персоналізації та remarketing. Якщо компанія застосовує власний banner, Google рекомендує впровадити Consent Mode v2; сертифікована CMP може передавати сигнали через свою інтеграцію. Це вимога продукту Google, а не окремий закон під назвою «Consent Mode». (Google Ads Help)

Важливо не підміняти сенс: Google не надає сайту юридичного дозволу на обробку. Компанія, як і раніше, відповідає за те, як отримує consent, які цілі показує людині та які дані надсилає кожному отримувачу.

Чим Basic mode відрізняється від Advanced mode

КритерійВідмінність режимів
До згодиBasic блокує Google tags; Advanced завантажує їх із початковим станом, зазвичай denied.
При відмовіBasic не надсилає Google дані; Advanced може надсилати обмежені запити без cookies.
Моделювання конверсійBasic може використовувати загальні моделі; Advanced — моделі конкретного рекламодавця за виконання умов.
Smart BiddingВикористовує доступні спостережувані та модельні конверсії; обсяг і якість не гарантовані.
Персоналізовані аудиторіїПотрібна згода залишається обов’язковою; моделювання не створює ідентифікованого списку remarketing.
PrivacyОбидва режими потребують оцінки фактичної обробки; Advanced не стає допустимим автоматично.
Складність і вибірBasic передає менше даних; Advanced потребує додаткових перевірок потоків та eligibility.

У Basic mode моделювання Google Ads спирається на загальну модель, оскільки сайт не надсилає власних сигналів про non-consented взаємодії. Advanced mode може дати advertiser-specific modeling, оскільки Google отримує обмежені вимірювання без cookies. Офіційна документація прямо попереджає: advanced implementation означає передавання даних навіть при denied; склад і допустимість цього потоку потрібно оцінювати, а не називати його автоматично «анонімним». (Google: Consent Mode overview)

Відсутність pings сама по собі не доводить Basic: причиною може бути помилка інтеграції, блокувальник або незапущений тег. Перевіряйте конфігурацію та фактичний сценарій разом.

Які умови потрібні для моделювання

Google Ads вказує серед умов 700 рекламних кліків на день протягом семи днів для кожної пари країна–домен, коректну реалізацію та достатню якість моделі. Це критерії eligibility, а не гарантія відновлення певної частки конверсій. Google Ads: умови моделювання.

GA4 behavioural modeling — інший процес. Серед умов: 1 000 подій на день із відмовою від analytics consent щонайменше сім днів, 1 000 щоденних користувачів зі згодою щонайменше в семи з останніх 28 днів і відповідна Advanced-реалізація. Досягнення порогів не гарантує доступності функції. GA4: поведінкове моделювання.

Тому твердження «Advanced повертає 70%» або «підвищує точність ставок на 30%» не можна переносити як обіцянку Canem Errant. Спочатку потрібно перевірити, чи доступне моделювання в конкретному акаунті та чи узгоджуються змодельовані звіти з реальними замовленнями.

Чому це особливо важливо для бізнесу в Австрії та ЄС

Австрійська Datenschutzbehörde вказує, що технічно необов’язкові cookies можна встановлювати або зчитувати лише після consent. Відмова має бути такою самою простою, як згода; pre-checked boxes, прихована відмова та nudging не створюють дійсного вибору. Правило стосується не лише файлів із назвою cookie, а й зберігання або доступу до даних на пристрої. (DSB: Datenschutz & Cookies)

GDPR окремо регулює обробку персональних даних. Якщо компанія спирається на consent, він має бути вільним, конкретним, інформованим та однозначним, а відкликання — доступним без негативних наслідків. (EDPB: Consent)

Звідси два висновки:

  1. CMP має отримувати реальний вибір до технічно необов’язкової обробки.
  2. Consent Mode має точно передавати цей вибір, але не замінює privacy notice, правової підстави, data minimization і договорів з отримувачами даних.

Навіть cookieless ping не можна автоматично оголошувати неперсональним. Оцінка залежить від параметрів запиту, ідентифікаторів, можливості зіставлення та подальшої обробки Google.

Smart Bidding використовує спостережувані та, коли доступно, змодельовані конверсії. Помилки consent змінюють навчальні дані:

  • якщо теги запускаються до вибору, система може обробити дані всупереч інтерфейсу banner;
  • якщо consent завжди залишається denied після прийняття, дозволені події не доходять повністю;
  • якщо Basic і Advanced переплутані, команда неправильно оцінює доступний обсяг моделювання;
  • якщо продажі не звіряються з backend, зростання звітних конверсій можна помилково прийняти за зростання виторгу.

Моделювання не відновлює конкретного користувача й не доводить конкретного продажу. Воно оцінює сукупний обсяг. Тому рекламний звіт потрібно порівнювати із замовленнями та оплатами за той самий період, враховуючи затримку конверсій і повернення.

Крок 1. Зафіксуйте цілі та категорії CMP

Зіставте категорії banner з analytics_storage, ad_storage, ad_user_data і ad_personalization. Не об’єднуйте статистику та персоналізацію в один нечіткий перемикач. Рішення про Basic або Advanced узгодьте з відповідальним за privacy та фактичним списком даних.

Крок 2. Встановіть default до решти тегів

Google рекомендує задавати початковий consent-стан до завантаження вимірювальних тегів. Приклад показує структуру, але регіони та wait_for_update вибираються під конкретну CMP:

У Google Tag Manager використовуйте відповідний CMP template на Consent Initialization. Для власного consent template призначені setDefaultConsentState і updateConsentState; довільний виклик gtag із Custom HTML не є рівноцінною заміною.

Два приклади нижче стосуються прямої gtag-інтеграції поза GTM consent template. Вони передбачають ініціалізований Google tag і підключену CMP, а не є повним встановленням:

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied'
});

Не копіюйте довільну затримку лише тому, що вона є у статті. Google пропонує wait_for_update, коли CMP завантажується асинхронно, але значення має відповідати реальній реалізації. (Google: setup guide)

Затримка 500 ms не є універсальним значенням або постійним блокуванням; подальше оновлення має працювати й після її завершення.

Крок 3. Передайте update після вибору

CMP має оновити лише ті стани, які людина справді дозволила:

gtag('consent', 'update', {
  ad_storage: 'granted',
  analytics_storage: 'granted',
  ad_user_data: 'denied',
  ad_personalization: 'denied'
});

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

CMP зберігає та оновлює вибір; Consent Mode не робить цього автоматично. Передайте update до переходу користувача на іншу сторінку та перевірте збереження відмови після відкликання.

Крок 4. Перевірте всі сценарії

У Tag Assistant і browser network перевірте перший візит, прийняття всіх категорій, повну відмову, частковий вибір, зміну рішення та повторний візит. Потім відкрийте Google Ads diagnostics і переконайтеся, що сигнали справді приймаються.

URL passthrough і ads data redaction — окремі функції. Їх не можна вмикати як універсальний «privacy preset»: оцініть, які click IDs передаються, коли вони редагуються та чи відповідає це документованому вибору користувача.

Passthrough може передавати click information за посиланнями всередині того самого домену: перевірте параметри та redirect. Redaction стосується певних рекламних click IDs при відмові від рекламного зберігання. Жодна функція не створює юридичного дозволу на передавання даних.

Які помилки трапляються найчастіше

Сигнали v2 відсутні. CMP передає лише ad_storage і analytics_storage, оскільки конфігурацію не оновили після 2023 року.

Default встановлюється надто пізно. Google tag встигає виконатися до consent initialization, тому перший запит не відповідає очікуваному стану.

Усі стани змінюються одночасно. Людина дозволяє аналітику, а GTM також вмикає рекламні дані та персоналізацію.

Browser і server container отримують різний consent. У браузері marketing заборонений, але server-side tag продовжує надсилати подію.

Команда перевіряє лише banner. Гарний інтерфейс не доводить, що network requests і платформні diagnostics відповідають вибору.

Обґрунтовуйте висновки даними конкретної інтеграції. Без вибірки, яку можна перевірити, не можна заявляти частку австрійських акаунтів із помилками або фіксовані втрати конверсій.

У server-side схемі web container передає consent parameters у server container, а кожен outbound tag застосовує їх перед надсиланням. Google прямо вказує, що Consent Mode налаштовується у web container, після чого server container отримує ці параметри разом із запитом. (Google: server-side Consent Mode)

Це дає змогу централізовано документувати маршрути даних і не передавати платформам непотрібні поля. Але «подвійна перевірка» корисна лише за одного джерела consent-стану та правил, які можна тестувати. Два неузгоджені шари створюють не додатковий захист, а два місця для помилки.

Consent-aware Google tags обробляють передані стани. Для custom tags Meta, TikTok та інших отримувачів потрібні явні перевірені правила: Google-сигнали не керують ними автоматично. Запишіть мету, допустимі поля, умову надсилання та поведінку після відкликання для кожного адресата.

Практичну архітектуру Pixel, backend і server container розбирає посібник із server-side tracking.

Що можна перевірити цього тижня

  1. Відкрийте Tag Assistant і знайдіть ad_user_data та ad_personalization до та після вибору в CMP.
  2. Порівняйте повну відмову, частковий вибір і повну згоду за реальними network requests, а не лише за інтерфейсом banner.
  3. Перевірте, чи отримує server container ті самі consent-стани.
  4. Звірте Google Ads conversions із backend-замовленнями та відокремте змодельовану зміну звіту від зміни реальних продажів.

Додаткові джерела: Google: CMP setup.

Поширені запитання

Basic блокує Google tags до consent і не надсилає Google дані при відмові. Advanced завантажує tags із початковим denied і може надсилати cookieless measurements для advertiser-specific modeling. Це різний обсяг передавання даних, тому вибір не можна робити лише через бажання отримати більше конверсій у звіті.

Google вимагає актуальних consent-сигналів для використання відповідних функцій вимірювання, remarketing і персоналізації на EEA traffic. Закон вимагає дійсної підстави та дотримання правил cookies і персональних даних, але не приписує конкретний продукт Google. Компанія може вибрати інший технічний шлях, розуміючи обмеження функцій Google Ads.

Скільки конверсій відновить Advanced mode?

Заздалегідь це невідомо. Доступність залежить від трафіку, умов eligibility, згоди та якості налаштування. Перевіряйте diagnostics і backend; не можна обіцяти фіксований відсоток або нові продажі лише завдяки моделюванню.

У Google є програма сертифікованих CMP, але наявність у списку не гарантує правильної конфігурації конкретного сайту. Потрібно перевірити mapping категорій, default/update, порядок завантаження та реальну поведінку запитів. (Google: CMP setup)

Ні. Він передає consent-стани Google tags. Відповідність залежить від інтерфейсу CMP, цілей, підстави обробки, складу даних, отримувачів, договорів, строків зберігання та можливості відкликання. Для спірної архітектури потрібна оцінка privacy-спеціаліста або юриста.


Якщо banner, GTM і Google Ads показують різні consent-стани, спочатку зафіксуйте фактичні network requests. Перегляньте Tracking & CAPI або опишіть проблему у формі.

Де маркетингові дані перестали відповідати реальності?

Опишіть ситуацію: що показує реклама, що відбувається після заявки та якого результату ви очікували.

Для вашої конфігурації перевіряємо, як вибір у CMP доходить до браузерних і серверних тегів. Ця технічна робота з трекінгом не є юридичним підтвердженням усієї обробки даних.

Як перевіряємо трекінг і CAPI Обговорити ситуацію
consent-modeGDPRgoogle-adsprivacyeurope