Почему я перестал доверять «срабатыванию тега» как доказательству качества аналитики

Почему я перестал доверять «срабатыванию тега» как доказательству качества аналитики

В GTM есть опасная иллюзия: если тег fired — значит, всё измерение работает. На практике это часто не так. Я вижу одну и ту же ошибку у сильных маркетинг-команд: они проверяют факт отправки события, но не проверяют, дошло ли оно до системы, в каком виде и можно ли этому событию вообще доверять.

Мой главный тезис простой: **в 2026 году тег — это не доказательство, а только начало проверки**. В privacy-first среде, где сервер-сайд (server-side) и модели атрибуции постепенно вытесняют last-click, цена «почти корректной» аналитики становится слишком высокой. Неправильно собранное событие потом влияет и на оптимизацию кампаний, и на отчёты по выручке, и на решения по бюджету.

Из практики: на одном B2B-проекте мы нашли расхождение в 14% между отправкой события и его фактическим попаданием в аналитику. Причина была не в «поломанном GTM», а в цепочке вокруг него: дублирование триггера, потери на Consent Mode, и нестабильная передача параметра client_id. Формально всё выглядело рабочим. По факту — часть конверсий жила в тени.

Я теперь проверяю любой критичный тег по трём уровням:
— сработал ли триггер в GTM;
— ушёл ли запрос и получил ли он корректный ответ;
— совпадают ли параметры события с тем, что ждёт аналитика, CRM или рекламная платформа.

Если хотя бы один уровень не сходится, я не считаю событие надёжным. Это особенно важно сейчас, когда маркетинг всё чаще отвечает не за «лиды ради лидов», а за RevOps-результат: общую выручку, качество pipeline и сохранение LTV.

Мой совет простой: перестаньте спрашивать «тег сработал?». Спрашивайте «можно ли на этом событии принимать решение?». В GTM это намного более полезный вопрос.

— @GTMrecipesRuPro