Режим согласия Google (Consent Mode) V2

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

В версии V2 основными нововведениями являются два новых сигнала согласия: ad_user_data и ad_personalization, а также обновленная схема URL для передачи состояний согласия в сервисы Google.

Этот материал является свободным переводом с дополнениями и комментариями к гостевому посту Маркуса Берша (который написал отличный FAQ по Режиму согласия на своем родном немецком языке) в блоге Симо Агавы.

Что делает Consent Mode?

Режим согласия в первую очередь связан с сбором дополнительных сигналов от пользователей, которые не дали согласия на доступ к их личным данным или хранилищу браузера для сбора данных. Эти сигналы затем используются Google для моделирования конверсий (Google Ads, Floodlight и т.д.) и поведения посетителей (Google Analytics 4).

Эта статья представляет собой технический обзор, поэтому мы не будем подробно останавливаться на этических и юридических вопросах, связанных с сбором данных от пользователей без их согласия. См. раздел “Итог” для ознакомления с некоторыми мыслями Симо Ахавы по этой теме.

Этот метод сбора аналитических данных и сигналов рекламы от пользователей без их согласия основан на логике избегания доступа к хранилищу браузера. Таким образом, куки, содержащие личные данные (такие как идентификаторы в интернете), не будут доступны сервисам Google, и вместо этого используются случайные, временные идентификаторы.

Данные без согласия не отображаются напрямую в отчетах Google – вместо этого они проходят процесс моделирования, в ходе которого они формируются и адаптируются так, чтобы выглядеть как настоящие данные (собранные от пользователей, давших свое согласие).

Что нового в Consent Mode V2?

В версии V2, исходные сигналы Режима согласия (ad_storage для рекламных куки и analytics_storage для аналитических куки) дополняются двумя новыми сигналами:

• ad_user_data: дал ли пользователь согласие на использование его личных данных в рекламных целях?
• ad_personalization: дал ли пользователь согласие на использование его данных для ремаркетинга?

Полный список параметров режима согласия: 

Тип согласия	Описание
ad_storage	Активирует хранение данных, таких как файлы cookie, связанных с рекламой.
ad_user_data ⚠️	Устанавливает статус согласия на отправку в Google пользовательских данных, связанных с рекламой.
ad_personalization	Устанавливает статус согласия на персонализированную рекламу.
analytics_storage	Активирует хранение данных, таких как файлы cookie, связанных со статистикой, например продолжительностью посещения и т. д.
functionality_storage	Активирует хранение данных, связанных с функциями сайта или приложения, например языковыми настройками и т. д.
personalization_storage	Активирует хранение данных, связанных с персонализацией, например рекомендуемыми видео и т. д.
security_storage	Активирует хранение данных, связанных с обеспечением безопасности, например аутентификацией, предотвращением мошенничества и другими способами защиты.

В отличие от ad_storage и analytics_storage, эти флаги не влияют на функционирование тегов на самом сайте. Это дополнительные параметры, отправляемые вместе с сигналами в сервисы Google, предназначенные для инструктирования этих сервисов о том, как можно использовать данные пользователя в рекламных целях.

Таким образом, в то время как ad_storage и analytics_storage являются квалификаторами данных на входе (поскольку они контролируют, какие идентификаторы отправляются с сигналами), ad_user_data и ad_personalization являются инструкциями для сервисов Google о том, как обрабатывать данные на выходе.

Режим согласия включает в себя дополнительные, более продвинутые настройки, такие как ads_data_redaction, которые предотвращают передачу любых идентификаторов кликов или декораций куки третьих сторон в рекламных потоках. Кроме того, существуют настройки, такие как allow_ad_personalization_signals, которые также регулируют, какие типы данных могут быть доступны рекламным сервисам Google. В случае конфликта между этими настройками и Режимом согласия, преимущество отдается “строжайшей” настройке в пользу защиты данных.

⚠️ В недавнем письме, отправленном клиентам Google Ads, Google объявила об изменении в Режиме согласия в марте 2024 года.

Google объявила, что они будут автоматически отображать сигнал согласия ad_user_data в соответствии с установленным значением ad_storage. Этого можно избежать, вручную установив ad_user_data в настройках Режима согласия. Другими словами, это изменение касается сайтов, использующих Режим согласия, но не устанавливающих сигнал ad_user_data.

Почему Google это делает? Хороший вопрос. ad_user_data требуется для сбора Улучшенных конверсий. Он также необходим, если вы хотите связать Google Analytics 4 с Google Ads.

Похоже Google сделали это, чтобы гарантировать, что Улучшенные конверсии и связи GA4/GAds не нарушатся в марте 2024 года для сайтов, использующих Режим согласия, но еще не обновившихся для использования этих относительно новых сигналов.

Расширенный vs. Базовый режим

Consent Mode V2 также ввел понятия Расширенного режима согласия (Advanced Consent Mode) и Базового режима согласия (Basic Consent Mode).

Технически, это не новшества. Расширенный режим согласия — это Режим согласия в том виде, как мы его знаем (и как Google хочет, чтобы мы его использовали). Это означает сбор данных от пользователей, которые не дали своего согласия.

Базовый режим согласия означает, что Режим согласия активен на странице (или в приложении), но загрузка тегов Google и сбор данных блокируются до тех пор, пока не будет получено согласие пользователя.

Другими словами:

• Без Режима согласия: Режим согласия вообще не реализован на странице. Предполагается, что все собранные данные имеют согласие пользователя на передачу в сервисы Google.
• Базовый Режим согласия: Режим согласия реализован, но данные собираются только в случае, если пользователь дает свое согласие.
• Расширенный Режим согласия: Режим согласия реализован, и данные собираются от пользователей, как в случае предоставления согласия, так и в случае его отказа.

Выбор режима влияет на качество моделирования данных:

	Расширенный вариант	Базовый вариант
Поведение тега	Теги Google загружаются до того, как пользователю показывается диалоговое окно для получения согласия. Если пользователь не соглашается применять файлы cookie, теги отправляют сигналы ping без них.	Теги Google блокируются, пока не будет получено согласие.
Моделирование поведения в GA4	Да
Моделирование конверсий в GA4	Да	Да *
Моделирование конверсий в Google Рекламе	Да	Да *

* Если теги заблокированы из-за настроек согласия, система не будет собирать данные. В таком случае для моделирования конверсий в Google Рекламе используется общая модель. Учитываются разные функции, например тип браузера, тип действия-конверсии, время суток и другие высокоуровневые переменные, по которым невозможно идентифицировать пользователя.

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

Базовый режим Consent Mode

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

На самом деле это довольно незамысловато. Вы реализуете Режим согласия на сайте таким образом, чтобы теги отправляли сигналы согласия в сервисы Google. Однако вы блокируете активацию тегов, если согласие не было предоставлено. Другими словами, вы отправляете в Google только сигналы о предоставленном согласии, и Google будет предполагать, что данные от пользователей, не давших согласие, не были собраны.

На момент написания этого текста, выполнение этой ручной работы остается за вами. Не существует волшебного переключателя “Базовый режим согласия”, который автоматически настроит теги Google должным образом.

Настройки согласия в Google Tag Manager

Google Tag Manager предлагает интерфейс настроек согласия для управления настройками согласия в ваших тегах.

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

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

Это исключительно настройки Google Tag Manager. У них нет аналогов в gtag или самом Режиме согласия. Например, хотя теги Google Analytics 4 чувствительны ко всем четырем сигналам Режима согласия, они имеют встроенные проверки согласия только для analytics_storage и ad_storage. Почему? Потому что только эти состояния согласия фактически изменяют работу кода тега. ad_user_data и ad_personalization являются флагами URL, которые автоматически добавляются к запросам GA4 – тег события GA4 не нуждается во взаимодействии с этими состояниями.

Нужно ли использовать Consent Mode в 2024?

Возможно, особенно если вы работаете в Европейской экономической зоне или ваши посетители сайта являются субъектами данных в ЕЭЗ.

Как минимум, в 2024 году вам, скорее всего, потребуется реализовать Базовый режим согласия для всех ваших тегов Google. Это не обязательно плохо, даже если потребует дополнительных ресурсов для маркировки и внедрения. Поскольку вы собираете данные только от пользователей, которые дали свое согласие (верно?), Базовый режим согласия просто означает, что вы сообщаете это состояние согласия в сервисы Google вместе с собранными данными.

Однако, если вы используете рекламные сервисы Google (напрямую или через Google Analytics 4), Режим согласия может быть обязательным.

• Если вы собираете собственные данные о пользователе (first-party user data), используете user_id Google Ads или делитесь данными о конверсиях из Google Analytics 4 в Google Ads, вы должны реализовать Режим согласия и установить флаг ad_user_data.
• Если вы собираете данные для ремаркетинга с помощью рекламных сервисов Google, вы должны реализовать Режим согласия и установить флаг ad_personalization.

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

Если вы хотите или должны реализовать Режим согласия, вам следует сделать это как можно скорее. Режим согласия следует развертывать как можно раньше на странице или в процессе рендеринга приложения. Для этого в Google Tag Manager для веба есть встроенный триггер, Инициализация согласия (Consent Initialization).

Важно: Нет необходимости что-либо менять в настройке ваших тегов или начинать отправку данных без предоставленного согласия (Расширенный режим согласия)! Требуется реализовать Режим согласия, и Базовый режим согласия будет вполне достаточен. В этом случае, как и раньше, вам просто нужно убедиться, что данные не собираются и теги не активируются до получения согласия.

В большинстве случаев у вас уже есть Платформа управления согласием, и включение новых сигналов — это всего лишь флажок в настройках.

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

Что если Consent Mode не будет реализован к марту 2024?

Исходя из недавней презентации Google, если вы добавили на свой сайт баннер CMP (Платформа Управления Согласием) и настроили его правильно, вы столкнетесь с проблемами отслеживания эффективности. Вы частично или полностью потеряете данные от пользователей, которые не дают согласие на использование куки.

В результате теряются конверсии, и ухудшается оптимизация кампаний.

Моделирование в Режиме Согласия помогает преодолеть эту проблему, заполняя пробелы с помощью алгоритмов машинного обучения (Google говорит с помощью ИИ — в соответствии с модными технологическими тенденциями).

Во время презентации Google особенно сосредоточилась на моделировании в рамках конверсий Google Ads.

Важно упомянуть, что моделирование поведения и конверсий в GA4 (для пользователей, отказывающихся от согласия на куки) будет работать только с Расширенным Режимом Согласия.

Моделирование конверсий Google Ads включено как для базового, так и для расширенного типов.

Точность такого подхода вызывает вопросы; тем не менее, это все же лучше, чем полное отсутствие Режима согласия.

Для сравнения и обобщения во время презентации была представлена следующая таблица.

Для повышения точности Google рекомендует использовать расширенную реализацию. Базовая версия лучше, чем полное отсутствие режима согласия.

Если мы не будем отправлять информацию о согласии в Google с тегами с марта 2024 года, мы не сможем захватывать новых пользователей из Европейской экономической зоны (EEA) в списки аудитории в функции GA4 Audiences и делиться ими с Ads. Это сделает невозможным проведение ремаркетинга в Google Ads, Floodlight и Display.

Моделирование в Расширенном Режиме Согласия

Во время расширенной реализации моделирования алгоритмы Google могут использовать наблюдаемые пути пользователей, давших согласие, и экстраполировать образцы на агрегированные данные без куки, которые не содержат личных идентификаторов. Google использует такие сигналы, как Тип Устройства, Тип Конверсии, Страна, Время Суток и Тип Браузера в качестве индикаторов для повышения точности моделирования.

Моделирование в Базовом Режиме Согласия

Базовая реализация также позволяет моделировать конверсии в Google Ads, однако ее точность ниже. В этом случае мы не собираем никаких хитов без использования куки, поэтому моделирование основывается только на данных от пользователей, которые дали согласие на использование куки.

Изменится ли что-то с точки зрения защиты данных?

Оговорка: мы не являемся вашей юридической командой.

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

Собранные от этих пользователей данные выглядят практически так же, как и раньше – только теперь они содержат дополнительный сигнал «согласие предоставлено», и могут также включать явные указания на то, что данные могут быть использованы для рекламных сервисов Google.

Что касается «Расширенного режима согласия», его использование требует очень тщательного обдумывания вместе с вашей юридической командой. Помните, что вы собираете данные от пользователей, которые могли не дать согласия на такое.

Как проверить, активен ли Consent Mode?

Когда Режим согласия активен, будь то в Базовом или Расширенном режиме, с каждым запросом аналитики и рекламы в сервисы Google отправляются дополнительные параметры.

Вы можете использовать Tag Assistant, вкладку Network в инструментах разработчика вашего браузера или расширение для браузера.

Для оригинальной версии режима согласия, если вы смотрите на сетевые запросы, параметр, который вам нужен, называется &gcs, и имеет значение в следующем формате: G1xy.

x обозначает согласие на куки Google Ads и может быть либо 1 (предоставлено), либо 0 (отказано).

y обозначает согласие на куки Google Analytics и может быть либо 1 (предоставлено), либо 0 (отказано).

Возможные значения следующие:

Значение	Описание
G100	Согласие не было предоставлено.
G110	Согласие предоставлено Google Ads, но не Google Analytics.
G101	Согласие предоставлено Google Analytics, но не Google Ads.
G111	Согласие предоставлено и Google Ads, и Google Analytics.

Значение G100 возможно только в «Расширенном режиме согласия» (Advanced Consent Mode).

С Режимом согласия V2, дополнительный параметр gcd можно найти во всех запросах, и вы можете прочитать больше о его составе ниже.

Проверка через сетевые запросы (Инструменты разработчика)

Если вы отлаживаете сетевые запросы, вы можете просто использовать фильтр по gcs, чтобы найти все запросы, содержащие этот параметр. Это будет включать запросы как Google Analytics, так и Google Ads.

Кликнув по запросу, вы можете прокрутить до параметров полезной нагрузки запроса, чтобы найти значение gcs в списке:

Вы также заметите здесь другую настройку: gcd. Больше об этом ниже.

Проверка через Tag Assistant

Если вы перейдете на https://tagassistant.google.com/, вы сможете протестировать состояния согласия для любых сайтов, использующих теги Google.

После добавления домена, который вы хотите протестировать, вы можете выбрать ID тега в верхней части Tag Assistant, затем выбрать событие в навигации слева и, наконец, выбрать вкладку «Согласие» (Consent), чтобы увидеть, в каком состоянии были различные сигналы согласия в момент события.

Если вы видите предупреждение о том, что «тег считал согласие до того, как было установлено значение по умолчанию» (a tag read consent before a default was set), это означает, что у вас возникла ситуация, когда ваши состояния согласия не были установлены до того, как теги, ссылающиеся на них, успели сработать.

Решение

Google Tag Manager: Убедитесь, что любые теги, записывающие согласие, срабатывают до события загрузки контейнера, Container Loaded. Рекомендуется использовать триггер инициализации согласия (Consent Initialization) для тегов, записывающих согласие.

После обновления проверьте, присутствуют ли состояния согласия в событии загрузки контейнера (Container Loaded event).

Для реализации через gtag: Найдите код, который вызывает API gtag(‘config’, ‘AW-xxxx’) и убедитесь, что команды gtag(‘consent’, ‘default’) или gtag(‘consent’, ‘update’) выполняются до любых команд gtag(‘config’). После обновления проверьте, присутствуют ли состояния согласия в событии Config.

Сигналы Consent Mode V2

Параметр gcs используется исключительно для ad_storage и analytics_storage. Для новых сигналов и для Режима согласия V2 существует дополнительный URL-параметр, gcd, который вам нужно будет интерпретировать.

gcs включается во все запросы к сервисам Google, даже если Режим согласия не активен.

Он кодирует значения для всех четырех сигналов согласия (ad_storage, analytics_storage, ad_user_data и ad_personalization) и содержит информацию о том, как был сгенерирован сигнал согласия.

Формат строки следующий:

&gcd=11<ad_storage>1<analytics_storage>1<ad_user_data>1<ad_personalization>5

Строка начинается с 11, использует 1 для разделения различных сигналов согласия и заканчивается числом, например 5 (или иногда чем-то другим), чтобы обозначить конец.

Что касается возможных значений для сигналов, вот таблица, как мы ее сейчас знаем:

Буква	Описание	Пример
l	Строчная L означает, что сигнал не был установлен с Режимом согласия.	11l1p1l1l5 (Только analytics_storage был отклонен по умолчанию).
p	Отклонено по умолчанию (без обновления).	11p1p1p1p5 (все состояния согласия отклонены по умолчанию).
q	Отклонено как по умолчанию, так и после обновления.	11p1q1p1p5 (пользователь обновил свой выбор согласия, установив analytics_storage в отклонено после того, как он уже был установлен в отклонено по умолчанию).
t	Предоставлено по умолчанию (без обновления).	11t1t1t1t5 (все состояния согласия предоставлены по умолчанию).
r	Отклонено по умолчанию и предоставлено после обновления.	11r1r1r1r5 (пользователь предоставляет согласие на все сервисы после того, как они сначала были отклонены по умолчанию).
m	Отклонено после обновления (без установки по умолчанию).	11p1m1p1p5 (все другие состояния были отклонены по умолчанию, но analytics_storage был установлен только после того, как пользователь отклонил его).
n	Предоставлено после обновления (без установки по умолчанию).	11n1n1n1n5 (сайт не установил состояние согласия по умолчанию и вместо этого установил все состояния в предоставлено после выбора пользователя).
u	Предоставлено по умолчанию и отклонено после обновления.	11u1u1u1u5 (пользователь отозвал все согласия после того, как они были установлены в предоставлено по умолчанию).
v	Предоставлено как по умолчанию, так и после обновления.	11v1v1v1v5 (все состояния были предоставлены по умолчанию и по подтверждению пользователя).

Если вы запутались в терминах «по умолчанию» (default) и «обновление» (update), обратитесь к этой статье за дополнительной информацией о двух различных командах для взаимодействия с Режимом согласия.

Эти буквы могут показаться неоднозначными и могут измениться в будущем. Очевидно, что Google не предполагает, что вы будете отлаживать Режим согласия, анализируя URL-запросы. Вместо этого предпочтительным способом является использование Tag Assistant, но иногда (особенно если вы также перемешиваете данные в своих собственных сервисах), понимание схемы параметров URL может быть полезным.

Для каких тегов актуален Consent Mode?

Режим согласия является изобретением Google. Идея сбора данных от пользователей без их согласия и использование этих данных для моделирования полностью принадлежит Google.

Другие теги и сервисы теоретически тоже могут использовать эти флаги. Например, в Google Tag Manager вы можете создавать пользовательские шаблоны, которые реагируют на любые из заданных состояний согласия, даже на те, которые вы маркируете самостоятельно! Но это не «Режим согласия» – это просто создание технологии вокруг флагов и параметров, которые Google использует для Режима согласия.Интересно, что похоже, Microsoft копирует идею Google со своей собственной реализацией Режима согласия, которая имеет поразительные сходства с Режимом согласия Google.

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

Если ваша платформа управления согласием (CMP) не поддерживает интеграцию с Режимом согласия, или если вы хотите настроить все вручную, вы, безусловно, можете это сделать.

Если вы используете Google Tag Manager, вы можете использовать мой пользовательский шаблон тега для установления состояний согласия как для команд «по умолчанию» (default), так и для «обновления» (update).

Команда «по умолчанию» должна быть настроена на срабатывание по триггеру инициализации согласия (Consent Initialization), чтобы установить начальное состояние до активации любых других тегов.

Как только вы узнаете предпочтения пользователя относительно согласия, вы можете активировать тег с командой «обновление» (update).

Если вы не используете GTM или хотите настроить все с помощью JavaScript, вы можете использовать для этого метод gtag.

Приведенный выше код является лишь очень базовым примером. Важно, чтобы команда по умолчанию (default) вызывалась до активации любых тегов Google и чтобы команда обновления(update) вызывалась, как только будут зарегистрированы выборы пользователя относительно согласия.

Настройка Режима согласия может быть довольно трудоемкой, особенно если вы настраиваете все вручную. Однако важно выполнить это правильно, чтобы в итоге не столкнуться с юридическими проблемами. Маркус Берш предлагает отличный список проверок для верификации реализации здесь: https://www.markus-baersch.de/consent-checkliste-buch/  (на немецком).

Итог

Режим согласия все еще очень хитроумный.

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

Сторонники Режима согласия пытаются разделить это мнение, утверждая, что пользователи не обязательно отказывались от согласия на “анонимные сигналы” или что это не действительно “личные данные” согласно GDPR и так далее. Они могут быть правы, хотя идея “анонимных данных”, собранных с сигналом отказа от согласия, кажется довольно абсурдной. Аналогично, GDPR имеет очень широкую сеть, когда речь идет о личных данных, так что сбор таких вещей, как идентификаторы заказов или идентификаторы пользователей от несогласных пользователей, почти наверняка приведет вас к проблемам, если вы будете проверены на соответствие GDPR.

Если вы собираете что-либо от пользователя, который не дал согласия на эту конкретную услугу, вы подвергаете себя множеству рисков:

• Юридические, если у вас нет законных оснований для сбора этих данных помимо согласия.
• Этические, если вы предполагаете, что пользователю нормально, если вы собираете данные о нем, даже если он отказал в согласии.
• Имидж бренда, если станет известно общественности, что вы собираете данные от пользователей, отказавшихся от согласия.
• Безопасность данных, если вы случайно собираете чувствительную информацию от пользователей, не давших согласия.

Таким образом, сбор данных от пользователей без их согласия всегда будет представлять собой риск, превышающий риск несбора данных. Вам необходимо тщательно оценить этот риск.

Кроме того, Базовый режим согласия, когда данные собираются только от согласившихся пользователей, на данный момент кажется очевидным решением. Возможно, Google просто автоматически включит его по умолчанию для всех своих сервисов.

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

Используемые материалы

• Consent Mode V2 For Google Tags | Simo Ahava’s blog 
• Consent Mode (Google tags) – Custom Tag Template | Simo Ahava’s blog 
• Consent Mode Deep Dive for Web & App: Power Durable Performance in 2024 
• [GA4] Моделирование поведения для режима согласия – Cправка – Google Analytics 
• Режим согласия – Cправка – Google Реклама 
• Consent Mode 2.0 FAQ | 📊 Blog Markus Baersch [de] 
• Google Consent Mode v2 — Prepare your marketing for 2024 
• Таблица сравнения CMP