GA4: как я перестал «верить» в отчёты и начал лечить путь пользователя по шагам
Я много раз видел одну и ту же схему: в GA4 смотрят на воронку или cohort, а потом удивляются, что эффективность «падает» или «вылезают» странные сегменты. Мой вывод после серии внедрений в B2B и e-com: проблема почти всегда не в маркетинге и не в трафике, а в том, что GA4 показывает измерения, которые мы сами не довели до рабочего состояния. Поэтому я веду работу не с отчётов, а с каркаса событий и реконструкции пути пользователя.
Рецепт “Диагностика пути” (занимает 2–3 часа, если матрица событий уже есть)
1) Зафиксируйте “корень правды”: ключевой user journey-узел
Вместо “конверсия есть/нет” я выбираю один узел, который отражает ценность:
— e-com: first purchase / add to cart с валидным item_id (или purchase, если уже зрелая интеграция)
— B2B: qualified lead не как «форма отправлена», а как событие с признаками качества (например, заполнены поля, есть account context, есть согласие на обработку)
Если узел расплывчатый — дальше вы будете чинить симптомы.
2) Проверьте, что события не “переизмеряются”
Самая частая ошибка: одно и то же событие приходит разными путями (разные названия, разные параметры, дубликаты из-за двух тегов/двух источников).
Я делаю простую проверку: в DebugView/Realtime сопоставляю цепочку “действие → параметры → отправка”. Если в одном сценарии purchase приходит и через app stream, и через web stream, данные будут конфликтовать, а атрибуция — «плыть».
3) Соберите “минимальный набор параметров”, без которого GA4 не построит устойчивую картину
Я придерживаюсь правила: для ключевых событий должны быть хотя бы
— идентификатор объекта (item_id / lead_id / deal_id или их прокси)
— источник контекста (campaign/source/medium — в терминах вашей схемы)
— признак качества (например, флаг согласий, наличие заполненных обязательных полей)
На практике один клиент в e-com год жил с purchase без нормального item_id — retention и LTV в разрезах были “плавающими”. После восстановления item_id картина стала стабильной уже в течение одной недели.
4) Перестаньте думать про last click — переключитесь на “структуру касаний”
В 2026 я ожидаю меньше доверия к last-click: privacy-first атрибуция и server-side (а ещё MMM и incrementality) заставляют маркетинг отвечать за выручку вместе, а не спорить “кто победил в последнем переходе”.
Поэтому я строю проверку так: беру сегменты пользователей по первому значимому действию и смотрю, как ведут себя дальше. Это похоже на “когортную” логику, но руками и по чётким узлам — чтобы исключить эффекты мусора в событиях.
5) Приземлите в ревенью-метрики: что вы делаете с наблюдением
Если вы нашли, что путь ломается на шаге “конверсия выглядит, но качество не то” — значит, вам нужен не ещё один отчёт, а правка условий события/валидации параметров и согласование с продажами и customer success (в логике RevOps).
Часто это быстро окупается: у нас был кейс, где после уточнения параметров квалификации доля MQL с реальным SQL выросла, а стоимость привлечения «по ощущениям» перестала расти. То есть маркетинг перестал финансировать не то качество.
Моё главное мнение: GA4 — это не витрина, а конструктор. Воронки и когортные отчёты красивы, но работают только на чистой модели событий. Начните с шага 1–3 — и вы перестанете бороться с призраками в статистике.
— @GA4cookbookRuPro
GA4 cookbook — рецепты
@GA4cookbookRuPro
GA4: как я перестал «верить» в отчёты и начал лечить путь пользователя по шагам
Этот пост опубликован в Telegram-канале GA4 cookbook — рецепты. Подписаться можно по ссылке: @GA4cookbookRuPro.