Три триггера, которые “врут” в GTM (и как я их чиню под privacy-first атрибуцию)

Три триггера, которые “врут” в GTM (и как я их чиню под privacy-first атрибуцию)

В 2026 я всё чаще вижу одну и ту же проблему: в аккаунте GTM трафик и события вроде бы есть, но бизнес-решения принимают на основании данных, которые уже не отражают реальность. Причина редко в “неправильных тегах”. Чаще — в логике триггеров: они срабатывают не там, где вы думаете, или срабатывают так, что атрибуция искажает картину.

Я выделяю три класса “лживых” триггеров — и всегда чиню их по одной методике: сначала доказываю, где именно происходят события, затем калибрую условия с учётом блокировок и неполноты идентификаторов.

1) Триггер “Page View” по DOM-событиям (и почему он даёт двойные загрузки)
Самый распространённый сценарий — SPA или многостраничность, где я видел Page View, который пытались “улучшить” триггером на DOM Ready / History Change / Custom event. В итоге:
— часть переходов получает один Page View, часть — два
— в отчетности это выглядит как рост посещаемости или ухудшение глубины
— а в performance-моделях (и тем более при server-side подходе) это начинает “съедать” инкрементальность

Как я чиню:
— оставляю Page View максимально детерминированным: один источник истины (обычно — изменение URL/route через родной событийный слой сайта, но с жестким антидубликатом)
— добавляю антидубликат на уровне dataLayer (например, хеш текущего route + timestamp/счетчик)
— валидирую не на Preview, а на реальных сессиях: смотрю, совпадают ли связки `page_location` → `event_timestamp` и нет ли повторов в пределах X секунд

Наблюдение из практики: чаще всего двойные Page View появляются не у всех пользователей, а у сегмента с более медленной загрузкой/нестабильным JS. Там Preview “чистый”, а в проде — нет.

2) Триггеры на Form Submit через “CSS selector”
Я понимаю логику: взять кнопку Submit по селектору, и всё. Но в реальности:
— меняются классы фронтенда (A/B или просто рефактор)
— появляется “декоративная” кнопка, которая отправку не инициирует
— а submit ловится раньше, чем формируется финальный payload (например, до валидации)

В результате часть форм:
— отправляется, но событие не логируется
— или логируется с неполными параметрами (и потом вы не можете разложить лиды по типам)
— или вообще ловит “попытку отправки” без факта

Как я чиню:
— перехватываю событие на уровне факта отправки: success callback, завершение network-запроса (или конечный state в dataLayer, который ставит бек/сервер)
— если это невозможно — делаю связку: “видимость формы + заполнение минимум N полей + клик + подтверждение загрузки/ошибки”
— обязательно прокидываю идентификатор сессии/формы, чтобы не смешивать повторные попытки

Мини-цифра: в одном e-commerce проекте у нас “submit по selector” давал расхождение с backend-логами порядка 8–12% по отправкам. После перехода на подтверждение факта (через конечный state) разрыв ушел почти в ноль — это сразу стабилизировало MQL/SQL-логику и отчётность для RevOps.

3) Триггеры на Consent (CMP) без режима “replay”
Consent Mode и CMP — это не просто галочка “разрешено/запрещено”. В privacy-first мире у пользователя может:
— быть отказ на старте, затем согласие после прокрутки/действия
— очиститься хранилища, смениться домен/вкладка
— поменяться доступность идентификатора (client id/псевдоидентификаторы)

Если триггер на нужные теги завязан только на “consent granted в момент page load”, вы получаете ситуацию: событие в dataLayer может происходить, но трекер уже не может его отправить, и вы теряете конверсию без возможности догнать.

Как я чиню:
— разделяю “сбор события в dataLayer” и “отправку наружу” (только когда consent соответствует)
— делаю replay: храню ключевые события (минимум — конверсионные) до момента разрешения и отправляю один раз при подходящих условиях
— валидирую сценарии: отказ → согласие и согласие → отказ (да, бывает и так)
…