Сообщить об ошибкеКороткий ответ
Основные подозреваемые: триггер построен на клике по CSS-классу/ID, который используется не только на нужной кнопке, но ещё где-то (ложные срабатывания в других местах не относятся к этой проблеме) или, наоборот, на части страниц другой вариант верстки/AB-теста использует другой класс для той же кнопки; также возможна гонка условий (race condition), когда переход на следующую страницу происходит быстрее, чем GTM успевает отправить тег.
Как это работает подробнее
Клик-триггеры в GTM по умолчанию срабатывают асинхронно, и если после клика сайт сразу переходит на новую страницу (navigation), запрос тега может быть прерван браузером до завершения отправки; кроме того, если на сайте идёт A/B-тест интерфейса или разные шаблоны для разных сегментов пользователей, кнопка может иметь разную верстку/атрибуты, из-за чего триггер срабатывает не во всех вариантах.
Что использовать на практике
- Практика. Диагностику стоит вести через анализ: сначала проверить, не совпадает ли процент несработавших тегов с долей пользователей в определённом варианте A/B-теста или типе устройства/браузера; затем проверить, использует ли GTM механизм задержки перехода (например, через встроенную настройку "wait for tags" или кастомный код задержки) для триггеров, связанных с переходом на новую страницу.
Подводные камни
- Риск ошибки. Частая ошибка — сразу считать проблему «случайным шумом сети» без количественной проверки, действительно ли несработавшие случаи равномерно распределены, или они концентрируются в конкретном сегменте (конкретный браузер, вариант теста, тип устройства), что указывает на системную, а не случайную причину.Частая ошибка — не использовать встроенные в GTM настройки «Wait for Tags» (ожидание завершения отправки тега перед переходом на новую страницу) и «Tag Sequencing» для триггеров, связанных с навигацией — без них клик-триггеры на кнопках, ведущих на новую страницу, систематически теряют часть срабатываний на медленных сетях.