Как настроить режим согласия в Google Tag Manager

Руслан Фатхутдинов

Веб-аналитик агентства Реаспект

Редактор Telegram-канала «Идея украдена»

На момент написания этой статьи функционал настроек, связанных с согласием, находится в режиме BETA. И это говорит о том, что инструмент будет активно развиваться и дополняться новыми функциями. 

Важно сказать, что настройки, связанные с согласием, доступны без ограничений для обеих версий Google Tag Manager, как для бесплатной, так и для платной GTM 360. 

Типы согласия 

Есть пять типов согласия, которые рекомендует использовать Google: 

Интересно, что в Европейском союзе хранилища functionality_storage и security_storage относятся к хранилищам строгой необходимости и не требуют получения согласия. 

Настройки, связанные с согласием на уровне тегов 

Настройки, связанные с согласием на уровне тегов, находятся в конце раздела «Расширенные настройки». 

Обычно внутри раскрывающегося списка есть два раздела. Но иногда он один. Почему это происходит, описано ниже. 

Проверки встроенного согласия 

Тег проверяет статус всех типов согласия, перечисленных в блоке. Теги со встроенной проверкой согласия обычно меняют поведение в зависимости от того, было ли получено согласие конкретного типа. 

Например, на скриншоте выше указаны типы согласия ad_storage и analytics_storage, перечисленные в разделе «Проверка встроенного согласия». Это значит, что тег (конкретно шаблон этого тега) указал в своих разрешениях, что ему необходим доступ для чтения и/или записи к этим конкретным типам разрешений. 

Это важно знать и учитывать, чтобы понимать, как поведет себя тег в конкретной ситуации. 

У тегов Google (Analytics, Ads и Floodlight) есть встроенные проверки для analytics_storage и ad_storage, и их поведение описано. Другие теги могут требовать другие типы согласия, а что происходит в ситуации предоставления или непредоставления согласия, надо читать в доках на официальном сайте сервисов. 

Проверки дополнительного согласия 

Эта настройка позволяет проверять уровень предоставленного согласия прямо из самого контейнера, даже если сам тег никак не взаимодействует с API согласия. 

В разделе представлено три варианта: 

1. Не настроено – опция по умолчанию. Если вы не точно знаете, как данное согласие должно влиять на работу тега, выбирайте эту опцию. 
2. Дополнительное согласие не требуется – выбирайте эту опцию, если тег должен запускаться вне зависимости от того, какой уровень согласия дал пользователь. 
3. Для активации тега требуется дополнительное согласие – эта опция для гибких настроек, если тег должен менять свое поведение в зависимости от разных настроек типов согласия. После активации этой опции появится небольшая таблица, в которую можно добавить любые из пяти описанных выше типов согласия. Тег будет срабатывать только в том случае, если все перечисленные типы согласия получат разрешение. 

Окно обзора настроек режима согласия 

Для активации окна с обзором настроек режима согласия перейдите в раздел «Администрирование» > «Настройки контейнера» и поставьте галочку в пункте «Включить обзор настроек режима согласия». 

После этого в разделе «Теги» вверху справа, рядом с кнопкой «Создать», появится иконка в виде щита с галочкой (Обзор настроек режима согласия). 

Нажав на эту кнопку, вы откроете окно со списком всех тегов и их настройками согласия. 

Все теги в этом окне распределены по двум блокам: 

1. «Режим согласия не настроен» – в этом блоке находятся все теги, у которых в разделе «Проверка дополнительного согласия» выбрана опция «Не настроено». Другими словами, проверка дополнительного согласия не настроена. 
2. «Режим согласия настроен» – здесь находятся все теги, у которых настроена проверка дополнительного согласия. 

• Значение «Нет» в колонке указывает, что в дополнительных настройках согласия у тега был выбран вариант «Дополнительное согласие не требуется». 
• Если в настройках выбран пункт «Для активации тега требуется дополнительное согласие», в колонке «Дополнительное согласие» будут указанные типы согласия. 

В окне «Обзор настроек режима согласия» доступны массовые действия с согласием. Для того чтобы задать согласие сразу нескольким тегам, надо поставить галочки напротив нужных, и нажать на иконку щита с шестеренкой (Массово изменить настройки, связанные с согласием). 

Триггеры обработки согласия 

Есть 2 типа триггеров, которые относятся к режиму согласия: 

1. Инициализация. 
2. Инициализация согласия. 

Оба триггера добавлены в раздел «Просмотр страницы» и в режиме предпросмотра загружаются отдельными событиями. 

Триггер «Инициализация согласия» 

Триггер «Инициализация согласия» срабатывает самым первым из всех возможных триггеров. Этот триггер используется для запуска тегов, которые задают или обновляют статус согласия, получаемого от пользователя. Таким образом гарантируется, что теги, которые будут вызваны триггерами после этого триггера, будут учитывать заданные пользователем настройки согласия. 

Другими словами, этот триггер предназначен для использования с тегами платформы для запросов согласия или тегов, которые устанавливают настройки согласия по умолчанию. 

По умолчанию во всех контейнерах присутствует триггер «Consent Initialization – All Pages». 

На уровне данных (dataLayer) этот триггер отправляется в качестве события «gtm.init_consent» с именем «Consent Initialization». 

Триггер «Инициализация» 

Триггер «Инициализация» запускается сразу после триггера «Инициализация согласия», но перед любыми другими триггерами. Он используется для настройки зависимостей, не связанных с согласием. 

Если надо запустить какой-нибудь тег, до загрузки контейнера, а следовательно, добавления каких-то данных datalyer, надо привязываться к этому триггеру. 

По умолчанию во всех контейнерах присутствует триггер «Initialization – All Pages». 

На уровне данных (dataLayer) этот триггер отправляется в качестве события «gtm.init» с именем «Initialization». 

Настройка обработки согласия 

Для окончательной настройки обработки согласия необходимо подготовить свой сервис, который проведет анализ сайта на наличие кук, распределит их по категориям, и запросить согласие у посетителей. 

Или можно воспользоваться одним из сервисов, который берет на себя все задачи по сбору согласия. Google в своем справочнике предлагает на выбор 9 CPM-платформ. 

Некоторые платформы добавили свои решения в общую галерею тегов и переменных Google Tag Manager. Три решения можно увидеть в окне обзора настроек режима согласия. Еще часть решений можно найти в разделе «Шаблоны» по ключевым словам «Constent» или «CMP». 

В этой статье будет описан процесс настройки режима согласия на примере сервиса cookiebot. 

Настройка проекта в cookiebot 

1. Заходим на сайт cookiebot и проходим регистрацию. 

2. Нажимаем на иконку с карандашом около поля Domain Group (в этом блоке происходит добавление, удаление и переключение между группами доменов). Задаем название своей группы доменов / компании. 

Одна группа доменов объединяет в себе домены и поддомены, принадлежащие одной компании. 

3. Вкладка «Domains» в разделе «Settings» предназначена для управления доменами и поддоменами: 

• В поле «Domain name», нажав на иконку со знаком плюса, можно добавить адрес домена / поддомена. В столбце «Scan frequency» задается частота переобхода сайта с целью обновления списка cookie-файлов. 
• В поле «Domain alias» задаются дополнительные зеркала домена, если он доступен по нескольким адресам. 
• Если вы добавили несколько доменов, найдите поле «Enable bulk consent for all domains». Активируйте его, чтобы согласие, данное на одном домене, было учтено всеми доменами. 
• В блоке «User consent expiration» можно выбрать срок, через который у пользователя снова будет запрошено согласие. 

4. Вкладка «Dialog» в разделе «Settings» предназначена для управления внешним видом окна для сбора согласия, его позиции появления, а также содержания. 

5. Вкладка «Declaration» в разделе «Settings» дает возможность настроить, нужно ли показывать посетителю список кук, найденных на сайте, или нет. 

6. На вкладке «Content» в разделе «Settings» можно выбрать язык окна запроса согласия, а также изменить или добавить свои условия в текст согласия. 

7. Последняя вкладка раздела «Settings» называется «Your scripts» и отвечает за установку скрипта cookiebot на сайт. Так как мы будем использовать Google Tag Manager, нас интересует только значение Domain Group ID. 

8. В разделе «Cookies» находится список обнаруженных во время сканирования сайта файлов cookie. Для каждого файла будут указаны примеры страниц, на которых они были обнаружены, примеры значения, к какому домену они относятся и срок их жизни. 

Кроме того, каждому файлу можно задать тип согласия и описание. 

Соответствие типов согласия Google Tag Manager и Cookiebot 

Для большинства файлов cookiebot автоматически определит тип согласия. А для тех файлов, для которых не сможет его определить, выставит значение «Unclassified». Этот тип согласия не относится ни к одному другому. И не будет блокироваться в случае запрета какого-либо типа согласия со стороны посетителя. Другими словами, очень важно распределить все «Unclassified»-файлы по правильным типам. 

Важно! Если сайт был добавлен недавно, эта страница может не содержать файлы cookie. Обращайте внимание на информацию в разделе status. 

9. В разделе «User consents» содержится статистика по сбору согласия для всех добавленных в группу сайтов. 

10. А в разделе «Reports» содержится информация о выполненных сканированиях сайтов. 

Настройка тега cookiebot в контейнере Google Tag Manager 

1. В контейнере переходим в раздел «Шаблоны» > «Шаблоны тегов», находим шаблон с названием «Cookiebot CMP» и добавляем его себе. 

2. В разделе «Теги» создаем новый тег. 

• Тип – Cookiebot CMP. 
• Cookiebot ID – Domain Group ID, полученный в результате настройки cookiebot. 
• Language – Default (auto-detect). Способ определения тегом языка, на котором надо показывать баннер сбора согласия посетителю. 
• Enable IAB Transparency and Consent Framework – стоит отмечать только в случае, если используете фреймворки сбора согласия (Transparency and Consent Framework (TCF)). 
• Default Consent State – все поставить «Granted». Какой уровень согласия будет у тега с указанными типом до того, как пользователь сам укажет тип согласия. 
• Wait for update – 2000. Сколько миллисекунд ждать до показа баннера сбора согласия. 
• Триггер – «Consent Initialization – All Pages». 

Чтобы проверить корректность настройки тега, можно запустить контейнер в режиме предпросмотра. 

А так запуск тега выглядит в режиме предпросмотра. 

Настройка триггеров обновления согласия 

Триггерами некоторых тегов выступают разные этапы загрузки страницы. Например, у PageView тега Universal Analytics триггером выступает событие Page View. При запросе согласия эти события будут упущены. То есть просмотр страницы, в течение которого дано согласие, не попадет в счетчик. И первым просмотром будет уже следующая загрузка страницы. 

Чтобы засчитать просмотр или в момент загрузки страницы, или в момент выдачи согласия необходимо добавить 5 новых триггеров типа пользовательское событие: 

• cookie_consent_statistics, 
• cookie_consent_marketing, 
• cookie_consent_preferences, 
• cookie_consent_necessary, 
• сookie_consent_update. 

Каждое из этих событий происходит в момент обновления статуса согласия для каждого из типов согласия. 

Настройка типов согласия для тегов 

Остается открыть окно обзора настроек согласия и для каждого тега указать правильный тип согласия. 

Результат настройки режима согласия 

В результате настройки режима согласия теги с типами согласия, которое дано не было, просто не будут запускаться на уровне самого контейнера. 

Покажу, как это работает на примере тега Universal Analytics – Pageview. 

1. Зададим тегу проверку дополнительного согласия уровня «Для активации тега требуется дополнительное согласие» с типом «analytics_storage». 

2. Вторым триггером запуска добавим «CE – cookie_consent_statistics». 

3. Тип согласия «analytics_storage» в GTM равен типу согласия «Statistics». Поэтому в самом теге «Cookiebot CMP» выставим этому типу согласия значение по умолчанию «Denied». 

4. Запускаем режим предпросмотра и смотрим событие «Container Loaded» (триггер «Просмотр страницы»), так как именно оно является обычным триггером для запуска основных счетчиков. 

Видим, что тег не запущен: 

Открываем подробную информацию о теге и видим, что тег не запущен по причине «Not fired due to missing consent» (Не запущен из-за отсутствия согласия). 

Файла cookie Universal Analytics (Имя _ga) нет. 

Никаких хитов тоже нет. 

4. Предоставим согласие на сбор Statistic данных. 

После выдачи согласия произошло событие «cookie_consent_statistics» и тег запустился. 

Заключение 

На момент написания этой статьи владельцам сайтов на территории России нет необходимости досконально контролировать режим согласия и сбор данных, как, например, это происходит в Европейском союзе или штате Калифорния. Но, вероятно, в какой-то момент такая потребность появится. 

И, как вы видите, настроить работу с согласием благодаря Google Tag Manager и другим готовым решениям достаточно легко и быстро. 

Но всегда стоит держать в голове, что в случае отказа какому-то типу согласия, будет заблокирован запуск всех тегов, требующих этот тип согласия. Например, запрет сбора статистических данных сделает посетителя невидимым для ваших систем аналитики.