Баннер cookie перед серверным тегингом: что меняется, а что нет

Имя хоста от первого лица — техническое свойство запроса. Это не разрешение. Если вчера вам требовалось согласие на установку аналитического cookie, оно требуется и сегодня, и то, что cookie теперь ставит metrics.yoursite.com вместо google-analytics.com, здесь ни при чём. Вопрос регулятора — что вы собираете и зачем, а не через какой сервер прошёл пакет по дороге.

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

Теги Google читают состояние согласия из нескольких именованных разрешений — analytics_storage, ad_storage, ad_user_data, ad_personalization — и подстраивают то, что отправляют. До решения посетителя менеджер согласий отправляет значение по умолчанию denied; когда посетитель выбирает, он отправляет обновление. В состоянии denied тег Google всё равно срабатывает, но отправляет пинг без cookie: без идентификатора клиента, без cookie, лишь сигнал, что страница была просмотрена, и ничего больше. Как только analytics_storage становится granted, он отправляет полное обращение. Серверный контейнер получает то, что было отправлено, а сигналы согласия путешествуют вместе с обращением, поэтому серверный тег GA4 ведёт себя так же.

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

Сущности, которые SignalHost создаёт в вашем контейнере, не несут условий согласия. Это намеренно. Собственные теги Google соблюдают Consent Mode; проверка согласия, добавленная вручную на тег Google без такой же на тегах событий GA4 под ним, — первая из двух ошибок ниже.

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

Либо ничего не ограничивайте вручную и дайте Consent Mode работать, либо ограничьте каждый тег, способный отправлять. Последовательной середины нет.

Некоторые менеджеры согласий работают, блокируя скрипты до получения согласия: они перехватывают теги script по URL и удерживают их. Их списки знают googletagmanager.com. Они не знают exxz2gdaz1jz.yoursite.com, потому что ничей список не мог бы: имя хоста и имя файла загрузчика уникальны для вашего контейнера. Так что в режиме блокировки загрузчик может быть пропущен безусловно, и если вы полагаетесь на блокировку, а не на Consent Mode, это тег, срабатывающий до согласия.

Два выхода. Добавьте URL загрузчика вручную в правила блокировки менеджера, в ту категорию, к которой относится ваша аналитика. Или — лучше, потому что это ещё и правильно обрабатывает пинг без cookie — положитесь на Consent Mode для тегов Google и используйте блокировку только для скриптов, которые его не поддерживают. Наш собственный сайт использует менеджер согласий в режиме автоблокировки вместе с Consent Mode; тег Google стоит после скрипта менеджера, и тест в репозитории падает, если кто-то меняет их порядок.

Состояние согласия приходит в серверный контейнер внутри каждого обращения, и серверный тег GA4 читает его так же, как браузерный. Ничто на нашей стороне не выдаёт и не расширяет согласие; пинг без cookie остаётся пингом без cookie.

Если вы подключите назначение Meta или TikTok, те же обращения питают и их. Должен ли отказ посетителя от маркетингового согласия останавливать эти пересылки — решение, которое выражает ваш менеджер согласий: категорией, в которой находится загрузчик, и тем, соблюдает ли ваша настройка ad_storage из Consent Mode. Проверьте это так же, как всё остальное здесь: откройте сайт с неотвеченным баннером, посмотрите вкладку сети и увидьте, что уходит.

• Скрипт менеджера согласий стоит на странице выше тега Google.
• Состояние согласия по умолчанию denied отправляется до загрузки тега, с wait_for_update.
• Ни у одного тега в контейнере нет добавленного вручную условия согласия — или оно есть у каждого тега, способного отправлять.
• При неотвеченном баннере вкладка сети показывает пинг без cookie (gcs=G100 в запросе) и ни одного полного обращения.
• После принятия та же страница показывает полное обращение, и страница контейнера его считает.
• Если менеджер блокирует по URL, URL загрузчика есть в его правилах.