Что такое Google Tag Manager и почему не всегда нужно ждать разработчика
Отдел маркетинга запускает новую кампанию — скажем, рекламу в Facebook с оптимизацией на конверсии. Чтобы реклама заработала, на сайте нужно небольшое изменение: когда посетитель нажимает кнопку «Оформить заказ», в Facebook должен уйти сигнал. Мелочь на одну строку кода — но кто меняет код сайта? Разработчик. А он в этот момент занят другой задачей и говорит «посмотрю через пару дней» — кампания же уже запущена. Данные первых трёх дней не вернутся никогда, потому что в эти дни ничего не измерялось.
Это не единичный случай. Новый пиксель Instagram, отдельный сигнал «форма отправлена», код конверсии для TikTok, метка для отдельного списка ремаркетинга — каждый попадает в ту же очередь: маркетинг ждёт, разработчик занят другим, а изменение, даже маленькое, оказывается в конце списка приоритетов. Google Tag Manager (GTM) не убирает эту очередь полностью, но меняет, кто ею управляет — а настроенный небрежно, создаёт взамен другую проблему.
Что именно делает Google Tag Manager
GTM работает по простому принципу: на сайт один раз ставится один фрагмент кода — «контейнер». После этого каждый новый код для измерения или маркетинга живёт уже не в коде сайта, а в веб-интерфейсе GTM. Согласно собственному объяснению Google, система строится на трёх элементах: тегах (любой код стороннего сервиса, например пиксель Facebook), триггерах (условие, при котором тег срабатывает, например «нажата кнопка») и переменных (данные, которые использует тег, — адрес страницы или сумма заказа). Добавить новый пиксель — это уже не писать код, а заполнить три поля в панели GTM.
Контейнер нужен на сайте только один — это подтверждают сами документы Google: не отдельный контейнер на каждую страницу, а один на весь домен сайта. Это сводит работу разработчика к одной небольшой задаче: разместить код контейнера один раз. Каждое следующее изменение уже не требует нового деплоя.
В итоге разработчик один раз устанавливает контейнер, а дальше маркетинг сам управляет своими инструментами — аналитикой, рекламными пикселями, сигналами ремаркетинга — без участия разработчика.
Разработчик остаётся совсем в стороне? Нет — для этого есть уровни доступа
Это не значит, что разработчик теряет контроль полностью, хотя воспринимается часто именно так. Система прав доступа GTM делится на пять уровней: без доступа, только чтение, редактирование, подтверждение и публикация. Разработчик может оставить за собой право «подтверждения» — маркетинг вносит и тестирует любые изменения в контейнере, но на живой сайт они выходят только после его одобрения. Скорость растёт, контроль не теряется — просто становится ясно, кто за что отвечает.
Как безопасно добавить новый тег — четыре шага
- Создать в рабочей области. Маркетинг добавляет новый тег, триггер и переменную в своём рабочем пространстве (workspace). Пока это никак не влияет на живой сайт.
- Проверить в режиме предпросмотра. Согласно инструменту предпросмотра GTM, сайт открывается так, будто новая версия уже опубликована, — но для реальных посетителей ничего не меняется. На экране видно, какой тег сработал, в каком порядке и какие данные передал.
- Поделиться результатом.
Влияние на скорость — что на самом деле значит небрежное использование
Здесь есть реальный риск, и он отличается от расхожего мнения «GTM тормозит сайт» — проблема не в самом инструменте, а в том, сколько всего накопилось в контейнере и как это настроено. Согласно собственному руководству Google по производительности, теги накапливаются со временем, потому что их добавляют, но редко удаляют — по отдельности каждый выглядит незначительным, но когда на одной странице их собираются десятки или сотни, нагрузка на пропускную способность и процессор становится ощутимой. Тот же источник отдельно предупреждает: теги типа custom HTML несут наибольший риск, потому что добавляют на страницу произвольный JavaScript; простые пиксельные теги остаются лёгкими.
На практике это выглядит так: кто-то добавляет временный код отслеживания под одну кампанию, кампания заканчивается, код не удаляют. Через полгода в контейнере лежат пятнадцать таких «забытых» тегов, все срабатывают сразу при открытии страницы, и сайт, который когда-то грузился быстро, теперь заметно медленнее показывает первый экран. Рекомендация Google конкретна: теги, без которых можно подождать, переносить на триггер «Window Loaded» (после полной загрузки страницы), чтобы они не мешали первой отрисовке, и регулярно проверять контейнер, удаляя неиспользуемые теги.
Как это связано с GA4
GTM сам по себе не инструмент измерения — это трубопровод, который его доставляет. Самый частый сценарий такой: базовый код GA4 один раз ставится в контейнер, а затем каждое новое «событие» — заказ оформлен, форма отправлена, видео досмотрено — отправляется в GA4 отдельным тегом через GTM, без единого прикосновения к коду сайта. Настроить эту связку небрежно — и вместо удобства получаются тихие ошибки: событие считается дважды или не доходит вовсе, потому что никакого сообщения об ошибке не появляется — в отчёте просто нет цифры.
Самая частая ошибка выглядит так: когда-то разработчик поставил код GA4 прямо в код сайта, а позже кто-то подключил тот же аккаунт GA4 ещё и через GTM, забыв убрать старый код. В результате каждый просмотр страницы, каждый заказ попадает в отчёт дважды — конверсий насчитывается больше, чем реальных продаж, эффективность рекламы выглядит завышенной, и никто не ищет причину, потому что цифра кажется хорошей. Проверить это несложно: если в сетевой панели браузера на одно и то же событие уходит два одинаковых запроса, значит, есть дублирование.
Каждый новый тег в контейнере выглядит бесплатным — счёт за него оплачивает скорость.
Если на сайте годами копились теги и непонятно, сколько из них ещё вообще работает, гадать не нужно — наш бесплатный инструмент проверки скорости показывает реальные показатели загрузки страницы. А начиная с самого контейнера, наша услуга настройки инфраструктуры измерения связывает GTM и GA4 так, чтобы маркетинг мог работать свободно, не забирая скорость у сайта.
