*Матеріал створений на основі Consent Mode 2.0 FAQ | Blog Markus Baersch та Consent Mode V2 For Google Tags | Simo Ahava’s blog.
Цифровий світ розвивається, з’являються нові технології, удосконалюються алгоритми. Й все більше звертається увага на правила конфіденційності та згоду користувачів.
В березні 2024 набрав чинності новий Закон про цифрові ринки (DMA). Тож розуміння та впровадження Google Consent Mode V2 (режиму згоди) є вкрай важливим.
Якщо сайт чи застосунок збирає дані для створення аудиторії або ремаркетингу за допомогою рекламних служб Google, то власник веб-ресурсу мусить дати згоду на застосування режиму згоди.
Розглянемо нюанси Google Consent Mode V2:
Почнемо.
Режим згоди — це інструмент Google, який передбачає збір додаткових сигналів від користувачів, які не дали згоди на доступ до їхніх особистих даних або сховища браузера для збору даних. Потім Google використовує ці сигнали для моделювання конверсій (Google Ads тощо) та поведінки відвідувачів (Google Analytics 4). Тобто Google Consent Mode v2 — це механізм, призначений для інтеграції налаштувань згоди відвідувачів сайту з рекламними й аналітичними інструментами Google.
Режим згоди простими словами — дійсний дозвіл користувача на використання та обробку персональних даних сайтами та мобільними застосунками перед тим, як Google почне використовувати файли cookie та інші технології відстеження.
Першу версію поточного режиму згоди представили у 2020 році для дотримування законів ЄС про конфіденційність даних (GDPR). Тоді Google дозволив збирати дані для Google Analytics та Google Ads. Тож Google Consent Mode V2 – це оновлена версія, створена відповідно до нового Закону про цифрові ринки.
З березня 2024 при заході в сервіси Google користувачі могли помітити наступне попередження:
Рис. 1 – Дані Google Analytics
Google Consent Mode V2 базується на логіці уникнення доступу до сховища браузера. Таким чином, служби Google не матимуть доступу до файлів cookie, що містять особисті дані (наприклад, онлайн-ідентифікатори), замість них використовуються випадкові ефемерні ідентифікатори.
Єдине, що змінилося в версії V2, це те, що сигнали режиму згоди є обов’язковими для всіх, хто використовує GA4 для формування цільових груп або хто використовує маркетингові теги.
Трохи детальніше. Поточна версія вже має 2 вихідні сигнали режиму згоди:
Зараз ці 2 вхідних сигнали доповнюються 2 додатковими сигналами:
На відміну від ad_storage та analytics_storage, ці позначки не мають функціонального впливу на те, як теги поводяться на самому сайті. Це додаткові параметри, які надсилаються разом із запитами ping до служб Google та призначені для вказівок цим службам щодо того, як дані користувача можна використовувати для реклами.
Сигнали ad_storage та analytics_storage є вихідними кваліфікаторами для даних, оскільки вони контролюють, які ідентифікатори надсилаються разом із запитами ping. Натомість сигнали ad_user_data та ad_personalization є вихідними інструкціями для служб Google щодо обробки даних.
Режим згоди має й додаткові, більш розширені налаштування, як-от ads_data_redaction, які запобігають передачі будь-яких ідентифікаторів кліків або сторонніх файлів cookie в рекламних потоках. Крім того, існують налаштування allow_ad_personalization_signals, які також визначають, до якого типу даних мають доступ рекламні служби Google.
Як це працює?
Користувач надає (статус = надано) згоду або відмовляється (статус = відхилено) від згоди через банер cookie.
Інформація, яка надсилається на платформи Google після вибору, залежатиме від методу, який було вибрано для реалізації: базового чи розширеного.
Базовий режим полягає в блокуванні всіх тегів із правилами запуску в GTM й дозволі їм запускатися лише після надання правильної категорії згоди. Тоді теги надсилають у Google статуси згоди в такому порядку:
Якщо користувач не дає згоди, Google узагалі не передає його дані (навіть статус згоди), й активація тегів Google повністю блокується. Тоді моделювання конверсій для режиму згоди в Google Ads використовуватиме загальну модель.
Згідно з розширеною версією, теги Google завантажуються, коли користувач відкриває сайт або застосунок. Теги завантажують API режиму згоди й виконують наведені дії:
Розширений варіант режиму згоди забезпечує краще моделювання порівняно з базовим, оскільки він дає змогу використовувати не загальну модель, а індивідуальну для рекламодавця.
Рис. 2 – Режими згоди на cookie
Іншими словами наразі користувач має 3 режими роботи з веб-ресурсами:
Проте навіть якщо відвідувачі не погоджуються на використання файлів cookie, служби Google можуть працювати в обмеженому режимі та збирати дані про основні взаємодії, не порушуючи політику конфіденційності.
Основна увага під час обговорення режиму згоди була зосереджена на розрізненні між «базовим» та «розширеним» режимами. Проте це не є чимось новим: власники веб-ресурсів завжди могли використовувати режим згоди, але досі використовували теги, лише якщо на то була згода користувача.
Відповідну інформацію про це можна знайти в довідці Google Analytics для режиму згоди. Тут є наочне порівняння між розширеним та базовим варіантами реалізації.
Рис. 3 – Довідка Google Analytics для режиму згоди
Досі було досить незвично застосовувати це для налаштування GA4, тому відмінність між базовим та розширеним зазвичай була доречною/відомою лише у світі маркетингу Google. Єдине, що змінилося в версії V2, це те, що сигнали режиму згоди є обов’язковими для всіх, хто планує використовувати GA4 для формування аудиторій користувачів або хто використовує маркетингові теги.
Так, якщо ви працюєте в Європейській економічній зоні або відвідувачі вашого сайту є суб’єктами цієї зони. Тобто, якщо ви бачите приблизно таку картинку у своїй Google Analytics 4, як на скриншоті нижче, вам краще впровадити використання Google Consent Mode V2 на свій ресурс.
Рис. 4 – Наявні користувачі з ЄЕЗ
На скриншоті бачимо користувачів з геолокацією у Польщі, а Польща якраз належить до ЄЕЗ.
Усі, у кого раніше не було причин використовувати режим згоди, тепер не повинні цього робити. Єдині винятки — якщо
Потрібні 2 нові сигнали, згадані вище (з налаштуванням «надано»), щоб зібрані дані виконували своє призначення. Будь-хто, кого це торкнеться, мусив додати ініціалізацію режиму згоди та встановлення відповідних прапорців до наявних налаштувань.
Безперечно те, що GA4 більше не зможе створювати цільові групи для маркетингових цілей. Ймовірно, це також стосується тегів Google Ads Remartketing тощо. Можна припустити, що в обліковому записі Ads більше не буде конверсій. Тому впровадження всіх маркетингових налаштувань у Google за наведених вище умов є неминучим.
Кожен, хто використовує Consent Mode V1, мав отримати «автоматично перетворений» прапор ad_user_data, який приймає значення ad_storage. Однак без режиму згоди сигнали будуть повністю відсутні, що стане проблемою з 6 березня (тож ми сподіваємось, ви вже запровадили режим згоди на своєму ресурсі).
Параметри для двох нових прапорців для ad_user_data та ad_personalization також можна знайти в API, функціях для завантаження даних для порівняння клієнтів, розширених конверсіях для потенційних клієнтів або імпорті офлайн-конверсій.
Залежно від мети функції можна очікувати, що однакові правила застосовуються до всіх даних, й конверсії можуть рахуватися, але аудиторії, які можна використовувати для реклами, не створюються.
Якщо режим згоди активний чи то за згодою, чи то в запитах, які надсилаються без згоди, використовуються додаткові параметри, які можна знайти у вкладці “Network” браузера, наприклад, щоб побачити,
Для цього використовується параметр gcs. Якщо його можна знайти в запитах, він має значення в такому форматі: G1xy.
“x” означає згоду на використання файлів cookie Google Ads та має значення “1” (згода) або “0” (заборонено, файли cookie не збиратимуться). Друге значення “y” є аналогом “1” або “0” для згоди на файли cookie Google Analytics.
Таким чином, можливі наступні значення:
Наприклад, за допомогою пошуку “collect” (назва кінцевої точки GA4) або назви параметра “gcs” в огляді мережі можна знайти запити GA4, а корисне навантаження, яке показує всі параметри та їх значення, можна візуалізувати одним кліком:
Рис. 5 – Значення параметра “gcs”
Про наявність двох нових налаштувань режиму згоди 2.0 можна дізнатися з іншого параметра “gcd” (див. наступні розділи).
Найпростіший спосіб перевірки на власному сайті — скористатися режимом Debug View в Google Tag Manager. Якщо ви подивитеся на перегляд подій у шарі даних у лівій частині Tag Assistant, ви побачите записи типу “Consent”. Тут можна побачити, чи це значення за замовчуванням, чи відбулося оновлення, та які налаштування застосовуються перед тим, як спрацьовують відповідні мітки.
Ось приклад, в якому налаштування за замовчуванням були спочатку надіслані в події під номером 10, а потім оновлені в події 13, та встановлені в значення “надано” для всіх відповідних параметрів (див. “API Call”):
Рис. 6 – Подія Consent в Debug View Google Tag Manager
Крім того, окрема вкладка “Consent” також може бути використана для перегляду поточного статусу згоди для кожної події. Для цього не обов’язково використовувати GTM, контроль також можливий безпосередньо через події потоку даних GA4. Google надає додаткову інформацію та приклади в довідці з управління режимом згоди.
Складніше, але не обов’язково надійніше поглянути на рівень даних у консолі браузера. Ненадійно тому, що не всі способи встановлення налаштувань режиму згоди дійсно залишають сліди в dataLayer.
Рис. 7 – Перегляд змінних в dataLayer
З іншого боку, його наявність є вірною ознакою й дозволяє переглянути налаштування, так само як описано вище для попереднього перегляду в GTM.
Режим згоди, як правило, стосується тегів із всесвіту Google, тобто Google Analytics, Google Ads та Floodlight, а також тегів типу “посилання на конверсію”.
Інші теги теоретично також можна контролювати за допомогою інших загальних прапорів, наданих Google для “персоналізації, безпеки та функціональності” (див. Довідку). Можна навіть використовувати будь-які самостійно визначені налаштування, які використовуються виключно для управління відображенням тегів, але не поведінкою, як це працює у випадку з тегами Google щодо використання файлів cookie.
Існує ще один виняток з цього правила: Microsoft Ads також визнає режим згоди. Однак, хоча його потрібно ініціалізувати та використовувати аналогічним чином, він не знаходиться на рівні даних та не пов’язаний безпосередньо з режимом згоди Google, а є повністю незалежним.
Як уже було сказано вище, використання функцій Consent Mode для керування тегами в Google Tag Manager не є єдиним засобом. У більшості випадків «налаштування, що залежить від згоди» вже існує, і його можна та потрібно підтримувати. Відповідна ініціалізація прапорів режиму згоди перед відтворенням може знадобитися, якщо дані використовуватимуться в рекламних цілях.
Якщо ви використовуєте CMP, який не підтримує режим згоди, ініціалізацію можна включити до ваших власних налаштувань через JavaScript безпосередньо на сторінці або тег HTML через Tag Manager або (при використанні GTM) за допомогою шаблону тегу (автор Сімо Ахава).
Як тег HTML, який виконується якомога раніше, якщо надається згода (можливо, як тег налаштування для тегу Google або конверсій Google Ads тощо), він може виглядати так, якщо налаштувати його вручну:
Рис. 8 – Скрипт налаштування тега HTML для впровадження режиму згоди
Це можна зробити за допомогою шаблону тегів з Community Template Gallery в Google Tag Manager:
Рис. 9 – Налаштування режиму згоди через Community Template Gallery в Google Tag Manager
Висновок: ініціалізоване відповідними налаштуваннями “за замовчуванням” або оновлене перед запуском тегів, щоб відповідні сигнали були встановлені як “дозволені” відповідно до налаштувань режиму згоди, чинне налаштування відстеження може бути легко впроваджено таким чином, щоб нові сигнали надсилалися до Google. Це означає, що цільові групи все ще можна створювати та вимірювати конверсії на маркетингових платформах Google.
Найактуальнішу інформацію на 7.02.2024 ми знайшли у Телеграм-каналі Тані Міхальченко RSS: Google Ads + Analytics | контекстна реклама — обговорення спілкування з техпідтримкою Google.
Повторимо, що якщо ви працюєте в Європейській економічній зоні або відвідувачі сайту/застосунку є суб’єктами цієї зони, то впровадити використання Google Consent Mode V2 на ресурс необхідно, аби дані щодо конверсій збирались вірно та ви мали можливість налаштувати списки ремаркетингу.
Щодо ITForce: ми рекомендували клієнтам, яким цей момент актуальний, впровадити Google Consent Mode V2. Наразі задача виконується на стороні клієнтів.
Лайфхак з допису Романа Муртазіна з Facebook:
Якщо ви хочете швидко перевірити чи налаштовано на сайті Google Consent Mode, то дуже рекомендую супер-розширення для Chrome — Consent Mode Inspector by InfoTrust.
Просто. Швидко. Наглядно.
