Что изменилось после перехода на Consent Mode v2

Что изменилось после перехода на Consent Mode v2

Тема стала острой после того, как Google усилил требования к работе рекламных и аналитических тегов. Теперь cookie consent — это не просто баннер с кнопками «Принять» и «Отклонить», а часть всей схемы сбора сигналов. Если сайт работает с рекламой, аналитикой или ремаркетингом, пересматривать логику consent приходится почти всегда.

Раньше многие ограничивались коротким уведомлением о cookie. Этого уже мало. Google Consent Mode v2 меняет саму механику: сайт должен передавать статус согласия до запуска тегов, а не после, и именно тут всплывает вопрос, что нового в cookie consent после перехода на Google Consent Mode v2. У команды появляется больше точек контроля, а у владельца сайта — больше мест, где можно ошибиться.

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

Чем Consent Mode v2 отличается от прежней версии

Главное отличие — новые сигналы consent. В прежнем подходе чаще смотрели только на аналитику и рекламу в общем виде, а теперь Google ожидает более точные настройки по типам данных и персонализации. Это влияет не только на баннер, но и на то, как сайт отдает теги при первом визите пользователя.

Consent Mode v2 вводит более строгую логику для рекламных сценариев. Если раньше сайт мог жить с общим «разрешено или запрещено», то теперь приходится разделять несколько параметров и передавать их явно. Иначе рекламные теги ведут себя непредсказуемо: часть блокируется, часть работает в режиме ограниченной передачи сигналов, а отчеты в кабинете выглядят рваными.

Базовый cookie-баннер показывает выбор пользователя. Consent Mode v2 делает этот выбор технически значимым для тегов. В этом и разница: баннер — это интерфейс, а Consent Mode v2 — слой правил для аналитики и рекламы. Путают их часто.

Какие данные и разрешения теперь нужно учитывать

В центре внимания обычно четыре категории: analytics_storage, ad_storage, ad_user_data и ad_personalization. Они не равны между собой, и это не придирка к терминам. analytics_storage отвечает за хранение данных для аналитики, ad_storage — за рекламные cookies, ad_user_data — за передачу пользовательских данных в рекламные системы, ad_personalization — за персонализацию рекламы.

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

Есть и практический нюанс. Тексты в баннере должны совпадать с тем, какие категории реально включены в настройку consent. Если сайт просит «разрешить cookie», но внутри разносит данные по четырем режимам, пользователю сложно понять, на что он соглашается. А потом сложно объяснить аудитору, почему интерфейс и логика живут отдельно.

Как это влияет на cookie-баннер и UX

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

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

Нужно продумать повторный вызов настроек. Люди часто меняют мнение не сразу, а через 2–3 визита. Если ссылка на настройки спрятана в подвале и написана микроскопическим шрифтом, consent превращается в формальность. А потом отдел маркетинга удивляется, почему отказов много, а поведение пользователей в отчете не совпадает с ожиданиями.

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

Что нужно проверить в аналитике и рекламе

Первым делом проверяют GA4. Если consent передается неправильно, часть событий может не доходить, а часть — терять параметры. Для отчетов это неприятно: трафик есть, конверсии есть, но атрибуция начинает «плыть».

Google Ads тоже чувствителен к Consent Mode v2. Ошибка в параметрах consent может обрезать аудитории ремаркетинга, ухудшить качество сигналов конверсии и сделать сравнение кампаний менее честным. Это особенно заметно на сайтах, где трафик идет из нескольких источников, а рекламный кабинет любит аккуратные данные.

GTM надо смотреть отдельно. Контейнер может быть настроен правильно, но триггеры запускаются раньше, чем приходит default consent. В итоге пиксель срабатывает еще до того, как сайт получил выбор пользователя. Формально код есть, по факту логика сломана.

Сторонние пиксели тоже стоит прогнать руками. Meta Pixel, TikTok Pixel, сервисы ремаркетинга и виджеты аналитики иногда не умеют нормально жить в новой схеме без дополнительной обвязки. На небольшом сайте это дает 1–2 странных провала в данных, на крупном — уже системную дыру.

Типичные ошибки после внедрения Consent Mode v2

Самая частая ошибка — неверный порядок загрузки тегов. Сначала должен отработать default consent, и только потом запускаться аналитика и реклама. Если порядок перевернут, сайт отправляет сигналы без нужного статуса, а исправить это потом сложнее, чем кажется.

Еще одна проблема — отсутствие default consent вообще. Тогда система не знает, как вести себя до выбора пользователя. Иногда разработчики надеются, что баннер сам все «прикроет», но без явного стартового состояния Consent Mode v2 работает не так, как ожидается.

Часто расходятся настройки CMP и контейнера GTM. В интерфейсе пользователь отказал от рекламы, а GTM все равно получает разрешение на ad_storage. Такой конфликт не всегда бросается в глаза сразу. Он всплывает позже, когда команда сравнивает цифры из Google Ads и отчеты CMP.

Для сайтов, где важна не только аналитика, но и общая устойчивость, полезно смотреть на поддержка сайта после запуска: ошибки consent редко живут изолированно, они часто соседствуют с другими проблемами релизов, кеширования и скриптов.

Как подготовить сайт к обновлению

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

Следующий шаг — проверить CMP. Если платформа управления согласием не умеет передавать analytics_storage, ad_storage, ad_user_data и ad_personalization, обновление затянется. Иногда проще доработать интеграцию, чем перестраивать весь сайт, но это зависит от стека и количества трафика.

После этого обновляют теги. В GTM или в коде сайта надо задать default consent, проверить порядок загрузки и убедиться, что при отказе рекламные теги не стартуют раньше времени. Затем тестируют все в режиме предварительного просмотра, а потом еще раз на реальном сайте. Один тест в браузере — мало.

Полезно проверить и визуальную часть. Кнопка «Настроить» не должна прятаться за лишним кликом. Текст на ней лучше писать коротко. Длинные формулы никто не читает.

Что стоит учесть с точки зрения прав и документации

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

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

Для проектов, где ценится прозрачность и предсказуемость работы сайта, полезно опираться на как оценить надежность сайта перед заказом. Consent-логика — часть надежности, потому что ошибка в ней ломает аналитику так же уверенно, как сбой в форме заявки.

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

И наконец, после запуска обновления не бросайте cookie consent на самотек. Первые 7–14 дней стоит смотреть на отчеты, проверять падения в трафике и сравнивать поведение рекламных тегов до и после релиза. В таких задачах помогает и платформа аналитики и мониторинга сайтов ·, если нужен регулярный контроль за тем, как сайт отдает сигналы и не теряет ли он данные по пути.