GA4 как «конструктор блюда»: почему вы теряете конверсию между событиями и воронками

GA4 как «конструктор блюда»: почему вы теряете конверсию между событиями и воронками

Когда я вижу отчёты в GA4, где «конверсия в целевое событие» вроде бы есть, но бизнеса она не оправдывает, я почти всегда начинаю не с дашборда, а с кухни: с того, как данные превращаются в события, и как эти события начинают вести себя в анализе.

Мой главный тезис: проблема не в том, что GA4 “плохо считает”. Проблема в том, что команда часто строит воронку и атрибуцию поверх несогласованных слоёв — событий, пользовательских свойств и покупательных/лидовых статусов — и в итоге получает “конверсию, которая не соответствует рецепту”. В 2026 это особенно заметно на фоне server-side (серверной доставки) и privacy-first атрибуции: вы можете улучшить качество сбора, но аналитика останется прежней, если логика событий не выстроена.

Рецепт (step-by-step), как я проверяю связность GA4 и воронок:

1) Зафиксируйте «истину» события
Откройте события, на которые вы опираетесь в воронке (например, add_to_cart → begin_checkout → purchase или lead_submit). Выпишите: какие параметры вы ожидаете стабильно (id товара, тип формы, источник лида, валюта/выручка). Если хотя бы один ключевой параметр “плавает” (то приходит, то нет), воронка будет “распадаться” на уровне сегментации.

2) Проверьте согласование user-идентификаторов
GA4 умеет сводить поведение пользователя, но только если у вас корректно настроены связки: User-ID (если вы используете), согласованные Client ID, отсутствие дублей при миграции. В практике я видел ситуацию: после внедрения серверного тегирования доля уникальных пользователей “скакнула”, а воронка по пользователям — нет. Это прямой симптом, что вы меряете “разные сущности” в разных отчётах.

3) Настройте один источник правды для статусов
Если вы строите SQL-подобную логику руками (“лид квалифицирован, когда…”) — остановитесь и закрепите статусы через события или через единообразные параметры. Иначе вы получите картинку, где воронка по событиям говорит одно, а CRM/RevOps (общая ответственность маркетинга, sales и customer success за выручку) — другое. В 2026 это критично: классическая lead-генерация через MQL/SQL всё чаще уступает моделям по выручке и удержанию, и расхождения в статусах становятся финансовыми ошибками, а не “аналитическими”.

4) Проверьте инкрементность изменений как мини-перфоманс
Даже без A/B: сделайте “канарейку” на сегмент аудитории/путь страницы. На моей практике самый быстрый тест — сравнить конверсию по одному шагу воронки “до/после” в одном и том же сегменте пользователей в пределах контрольного окна и убедиться, что изменение не ломает предыдущие шаги. Если покупка выросла, но begin_checkout упал — значит вы починили трекинг, но сломали интерпретацию событий (или наоборот).

Один практический ориентир, который я держу как соль блюда: если разница между шагами воронки (например, begin_checkout → purchase) увеличилась после релиза тегов, но общее количество пользователей в сегменте осталось сопоставимым — почти всегда проблема в параметрах/условиях построения, а не в поведении аудитории.

Итого моё мнение: GA4 воронки — это не графики “куда нажимали”, а контракт вашей аналитической кухни. Если события не договорились между собой (параметры, идентификаторы, статусы), вы не почините проблему “красивым” дашбордом. Почините рецепт: от события к статусу, от статуса к воронке, и только потом — к атрибуции и экономике.

— @GA4cookbookRuPro