Google Tag Manager: зачем он на сайте и когда без него можно обойтись

На сайт ставится один фрагмент кода с идентификатором контейнера вида GTM-XXXXXX. Всё остальное живёт в кабинете tagmanager.google.com и состоит из трёх сущностей. Тег — это то, что нужно выполнить: код счётчика, пиксель рекламной сети, отправка события. Триггер — условие, при котором тег срабатывает: загрузилась страница, отправлена форма, клик по кнопке с определённым классом, прокрутка до 75 %. Переменная — значение, которое подставляется в тег: адрес страницы, текст кнопки, сумма заказа из dataLayer.

Ключевое удобство — публикация версиями. Вы правите теги в рабочей области, проверяете в режиме предпросмотра на своём сайте и только потом нажимаете «Опубликовать». Каждая публикация сохраняется, и к любой прошлой версии можно откатиться за минуту. Разработчик в этой схеме нужен один раз — вставить код контейнера, а дальше маркетолог меняет отслеживание сам.

Что GTM не делает: не хранит статистику, не строит отчёты, не заменяет Метрику или сквозную аналитику. Он лишь доставляет чужие скрипты на страницу по правилам. Отсюда практическое следствие: если у вас нет ни одного события, которое вы не можете настроить прямо в Метрике, контейнеру нечего доставлять.

GTM окупает свою сложность там, где отслеживание превращается в постоянную работу, а не разовую настройку. Проверьте сайт по признакам ниже — совпадение хотя бы двух из них уже серьёзный аргумент за контейнер.

Отдельно про интернет-магазины. Электронная коммерция в Метрике собирает данные о просмотрах товара, добавлении в корзину, оформлении заказа и покупке — и читает их из объекта dataLayer, того самого, с которым работает GTM. Когда разработчик один раз научил сайт складывать в dataLayer события с товарами и суммами, контейнер раздаёт эти данные и Метрике, и рекламным пикселям, и любому новому сервису без повторной доработки кода. Без GTM каждый новый получатель — отдельная задача программисту.

Типичный сайт услуг живёт с тремя-пятью целями: отправка формы, клик по телефону, переход в Telegram или WhatsApp, иногда — скачивание прайса. Метрика закрывает большую часть этого автоцелями: при включённой опции счётчик сам фиксирует клики по номеру и email, отправку форм, переходы в мессенджеры, скачивание файлов. Остаётся одна ручная цель на успешную отправку формы — её ставят либо через JavaScript-событие в коде формы, либо через цель на посещение страницы «спасибо». Ради одной цели поднимать контейнер, учётку Google и режим предпросмотра — несоразмерно.

Лендинг на конструкторе — вторая ситуация, где GTM чаще мешает. У конструкторов есть штатное поле для номера счётчика Метрики, а формы конструктора Метрика видит через автоцели. Добавить контейнер туда можно, но каждая проверка «почему не считается заявка» превращается в поиск по трём местам: настройки конструктора, контейнер, счётчик. При смене подрядчика по рекламе это регулярно заканчивается двумя счётчиками на одной странице и задвоенными визитами.

Общее правило простое: каждый промежуточный слой между сайтом и отчётом — это ещё одна точка, где может сломаться подсчёт заявок, и ещё один человек, которого нужно спросить «а что там настроено». Если слой не решает конкретную задачу из предыдущего раздела, его не должно быть.

Скрипт контейнера загружается с домена googletagmanager.com. Это значит, что работоспособность всего, что лежит внутри, зависит от того, доступен ли этот домен конкретному посетителю. У части пользователей он недоступен или грузится медленно: корпоративные сети с фильтрацией внешних доменов, блокировщики рекламы, у которых этот адрес есть в списках, нестабильный доступ к зарубежным серверам с мобильного интернета. Точную долю таких визитов вы узнаете только на своём трафике — сравнив число визитов в Метрике, поставленной напрямую, с числом срабатываний тега из контейнера.

Из этого вытекает главное правило подключения: код счётчика Метрики ставится в код сайта напрямую, в секцию head, а не тегом внутри GTM. Иначе при неудачной загрузке контейнера у пользователя вы теряете не только события, но и сам визит — и в отчётах появляется необъяснимый провал трафика, который потом ищут в рекламе. Внутри контейнера остаются события и сторонние теги, потеря которых для части визитов неприятна, но не искажает базовую картину.

Третий пункт — персональные данные. Контейнер сам по себе не отправляет в Google ничего, кроме факта загрузки, но каждый тег внутри него куда-то передаёт данные о посетителе. Если через GTM вы подключаете сервисы, которые обрабатывают данные за пределами России, состав передаваемого и формулировки в политике конфиденциальности стоит согласовать с юристом с оглядкой на 152-ФЗ. Мы на этой стороне даём перечень тегов и того, что каждый передаёт, — юридическую оценку делает ваш юрист.

И организационное: контейнер привязан к аккаунту Google. Если он создан на почте подрядчика, при расставании вы можете остаться без доступа к тому, что стреляет на вашем сайте. Контейнер создаётся на аккаунт компании, подрядчику выдаётся роль редактора или издателя, а не владельца.

Код GTM загружается асинхронно и сам по себе редко тормозит первую отрисовку. Проблема в содержимом. Контейнер, куда за два года накидали пиксели трёх рекламных систем, два чата, квиз и «на всякий случай» старый счётчик, выполняет всё это на главном потоке браузера при каждой загрузке страницы. Пользователь видит страницу, нажимает на кнопку — и ждёт, пока браузер закончит с тегами. Это ровно то, что измеряет INP. Если какой-то тег вставляет на страницу баннер или виджет выше первого экрана, сдвигается и LCP.

Лечится это гигиеной контейнера, а не отказом от него. Раз в квартал открывать список тегов и удалять всё, чем никто не пользуется: пиксели рекламных сетей, где кампании остановлены, тесты, которые завершились, дубли счётчиков. Тяжёлые виджеты — чат, обратный звонок, карту — вешать на триггер «окно загружено» или на первое взаимодействие пользователя, а не на «просмотр страницы». Пользовательские HTML-теги, которые тянут ещё один внешний скрипт, — проверять поштучно: часто у сервиса есть более лёгкий способ подключения.

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

Схема, к которой мы приходим на большинстве проектов, где контейнер оправдан, выглядит так. Счётчик Метрики стоит в head каждой страницы обычным кодом. Сайт при значимых действиях кладёт в dataLayer событие с понятным именем и параметрами: «form_sent» с названием формы, «quiz_finished» с числом шагов, «purchase» с суммой и составом заказа. GTM слушает эти события и раздаёт их получателям: в Метрику — вызовом достижения цели, в рекламные системы — их пикселями. Разработчик отвечает за то, чтобы события в dataLayer появлялись, маркетолог — за то, куда они уходят.

Смысл в разделении ответственности. Названия событий фиксируются в одном документе на проект, и когда меняется подрядчик по рекламе, он получает готовый словарь событий, а не разбирает чужие триггеры на классах кнопок, которые сломаются при первой правке вёрстки. Триггеры «по клику на элемент с таким-то CSS-классом» мы используем только как временную меру — до того, как разработчик добавит нормальное событие.

Если контейнер не нужен, та же логика работает без него. Сайт при отправке формы вызывает функцию ym с идентификатором счётчика и командой reachGoal, интернет-магазин кладёт данные о покупке в dataLayer, откуда их читает электронная коммерция Метрики без всякого GTM. Пиксель для одной рекламной сети вставляется в код напрямую. Для проекта с одним подрядчиком и стабильным набором событий это меньше слоёв и меньше точек отказа. Кто-то предпочитает тег-менеджеры, которые размещаются на собственном сервере, — они снимают вопрос доступности зарубежного домена, но требуют администрирования, и для малого бизнеса это редко оправдано.

Прежде чем решать «ставить или нет», выясните, что уже стоит: за годы жизни сайта на нём часто оказывается и контейнер, и пара счётчиков, о которых никто не помнит. Откройте исходный код любой страницы через «Просмотр кода страницы» и поищите по строкам «googletagmanager», «GTM-» и «mc.yandex». Найдётся идентификатор контейнера — значит, GTM есть, и первый вопрос: у кого доступ к этому аккаунту. Два разных номера счётчика Метрики — сигнал к разбору, какой из них смотрят в отчётах.

Второй инструмент — расширения браузера, которые показывают, какие теги загрузились на странице; официальное от Google называется Tag Assistant. Оно покажет и контейнер, и что стреляет внутри него. Для Метрики есть свой отладочный режим: добавьте к адресу страницы параметр _ym_debug=1, откройте консоль браузера — и увидите, какие цели и параметры счётчик отправляет при ваших действиях на странице.

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

На созвоне по настройке аналитики мы начинаем именно с этой ревизии, потому что половина запросов «поставьте нам GTM» после неё превращается в «наведите порядок в том, что есть». Если контейнер оправдан — переносим его на аккаунт компании, чистим от мёртвых тегов и переводим на схему из предыдущего раздела.