Новый Google Tag: что меняется в разметке данных

Новый Google Tag: что меняется в разметке данных

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

Чек-лист миграции и настройки:

— Провести аудит текущих контейнеров. Зафиксировать, какие события сейчас уходят в GTM, GA4, Google Ads и Optimize отдельно — это станет картой того, что должно переехать в новый тег.
— Зафиксировать единую схему событий. До миграции описать названия, параметры и типы данных (snake_case, формат значений). Без этого шага консолидация превратит хаос в консолидацию хаоса.
— Выбрать способ отправки. Server-side через Cloud Run или Cloudflare против client-side. Учитывать, что server-side снимает часть ограничений consent-режима, но требует DevOps-компетенции и не отменяет privacy-first атрибуцию.
— Настроить consent-экран как источник истины. Тег должен реагировать на согласие пользователя, а не наоборот. В эпоху server-side и MMM (маркетинг-микс-моделирование) это уже не юридическая формальность, а часть измерений.
— Перевести аудитории и конверсии в Ads. Проверить, что события GA4 корректно отображаются как конверсии в Google Ads без двойного срабатывания тега старого типа.
— Обновить QA-процедуру. Добавить регулярную проверку через Tag Assistant и DebugView, потому что одна общая точка отказа вместо нескольких изолированных — это и плюс, и риск.
— Задокументировать владельца схемы данных. В RevOps-подходе (объединение маркетинга, продаж и клиентского успеха ради выручки) за data schema отвечает конкретная роль, а не «все вместе».

Когда пригодится: при плановом переезде на server-side атрибуцию или при первых признаках расхождения данных между GA4 и рекламными кабинетами.

— @AItoolsMarketingRu