GTM ломается не в контейнере, а в логике триггеров и переменных

GTM ломается не в контейнере, а в логике триггеров и переменных

Чаще всего проблемы в GTM выглядят как «тег не сработал», но корень другой: переменная пустая, триггер слишком широкий, а данные в dataLayer приходят не в том порядке. Поэтому проверять нужно не только сам тег, а всю цепочку: событие → переменные → условия → отправка.

Что проверять в первую очередь:
— dataLayer.push действительно происходит до срабатывания триггера
— в переменной нет undefined, null и пустых строк там, где нужен конкретный value
— триггер не ловит лишние страницы, клики и формы
— одинаковые события не отправляются дважды через разные теги

Отдельная зона риска — согласованность имён. Если в одном месте пишете ecommerce.purchase, а в другом purchase_complete, отладка превращается в поиск фантома. Для GTM это разные сущности, даже если бизнес-логика одна.

Ещё один частый баг — привязка тега к Page View там, где нужен Custom Event. Визуально всё работает, но данные нестабильны: на быстрых страницах, SPA и ленивой загрузке часть событий просто теряется. Лучше один раз зафиксировать архитектуру событий, чем потом чинить аналитику по кускам.

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