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

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

Чаще всего проблема не в «не срабатывает тег», а в том, что:
— триггер слишком широкий и ловит лишние события;
— переменная читается до того, как данные попали в dataLayer;
— один и тот же тег стреляет дважды из-за нескольких условий.

В GTM сначала проверяй цепочку: событие в dataLayer → переменная → триггер → тег. Если на любом шаге есть неопределённость, дебаг превращается в угадайку. Для старта полезно смотреть не только Preview, но и сам поток событий в dataLayer, чтобы понять, что реально пришло на страницу.

Ещё одна типовая ошибка — смешивать бизнес-логику и технический скоуп. Например, один тег пытаются повесить на все клики, а потом фильтровать их внутри условиями. Надёжнее сузить триггер заранее: по CSS-селектору, по URL, по custom event, по конкретному значению переменной. Это уменьшает шум и ускоряет отладку.

Что делать на практике: держи отдельный список критичных тегов, проверяй их на дубли, а для каждого кастомного события фиксируй 3 вещи — имя события, состав payload и точный триггер. Если эти три точки совпадают, GTM ведёт себя предсказуемо.

Хороший контейнер — это не тот, где много тегов, а тот, где каждый тег можно объяснить одной строкой.