Режим согласия в Google Ads: как настроить Consent Mode v2

Что режим согласия делает с тегами Google

Режим согласия (consent mode) сообщает тегам Google, что посетитель разрешил, а что запретил. Теги читают состояние и ведут себя по-разному: пишут или не пишут куки, отправляют полные данные или урезанный сигнал. В справке Google Ads сказано прямо: режим согласия не дает баннер и не заменяет его, он с баннером взаимодействует.

Отсюда разграничение, на котором спотыкается половина внедрений. Баннер собирает выбор человека. Режим согласия переводит этот выбор в сигналы, которые понимают теги. Сайт с красивым окном про cookie, где нажатие кнопки никуда не передается, режима согласия не имеет - у Google нет способа узнать, что посетитель ответил.

Кого это касается по требованиям Google

Google описывает правило в обновлении режима согласия для трафика ЕЭЗ. Если посетитель из Европейской экономической зоны, а вы измеряете его действия тегами Google на сайте или SDK в приложении, выбор пользователя нужно передавать в Google - иначе закрывается доступ к персонализации рекламы, ремаркетингу и части статистики. То же правило действует, когда данные Google Analytics идут в Google Ads, Search Ads 360 или Display & Video 360.

Второй момент почти всегда понимают неверно. Сертифицированная платформа управления согласием (CMP) с интеграцией IAB TCF обязательна для площадок, показывающих рекламу через AdSense, Ad Manager и AdMob: для ЕЭЗ и Великобритании с 16 января 2024 года, для Швейцарии с 31 июля 2024 года. Рекламодателю Google ставит другое условие - передавать сигналы согласия через режим согласия или TCF. Конкретную CMP из партнерской программы Google при этом не навязывает, о чем и пишет в пояснениях к политике согласия пользователей из ЕС.

Зачем это знать, если европейского трафика нет

Регион считается по тому, где находится посетитель, а не по стране аккаунта. Кампании на Казахстан, Узбекистан или ОАЭ все равно собирают какую-то долю визитов из Европы: командировки, релокация, VPN, диаспора. Доля может быть в пределах процента, и тогда вопрос стоимости внедрения решается просто.

Есть причина разобраться и без европейского трафика вовсе. Рекламными данными теперь управляют сигналы согласия. Раньше эту роль делили настройки Analytics, и перемена уже задела аккаунты за пределами Европы. Подробности ниже, в разделе про параметры. Короткая версия: стартовое значение `ad_storage` теперь решает, попадут ли рекламные данные из тега Analytics в аккаунт Google Ads. Значение стоит выбрать осознанно.

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

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

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

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

Расширенный режим

Теги загружаются сразу и вызывают API режима согласия. Стартовые значения стоят на `denied`, если не настроено иначе, причем для ЕЭЗ, Швейцарии и Великобритании поведение отличается от остальных регионов. Пока согласие не получено, теги отправляют бескуковые пинги. После нажатия кнопки состояние обновляется, и при согласии уходят полные данные.

Состав пинга описан в справке и на юридическую проверку выносится именно он: отметка времени, user agent, referrer, признак наличия параметров клика в URL, булево состояние согласия, случайное число и идентификатор платформы согласия. Профили пользователей на этих пингах не строятся и списки ремаркетинга не собираются.

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

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

Четыре параметра и что закрывает каждый

Версия v2 появилась в ноябре 2023 года и добавила два параметра к двум прежним. Сейчас их четыре.

• `ad_storage` - хранение куки и идентификаторов для рекламных целей.
• `ad_user_data` - отправка пользовательских данных в Google для рекламы. Google отмечает, что этот параметр нужен для измерения, включая расширенные конверсии и теговое отслеживание конверсий.
• `ad_personalization` - персонализированная реклама. Если одновременно выставлен старый параметр `allow_ad_personalization_signals` с противоположным значением, персонализация выключается.
• `analytics_storage` - хранение куки для аналитики, например для расчета длительности визита.

Рядом с ними три служебных типа: `functionality_storage`, `personalization_storage`, `security_storage`. Сами теги Google на них не реагируют, но в Google Tag Manager ими удобно блокировать сторонние скрипты - от чата на сайте до пикселей партнеров.

Что происходит при `ad_storage` в значении `denied`: новые рекламные куки не пишутся, а сторонние куки на доменах google.com и doubleclick.net не используются, кроме защиты от спама и фрода. Один момент упускают почти все. В Google при этом по-прежнему уходит полный адрес страницы вместе с параметрами клика в URL. Обрезать их отдельной настройкой можно, о ней дальше.

Что поменялось 15 июня 2026 года

Раньше рекламные данные, собранные тегом Analytics, попадали в аккаунт по решению двух независимых механизмов: переключателя «Сигналы Google» в настройках ресурса GA4 и значения `ad_storage`. Схема давала противоречия - «Сигналы» выключены, а данные в Google Ads идут, потому что `ad_storage` разрешен.

С 15 июня 2026 года остался один контур. Справка Google Ads фиксирует это примечанием: `ad_storage` управляет использованием рекламных куки и идентификаторов из тега Google Analytics и Firebase SDK в Google Ads, и если это не нужно, стартовое значение ставят `denied`. Переключатель «Сигналы Google» продолжает работать, но отвечает теперь только за отчеты внутри Analytics.

Google также заявил, что позже в 2026 году персонализацией целиком станет управлять параметр `ad_personalization`. Дату не назвали, планировать под нее нечего.

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

Установка через Google Tag Manager или CMP

Теперь конкретика по установке. Я ставлю режим согласия в Google Tag Manager - в моей практике это привычная процедура, отдельного проекта из нее не выходит.

Два пути

Первый: готовая CMP. У Google есть список партнерских CMP, их шаблоны лежат в галерее шаблонов сообщества Tag Manager, а интеграция настраивается в интерфейсе тега за несколько шагов. Плюс подхода в поддержке: когда Google меняет версию режима согласия, новую версию выкатывает провайдер.

Второй: свой баннер плюс свой шаблон в контейнере. Здесь используются API самого Tag Manager - `setDefaultConsentState` и `updateConsentState`. Готовый пример вендор-независимого шаблона Google выложил на GitHub.

Порядок вызовов

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

В контейнере за это отвечает триггер Consent Initialization. Он срабатывает раньше всех остальных, включая триггер Initialization. На него вешается тег CMP или тег, который выставляет стартовые значения.

Есть подводная часть. Внутри шаблонов Tag Manager нельзя подменять `updateConsentState` вызовом `gtag('consent','update', ...)` - команды gtag становятся в очередь и могут не успеть до следующего события. Если баннер грузится асинхронно и рискует опоздать, в стартовой команде задается `wait_for_update` с числом миллисекунд ожидания.

Состояние обновляют на той странице, где человек нажал кнопку, до перехода. Загруженная с отказом страница, которая перезагрузилась уже с согласием, теряет часть событий: в Google Analytics у сессии может не оказаться события `session_start`. Обратная ситуация тоже описана в справке - если команда приходит перед самой выгрузкой страницы, браузер может оборвать запрос.

Региональные значения

Стартовые значения имеет смысл ограничивать регионами, где баннер показывается. Регион задается кодом по ISO 3166-2, причем более специфичное правило перекрывает общее: при `granted` для US и `denied` для US-CA посетитель из Калифорнии получит `denied`.

Про Швейцарию забывают регулярно. Массив регионов, где перечислены только страны ЕЭЗ и Великобритания, оставляет швейцарских посетителей на глобальном значении.

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

У каждого тега в разделе Advanced Settings есть Consent Settings. Там два блока: встроенные проверки согласия, которые есть у тегов Google по умолчанию, и дополнительные проверки с тремя состояниями - не задано, дополнительное согласие не требуется, требовать согласие для срабатывания. Второй вариант удобен как отметка «тег проверен».

Чтобы видеть картину по всему контейнеру, включите обзор согласия: Admin, затем Container Settings, затем Enable consent overview в дополнительных настройках. После этого в разделе Tags появляется отдельный экран со списками настроенных и ненастроенных тегов и массовым редактированием. Настройки заработают после публикации контейнера.

Передача параметров клика и обрезка рекламных данных

При `ad_storage` в значении `denied` идентификатор клика не сохраняется в куки первой стороны. Механизм url_passthrough передает его между страницами через адресную строку. Условия перечислены в справке: тег с поддержкой согласия на странице, включенная функция, внедренный режим согласия, переход в пределах того же домена и наличие GCLID или DCLID в URL.

Для тегов Google Ads и Floodlight функция включается в теге Conversion Linker галочкой «Enable linking on all page URLs». К ссылкам начнут добавляться параметры `gclid`, `dclid`, `gclsrc`, `_gl` и `wbraid` - редиректы на сайте должны их пропускать, а аналитика игнорировать.

Обратная настройка - `ads_data_redaction`. При значении `true` и запрещенном `ad_storage` идентификаторы клика из запросов тегов Google Ads и Floodlight вырезаются, а сами запросы уходят через домен без сторонних куки. При разрешенном `ad_storage` настройка ни на что не влияет.

Моделирование конверсий при отказе

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

Условия описаны в справке: корректно внедренный режим согласия или IAB TCF v2.0 и порог в 700 кликов по рекламе за 7 дней на связку «домен - страна». Дальше модели проходят период обучения, и моделированные конверсии постепенно появляются в отчетах. Отдельно включать нечего.

Полезная цифра для планирования: по данным Google, согласившиеся пользователи конвертируются в 2-5 раз чаще отказавшихся, а разброс зависит от отрасли, типа конверсии и доли согласия. Пример из той же справки: при доле согласия 50% рекламодатель потерял 19% конверсий, а моделирование вернуло 18%.

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

Честная оговорка от самого Google: система не видит, был ли у отказавшегося посетителя контакт с рекламой. Модели стремятся не завышать, поэтому часть случившихся конверсий в отчет не попадет.

Заметной просадки числа конверсий после запуска баннера я в своих проектах не видел - но это следствие географии, а не качества настройки. Доля европейского трафика в кампаниях по СНГ, Азии и Заливу маленькая, и статистика на ней почти не меняется. У проекта с половиной трафика из Европы картина будет другая.

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

Проверка: Tag Assistant и диагностика Google Ads

Проверок две, и делать стоит обе. Первая показывает, что происходит на странице. Вторая - что дошло до Google Ads.

Tag Assistant

Откройте tagassistant.google.com, введите адрес сайта, дождитесь открытия вкладки и примите баннер. Сообщение «Could not connect» на этом шаге нормально для базового режима: тег заблокирован до согласия, после нажатия кнопки соединение появится.

Дальше по шагам:

• В сводке выберите самое раннее событие Consent и в секции API Call убедитесь, что заданы все четыре параметра.
• Альтернативный путь - вкладка Consent в выводе тега, колонка On-page Default. Для посетителя из ЕЭЗ, Великобритании и Швейцарии там должно стоять Denied.
• Затем откройте последнее событие Consent и проверьте колонку On-page Update - после нажатия «принять все» значение меняется на Granted.
• Вкладка Tags покажет, какие теги сработали, а какие заблокировало состояние согласия.

Теги ведут себя по-разному, и это частая находка на этом шаге. Тег Google Ads уважает встроенные проверки, а сторонний скрипт, добавленный кастомным HTML без настроек согласия, срабатывает независимо от баннера.

Статус в аккаунте

В интерфейсе путь идет через «Цели» - «Конверсии» - «Сводка», дальше конверсионное действие и вкладка «Диагностика». Статусов два.

Первый - режим согласия внедрен. Сигналы доходят, порог моделирования пока не набран. Второй - режим внедрен и моделирование активно. В этом случае первые четыре недели рядом показывается таблица прироста по связкам «домен - страна».

Статус появляется не сразу: справка называет 48 часов, в отдельных случаях до двух недель. Если Tag Assistant показывает корректную картину, а статуса нет - это задержка, а не поломка. Прирост может не отобразиться и по другим причинам: режим стоит меньше семи полных дней либо четырехнедельное окно уже закрылось.

Проверять эти экраны имеет смысл после каждой правки баннера и каждой смены CMP. Новая версия шаблона провайдера может сбить передачу сигналов незаметно: интерфейс баннера выглядит прежним, а статус в аккаунте меняется через две недели.

Смежные материалы: базовая постановка отслеживания разобрана в статье про настройку отслеживания конверсий, состав передаваемых в Google данных и хеширование - в материале про расширенные конверсии, требования к клиентской базе - в статье про Customer Match. Остальные разборы по контексту собраны в обзоре кластера.

Частые вопросы