Настройка Google Tag Manager и серверного тегирования (server-side GTM)

Уровень данных (dataLayer): основа надёжных тегов

Привязать теги к CSS-классу кнопки быстро, но ненадёжно. Стоит обновить тему или платформе интернет-магазина переименовать кнопку, и тег покупки молча перестаёт срабатывать. Поэтому мы согласуем с разработчиком документ по уровню данных (dataLayer): в нём прописано, какие поля передаются при каком событии, а теги привязываются к этим событиям.

На готовых платформах (Shopify, а также популярные в Турции IdeaSoft, Ticimax, T-Soft) часть уровня данных приходит с плагином или темой. Сначала мы проверяем поступающие данные в режиме предварительного просмотра и просим дополнить недостающие поля; особенно важно, чтобы идентификатор товара имел одно и то же значение в GA4, каталоге Meta и Merchant Center.

Аудит контейнера GTM: правила, которые держат его в порядке

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

• Система именования в формате «Платформа - Событие - Триггер», отдельная папка для каждой платформы
• Право публикации только у двух человек, остальным пользователям — права на редактирование
• Заметка к каждой версии с описанием того, что изменилось
• Подготовка изменений в отдельной рабочей области и отправка ссылки на предпросмотр на согласование
• Удаление тегов, оставшихся от Universal Analytics и уже не передающих данные
• Передача email и телефона в хешированном виде для расширенных конверсий Google Ads

Серверный GTM: когда нужно серверное тегирование

При серверной схеме браузер отправляет данные не напрямую в Google, Meta или TikTok, а в серверный контейнер на вашем поддомене (например, metrics.yourdomain.com). Сервер приводит данные в порядок, отсекает лишние поля и передаёт их нужным платформам. Стороннего кода в браузере становится меньше, и это положительно сказывается на скорости сайта, особенно на показателе INP.

Настройка Meta Conversions API через серверный контейнер усиливает сигнал о покупке, на котором обучаются кампании продаж Advantage+; для этого событие Pixel и серверное событие должны сопоставляться по одному event_id. Для Cloud Run Google рекомендует не менее двух экземпляров сервера, чтобы снизить риск потери данных, а сервер предварительного просмотра работает отдельно. Поскольку для настройки нужен проект Google Cloud, серверную схему мы рекомендуем сайтам с высоким трафиком, которые передают данные в несколько платформ.

Consent Mode v2 и баннер cookie в Google Tag Manager

В Consent Mode v2, помимо ad_storage и analytics_storage, есть сигналы ad_user_data и ad_personalization. Мы связываем выбор пользователя в баннере cookie с этими четырьмя сигналами и в режиме предпросмотра проверяем, что обновление согласия передаётся до смены страницы. Текст баннера и оценка на соответствие KVKK (закон Турции о защите персональных данных) остаются за вашим юристом; мы настраиваем техническую связку и следим за сигналом, который получают кампании вроде Performance Max.

Google Tag Manager: когда мы это рекомендуем?

Как мы ведём Google Tag Manager

1. Инвентаризация контейнераСоставляем список текущих тегов, триггеров и переменных и отмечаем, для чего каждый нужен.
2. Документ по уровню данныхВместе с разработчиком готовим документ с названиями событий и полями.
3. Чистка и переименованиеУдаляем неработающие теги и применяем систему именования.
4. Тест в предпросмотреПрогоняем каждый сценарий в Tag Assistant и сверяем результат с инструментами тестирования платформ.
5. Серверный контейнер (при необходимости)Запускаем Cloud Run, поддомен и теги платформ.

Google Tag Manager: метрики и требования

Команда аналитики The Brand Move

Чтобы узнать больше о «Google Tag Manager» и других услугах по аналитике, свяжитесь с командой The Brand Move по аналитике.

Связаться с нами