GA4 не умер. Но в 2026 я всё чаще ставлю его не в центр, а на периферию стека
Я вижу одну и ту же ошибку у B2B и e-com команд: они покупают GA4 как «главную правду о пользователе», а потом удивляются, почему отчёты не сходятся с CRM, серверными событиями и данными retention-аналитики. Проблема не в GA4 как таковом. Проблема в том, что он заточен под массовую веб-аналитику и дешёвый охват, а не под управление выручкой.
В моей практике за последний год почти в каждом зрелом проекте схема была одинаковой:
— GA4 оставляли как слой для базовой медиамапы, отчётности по трафику и дешёвых срезов;
— Amplitude или Mixpanel брали на продуктовые сценарии, когорты, удержание и поведение по событиям;
— Heap подключали там, где нужна быстрая сборка событий без долгого ТЗ;
— а финальную бизнес-логику всё равно сводили в RevOps-контур: CRM, BI, серверные события, маржа, LTV.
**Мой вывод простой: GA4 хорош там, где нужен масштаб, но не хватает глубины.** Он полезен для верхнего слоя воронки, но ломается, когда маркетинг начинает отвечать не за клики, а за выручку. В эпоху privacy-first атрибуции last-click уже не может быть единственным «судьёй», а GA4 сам по себе это не компенсирует.
Один показательный пример: у клиента с B2B-воронкой расхождение между GA4 и CRM по квалифицированным лидам было около 28%. Не из-за «плохой настройки», а из-за реальности: часть касаний шла через сервер, часть — через офлайн-события, часть — через длинный цикл сделки. После сборки связки GA4 + Amplitude + BI команда перестала спорить о цифрах и начала спорить о решениях. И это, на мой взгляд, правильный этап зрелости.
Если упростить: GA4 — не ядро аналитики, а её входная дверь. Я бы не строил на нём стратегию. Я бы строил на нём только первый уровень наблюдения, а стратегию — на событии, выручке и удержании.
— @AnalyticsStackRu
Стек аналитики — обзоры
@AnalyticsStackRu
GA4 не умер. Но в 2026 я всё чаще ставлю его не в центр, а на периферию стека
Этот пост опубликован в Telegram-канале Стек аналитики — обзоры. Подписаться можно по ссылке: @AnalyticsStackRu.