Consent Mode в GA4 и GTM настройка режима согласия на сайте

Cookie-баннер сам по себе не управляет аналитикой. Он только показывает пользователю варианты выбора. Чтобы этот выбор влиял на GA4, рекламные теги и другие инструменты, сайт должен передать корректное состояние согласия до отправки данных и обновить его сразу после действия посетителя.

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

Что делает Consent Mode

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

В рабочей схеме участвуют три компонента:

• баннер или CMP получает и сохраняет выбор посетителя;
• Consent Mode переводит категории баннера в технические статусы granted и denied;
• GTM запускает теги в правильном порядке и применяет к ним встроенные либо дополнительные проверки согласия.

Эти компоненты нельзя считать взаимозаменяемыми. Consent Mode не создает текст политики, не определяет правовое основание и не решает, в каких регионах требуется согласие. Юридическая модель формируется отдельно, а техническая настройка должна точно ее реализовывать.

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

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

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

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

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

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

Какие сигналы необходимо настроить

Для современной конфигурации Google ключевыми считаются четыре состояния:

• analytics_storage — разрешение на хранение данных аналитики, включая связанные cookie;
• ad_storage — разрешение на рекламное хранилище;
• ad_user_data — разрешение передавать Google пользовательские данные для рекламных задач;
• ad_personalization — разрешение использовать данные для персонализированной рекламы.

Дополнительно могут применяться functionality_storage, personalization_storage и security_storage. Они относятся к функциональности сайта, персонализации и безопасности. Набор должен соответствовать реальным категориям баннера. Нельзя автоматически выдавать рекламное согласие из общего разрешения на аналитику или объединять разные цели только ради удобства настройки.

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

Что подготовить до работы в GTM

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

• соберите все теги GTM, скрипты в коде сайта, пиксели, виджеты и встроенные медиасервисы;
• разделите обязательные, аналитические, функциональные и рекламные технологии;
• определите регионы показа баннера и правила по умолчанию вместе с ответственным за правовые требования;
• решите, будет ли использоваться готовая CMP с шаблоном GTM или собственный баннер;
• зафиксируйте, где хранится выбор и как пользователь сможет изменить или отозвать его;
• подготовьте тестовые сценарии до изменения рабочего контейнера.

Consent Mode — не юридическая консультация и не доказательство соблюдения законодательства. Он исполняет переданные статусы. Если категории баннера сформулированы неверно или выбор пользователя сохраняется некорректно, технически исправный контейнер не устранит этот риск.

Пошаговая настройка через GTM

Шаг 1. Подключить источник согласия

Для готовой CMP используют официальный или проверенный шаблон из галереи GTM и документацию поставщика. Собственный баннер интегрируют через пользовательский шаблон, который обращается к Consent API GTM. Пользовательский HTML с командой gtag consent для управления состояниями внутри GTM использовать не рекомендуется: очередь команд может обработаться позже следующего события.

Шаг 2. Назначить Consent Initialization

Тег, который устанавливает значения согласия, запускают по триггеру Consent Initialization — All Pages. Этот этап выполняется раньше обычной Initialization и остальных триггеров. Его задача — предоставить состояние до того, как аналитический или рекламный тег попытается отправить событие.

Шаг 3. Установить состояния по умолчанию

Шаблон должен немедленно задать значения для всех используемых категорий. Конкретные значения и региональные правила определяются выбранной моделью согласия. Ниже показана логика для пользовательского шаблона GTM, а не код для тега Custom HTML.

const setDefaultConsentState = require('setDefaultConsentState');

setDefaultConsentState({​
ad_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied',
analytics_storage: 'denied',
wait_for_update: 500
});

Параметр wait_for_update дает асинхронному решению короткое время на чтение ранее сохраненного выбора. Значение подбирают по реальной работе CMP и скорости сайта, а не копируют механически. Слишком большое ожидание задерживает измерение, слишком маленькое не успевает получить состояние.

Шаг 4. Передать выбор пользователя

После нажатия кнопки баннера CMP должна сопоставить выбранные категории с сигналами Consent Mode и вызвать обновление на той же странице до перехода по ссылке или перезагрузки. Для собственного шаблона применяется updateConsentState.

const updateConsentState = require('updateConsentState');

updateConsentState({​
ad_storage: 'granted',
ad_user_data: 'granted',
ad_personalization: 'denied',
analytics_storage: 'granted'
});

Пример показывает частичный выбор: аналитика и рекламное хранилище разрешены, а персонализация рекламы — нет. Реальные значения должны формироваться динамически. Нельзя заменять выбор пользователя заранее подготовленным набором granted.

Шаг 5. Сохранить и восстановить состояние

Consent Mode не хранит пользовательское решение вместо CMP. Баннер должен сохранить выбор допустимым способом и восстановить его при следующей загрузке страницы. На повторном визите сначала устанавливаются значения по умолчанию, затем как можно раньше применяется ранее сохраненное состояние. Также нужен доступный интерфейс для изменения настроек.

Шаг 6. Настроить региональную логику

Если баннер и состояния отличаются по регионам, в шаблоне можно задавать региональные правила. Коды и приоритеты необходимо тестировать отдельно: более конкретная настройка региона может переопределять общую. Решение о том, где показывать баннер и какие статусы задавать, нельзя принимать только на основании геолокации из GTM — оно должно соответствовать правовой и продуктовой модели компании.

Как управлять Google и сторонними тегами

Теги Google для GA4, Google Ads, Floodlight и Conversion Linker имеют встроенные проверки согласия и сами меняют поведение в зависимости от статуса. При корректно настроенном расширенном режиме дополнительная блокировка этих тегов через Require additional consent может нарушить работу механизма: тег вообще не запустится и не сможет передать ограниченный сигнал.

Для сторонних тегов встроенной поддержки может не быть. Тогда в разделе Consent Settings задают дополнительное требование и указывают подходящий тип согласия. Рекламный пиксель не должен запускаться по разрешению только на аналитику, а функциональный сервис не следует без проверки относить к обязательным.

После инвентаризации удобно включить Consent Overview. Он показывает, для каких тегов дополнительные настройки уже заданы, а какие остались без решения. Это не заменяет тестирование, но помогает обнаружить забытые теги и массово проверить конфигурацию контейнера.

Как проверить внедрение

Проверка должна охватывать не одну кнопку «Принять все», а полный жизненный цикл выбора. Основной инструмент — предварительный просмотр GTM с Tag Assistant. На вкладке Consent нужно убедиться, что значения по умолчанию появляются на самом раннем событии, а после взаимодействия с баннером фиксируется корректное обновление.

Минимальный набор тестов:

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

2. отказ от всех необязательных категорий — cookie и сторонние теги не появляются вопреки выбору;

3. согласие только на аналитику — рекламные сигналы остаются denied;

4. согласие на все категории — разрешенные теги и cookie начинают работать после update;

5. отзыв согласия — статусы меняются обратно, а дальнейшие события учитывают новый выбор;

6. повторный визит — сохраненные настройки восстанавливаются без краткого запуска запрещенных тегов;

7. переход между страницами и сценарий SPA — состояние не теряется при смене маршрута;

8. мобильная версия, разные браузеры и регионы — баннер и техническая логика согласованы.

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

Типичные ошибки и последствия

Баннер не связан с Consent Mode

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

Состояние по умолчанию задается слишком поздно

Если GA4 или рекламный тег запускается раньше consent-тега, первое событие может уйти без ожидаемых ограничений. Consent Initialization должен срабатывать до остальных триггеров, а в коде сайта не должны параллельно загружаться неконтролируемые копии тех же тегов.

Обновление выполняется после перехода

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

Google теги заблокированы дополнительными проверками

Команда одновременно включает Consent Mode и добавляет к GA4 жесткое условие запуска только при granted. Для базового режима такое блокирование может быть частью архитектуры, но для расширенного оно лишает тег возможности работать в ограниченном режиме и снижает доступность моделирования.

Сторонние теги остаются без контроля

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

Категории CMP и сигналы не совпадают

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

Как оценивать данные после запуска

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

Для контроля полезно разделить три группы показателей:

• технические — доля страниц с корректным default и update, ошибки тегов, дубли контейнеров;
• согласие — распределение выбора по категориям, повторные изменения и сбои сохранения;
• аналитика — изменение объема событий, ключевых действий, рекламных конверсий и доли моделируемых данных.

Резкое падение не следует автоматически объяснять отказами пользователей. Сначала исключают технические причины: неверный триггер, отсутствующий analytics_storage, блокировку Google тега, дубли CMP, неправильное восстановление выбора и потерю update при переходе. Только после этого оценивают реальное влияние новой политики согласия на отчетность.

Краткие выводы

Consent Mode связывает выбор пользователя с поведением тегов, но не заменяет cookie-баннер, CMP и правовую оценку. Надежная настройка начинается с инвентаризации технологий и карты соответствия между категориями баннера и техническими сигналами.

В GTM consent-тег запускают через Consent Initialization, состояния по умолчанию задают до аналитики и рекламы, а выбор обновляют сразу после действия пользователя. Google теги используют встроенные проверки; для сторонних решений правила запуска настраиваются отдельно.

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