Смерть атрибуции по последнему клику и почему RevOps диктует выбор стека

В эпоху, когда классическая модель сбора лидов (MQL - квалифицированные маркетингом лиды) отходит на второй план, уступая место RevOps (системе управления выручкой), требования к инструментам аналитики фундаментально изменились. Больше нельзя просто «отслеживать путь» пользователя до нажатия кнопки «Купить». Сегодня мы строим системы, которые должны объяснять, как маркетинговый контент, созданный AI (искусственным интеллектом), превращается в долгосрочный LTV (пожизненную ценность клиента).

Выбор основного инструмента — GA4, Amplitude, Mixpanel или Heap — перестал быть вопросом «удобства дашбордов». Это вопрос архитектуры данных вашей компании в 2026 году.

— GA4 остается базовым стандартом для оценки общего трафика и работы с AI-обзорами поисковых систем. Однако, полагаться на него как на единственный источник правды в B2B или сложном E-com — стратегическая ошибка. Он по-прежнему «заточен» под охват, а не под глубину взаимодействия.

— Amplitude и Mixpanel выигрывают там, где продукт требует детального анализа поведения внутри интерфейса. В эпоху «нулевого клика», когда пользователь получает ответ на свой вопрос прямо в поисковой выдаче и не переходит на сайт, именно события (events) внутри вашего приложения становятся единственным способом понять, что клиент «созрел».

— Heap привлекает автоматическим захватом данных. Это спасение для команд, где нет ресурсов на настройку каждого чиха в Google Tag Manager, но критически важно видеть весь путь клиента целиком, не теряя контекст из-за ошибок в разметке.

Мое наблюдение из практики последних месяцев: компании, которые пытаются усидеть на двух стульях — сохраняя legacy-подход (традиционный подход) с last-click (атрибуцией по последнему клику) и одновременно внедряя RevOps — теряют до 30% эффективности рекламных бюджетов. Они просто не видят реального вклада верхнеуровневого контента, который формирует ту самую Topical Authority (тематический авторитет), необходимую для ранжирования в новой системе поиска.

*Главный вывод прост: если ваш стек аналитики не позволяет связать активность клиента с его ценностью для выручки через 6-12 месяцев, вы меряете не бизнес, вы меряете суету.*

Сейчас время переходить на server-side (серверную) передачу данных и внедрять MMM (моделирование маркетингового микса). Аналитика сегодня — это не про «откуда пришел», а про то, как каждый контакт с брендом меняет вероятность сделки. Выбирайте инструмент, который умеет объединять данные из CRM, продуктовой аналитики и рекламных площадок в единую модель данных, иначе вы продолжите оптимизировать кампании, которые не приносят денег.

Эра «смерти» атрибуции: почему инструментарий важнее метрик

Мы окончательно перешли в эпоху, где классическая модель атрибуции по последнему клику (last-click) стала музейным экспонатом. В 2026 году бизнес перестал верить в то, что один рекламный баннер «закрывает» сделку. В условиях RevOps (объединенной системы управления выручкой) мы видим, как фокус смещается с отслеживания пути пользователя на управление прибыльностью всей воронки.

Многие до сих пор выбирают стек аналитики, исходя из привычного удобства GA4, но в текущем ландшафте этого недостаточно. Когда информационный поиск в поисковиках уступает место ответам нейросетей, привычные каналы привлечения размываются.

Сравним подходы:

— GA4 остается стандартом для веба, но из-за жестких требований к приватности (privacy-first) данные становятся неполными. Это база для медийных кампаний, но не для принятия стратегических решений по продукту.
— Amplitude и Mixpanel — выбор тех, кто строит LTV (пожизненную ценность клиента) через глубокое изучение поведения внутри приложения. В условиях снижения среднего чека в электронной коммерции, способность этих систем подсветить «узкие места» в удержании пользователей становится критической.
— Heap выигрывает за счет автоматического сбора данных. В эпоху, когда скорость проверки гипотез определяет выживаемость продукта, возможность не настраивать каждое событие вручную экономит недели работы аналитиков.

Мое наблюдение из практики: компании, которые перешли от измерения «эффективности клика» к моделированию маркетингового микса (MMM) и инкрементальности (оценке прироста продаж благодаря рекламе), показывают на 12–15% более высокую маржинальность. Они перестали сжигать бюджеты на «горячие» ключи, которые и так конвертируются, и начали вкладываться в формирование узнаваемости бренда через контент, создающий авторитет в теме.

Выбор между этими инструментами больше не вопрос того, «кто лучше считает конверсии». Это вопрос того, как вы собираетесь управлять выручкой. Если ваш основной фокус — удержание и рост LTV, ваш стек обязан уметь работать с когортным анализом и событиями внутри продукта. Если же вы все еще пытаетесь «догнать» пользователя ретаргетингом на основе одного клика, вы проигрываете конкуренцию за внимание в Zero-click (эпохе без переходов).

Инструмент — это лишь зеркало вашей стратегии. Если стратегия строится на устаревших метриках, даже самый дорогой стек аналитики будет лишь красиво визуализировать ваше падение.

North Star Metric: как выбрать главную метрику продукта

North Star Metric, или «северная звезда», — это одна ключевая метрика, которая лучше других показывает, создаёт ли продукт ценность для пользователя и для бизнеса одновременно. Она не заменяет все остальные показатели, а задаёт фокус: команда понимает, ради какого результата работает.

Важно отличать её от KPI (ключевых показателей эффективности). KPI измеряют выполнение задач конкретной функции: маркетинг — стоимость лида, продажи — конверсию, продукт — активацию. North Star Metric шире: она должна быть связана с ценностью и с долгосрочным ростом, а не только с отчётностью по отделам. В 2026 году это особенно важно в B2B, где классическая воронка MQL/SQL всё чаще уступает месту RevOps и общей ответственности за выручку.

Типичные ошибки:
— выбирать метрику-результат, на которую команда не влияет напрямую;
— путать её с vanity metric, красивым, но пустым числом;
— делать North Star слишком абстрактной: «рост бренда» без операционного измерения;
— менять её каждый квартал, ломая фокус.

Пример: для B2B-SaaS North Star Metric может быть не «количество регистраций», а «число активных команд, которые еженедельно используют ключевую функцию». Это ближе к реальной ценности, чем верхнеуровневый трафик или лиды.

Как Nike собрал единый аналитический стек для DTC-роста: от GA4 до Amplitude

В 2026 году бренды уже не могут жить на одном last-click: трафик дорожает, AI-overviews забирают часть кликов, а в e-com важнее удержание и LTV, чем первая покупка. На этом фоне показателен кейс Nike с развитием direct-to-consumer (DTC) — продаж напрямую через сайт и приложение.

Контекст был такой: у Nike росли каналы, продуктовые команды выпускали новые сценарии в приложении, а маркетинг хотел понимать не только «откуда пришёл визит», но и **что человек сделал после первого касания**. Классическая веб-аналитика закрывала верх воронки, но плохо отвечала на вопросы про повторные покупки, вовлечение и вклад контента в выручку.

Задача звучала просто, но на практике была сложной:
— собрать единую картину поведения между сайтом и приложением;
— связать маркетинг, продукт и продажи через общие события;
— уйти от отчётов вида «визиты/сеансы» к метрикам активации, удержания и LTV;
— сделать так, чтобы команда могла быстро проверять гипотезы без тяжёлой аналитической разработки.

Решение строили в несколько слоёв. Для базовой цифровой аналитики оставили GA4 — как источник по трафику, кампаниям и общему пути пользователя. Но для поведенческой глубины подключили Amplitude: там стали собирать события уровня «просмотрел коллекцию», «добавил в избранное», «вернулся за 7 дней», «дошёл до покупки». Именно в Amplitude удобно строить когорты, воронки и удержание по сегментам, а не по усреднённому трафику.

Дополнительно Nike опирался на server-side (серверную) отправку части событий, чтобы меньше зависеть от ограничений браузеров и потерь данных. Это особенно важно в эпоху privacy-first, когда атрибуция всё чаще строится не на одном источнике, а на связке нескольких.

Что дало это на выходе:
— маркетинг увидел, какие кампании приводят не просто клики, а пользователей с более высоким повторным визитом;
— продукт получил быстрые ответы по точкам оттока в приложении;
— команда смогла сравнивать сегменты по LTV, а не только по CPA;
— обсуждение из формата «какой канал дешевле» перешло в «какой канал приводит более ценных клиентов».

**Главный урок:** в 2026 году сильный analytics stack — это не один «лучший» инструмент, а связка. GA4 отвечает за охват и каналы, Amplitude — за поведение и удержание, а серверная передача данных снижает потери в измерениях. Если бренд строит DTC-модель, выигрывает тот, кто измеряет не визит, а путь к выручке.

Amplitude, GA4 или Mixpanel: миф про «единую правду»

Миф: если выбрать один продукт (например, Amplitude вместо GA4 или наоборот), можно получить «единую правду» по поведению пользователей и перестать спорить с цифрами.

Откуда он берётся: привычка сравнивать интерфейсы. Люди видят похожие графики (воронки, удержание, когорты) и делают вывод, что источник данных один, логика одинаковая, а расхождения — это лишь “калибровка”. На практике же разные аналитические платформы по-разному определяют ключевые вещи: сессию, пользователя, событие, атрибуцию, частоту отправки, дедупликацию. Плюс накладываются режимы приватности: server-side-отправка, consent-статусы, кросс-доменные сценарии, возвраты в пределах окна. В 2026 году добавляется ещё и давление AI-overviews: растёт доля запросов и показов, где пользователь не “щёлкает” по сайту (zero-click), и маркетинг уже не может честно «дописать» визит, которого не было.

Почему это неправда: “единую правду” ломают не разные панели, а разная семантика и разные допущения. GA4 чаще воспринимают как отчётность по веб-событиям, где много работы вокруг privacy-first контура. Mixpanel и Heap нередко сильнее в аналитике поведения и продуктовых метриках — но тоже со своими правилами идентификации. Amplitude встраивается в событийную модель, где точность зависит от качества схемы событий и стабильности идентификаторов. Даже при одинаковой семантике расхождения появляются из-за латентности, пакетной доставки, дедупликации и того, как платформы трактуют “первое действие” и цепочки.

Что вместо этого: не искать “один источник истины”, а договориться о *едином словаре метрик* и *контракте данных*. Например: единые определения пользователя/сессии (ID-стратегия), событий (naming, обязательные параметры), окна атрибуции и правил дедупликации. Затем — “контрольный слой”: один эталонный пайплайн (обычно server-side + согласованные преобразования), и в каждой платформе — сравнение по заранее выбранным контрольным когортам и инкрементальным проверкам (incrementality, где возможно). Тогда Amplitude/GA4/Mixpanel становятся разными “линзами”, а не конкурентами за право считаться истиной.

Миф: «Mixpanel (или Amplitude) заменяет GA4 и “аналитика готова”»

В 2026 году это заблуждение звучит особенно убедительно, потому что таскать данные между инструментами стало быстрее, а визуализация событий — “красивее”. Но на практике продуктовая аналитика редко проигрывает внешней витрине, она проигрывает разрыву между событием, смыслом и управленческим решением.

Откуда миф
Его подпитывает сравнение “по интерфейсу”: в одном месте — воронки, в другом — отчёты, в третьем — дашборды. Кажется, что если Mixpanel/Amplitude умеют строить когортные графики и анализировать события, то они закрывают задачу целиком. GA4 при этом превращают в «просто ещё один счётчик», а серверную логику и качество данных — в настройку “попозже”.

Почему это неправда
ГА4 — это не “замена”, а опорная точка измерения: модель данных, сбор на уровне веба/приложений, связность с экосистемой трафика и базовой валидацией. А продуктовые платформы часто оптимизированы под исследование поведения и сегментацию. Проблема появляется, когда:
— в одном инструменте событие называется так, в другом иначе (семантика расползается);
— метрики от бизнеса считают “по-своему”, и в итоге retention/активация/конверсия начинают расходиться;
— при переходе на privacy-first атрибуцию (server-side, инкрементальность, MMM) вы не можете честно объяснить расхождения: что было измерено, где преобразовано и почему.

Что вместо
Стройте stack не по принципу “у кого красивее”, а по принципу ответственности:
— GA4 оставляйте как системную регистрацию событий и единый контракт на измерение;
— продуктовую аналитику (Mixpanel/Amplitude/Heap) используйте как исследовательскую линзу для когорт, фич-анализа и поведенческих гипотез;
— агрегируйте на RevOps/BI уровне бизнес-метрики (лиды, MQL/SQL, выручка, retention/LTV) и закрепляйте “одну правду” через единый словарь событий и проверки качества данных (валидация схемы, полнота, дубликаты).

И главное: не инструмент заменяет инструмент. Заменяется процесс принятия решений — когда аналитика становится измерением, а не витриной.

Глубже разбирают этот метод в @DemandGenB2B

От события к прибыли: как выстроить “измеримый” аналитический контур для RevOps в 2026

Маркетинг в 2026 всё чаще спорит не о том, какая кампания «лучше», а о том, что именно влияет на выручку. И тут ломается привычная логика: «GA4 посчитал конверсии — значит, всё работает». На практике же конверсия в лид или просмотр демо часто превращается в метрику ради метрики: она неполная, неустойчивая к изменениям в воронке и плохо объясняет, почему выручка растёт или проседает.

Выход — собирать аналитику не вокруг сайтовых событий, а вокруг контуров ответственности RevOps (маркетинг + продажи + customer success за выручку). Это не про «красивые дашборды», это про единый способ связывать: привлечение → квалификация → сделка → удержание → жизненная ценность.

Разберём, как это сделать без превращения стек-аналитики в набор несовместимых инструментов.

1) В 2026 атрибуция — не последняя миля, а модель принятия решений
Тезис: если вы строите решения “от последнего клика”, вы встраиваете в систему заведомую погрешность (а в privacy-first мире она растёт). Поэтому аналитический контур должен уметь отвечать на вопрос не «кто привёл», а «какие активности реально меняют бизнес-результат».

Пример: команда запускает контекстную рекламу и видит в GA4 рост лидов. Но в Mixpanel (или Heap) оказывается, что качество регистраций падает: доля дошедших до “requested demo” уменьшается, а дальше — больше “no-show”. В Amplitude это дополнительно подтверждается по когортам: пользователи из одного канала демонстрируют меньший activation rate (условное “вошли и сделали ключевое действие”), и это тянет down-funnel. В итоге last-click-вывод «кампания топ» не выдерживает, потому что в контуре нет промежуточной проверки качества.

Как чинят:
— Добавляют события квалификации (например, “lead_verified”, “demo_scheduled”, “demo_completed”, “proposal_sent”) и связывают их с источниками
— Делают server-side сборку (куда возможно) и унифицируют ключи идентификации
— Проверяют инкрементальность: простые A/B- или holdout-подходы по сегментам, плюс MMM там, где маркетинговые миксы сложно “разложить” кликами
Смысл: атрибуция превращается из “ответа на чье-то действие” в “модель, помогающую принимать решения” — и эту модель вы можете тестировать.

2) Единая “грамматика” событий: качество данных важнее количества событий
Тезис: стек (GA4/Amplitude/Mixpanel/Heap) может быть любым, но если события не стандартизированы, RevOps не получит согласованную картину. Нужна единая “грамматика” — что считается действием, кто его совершил, и как это связано с жизненным циклом клиента.

Пример: маркетинг видит событие “Lead” и трактует его как “потенциальный интерес”. Sales считает, что “Lead” — это “создан в CRM”. CS привязывает удержание к другому идентификатору: пользователю в продукте. В итоге один и тот же “Lead” в отчёте маркетинга и в отчёте продаж — это разные вещи.

Практика стандартизации:
— События делят по слоям: acquisition (привлечение), engagement (вовлечение), conversion (конверсия), value actions (ценностные действия), retention (удержание)
— Для каждого события фиксируют: описание, минимальный набор параметров, допустимые значения, периодичность и “истину” (source of truth). Например, “demo_completed” считается истинным только если есть запись в CRM, даже если в продукте тоже проставили флаг
— В event taxonomy вводят одинаковые ключи: campaign_id, content_id, referrer, device_type, plan_type (тариф/план), account_size, а также “revops_stage” (стадия цикла)
Если вы используете GA4 и один из продуктовых трекеров: GA4 берут для “широкой карты”, а Amplitude/Mixpanel/Heap — для поведенческой детализации и когорт. Но одинаковые значения параметров должны попадать во все инструменты.

3) Мост от пользователя к account: без Customer 360 RevOps будет слеп
Тезис: выручка редко “живёт” на уровне одного пользователя. Она живёт на уровне аккаунта (account) и на уровне набора ролей: кто подписывает, кто пользуется, кто продлевает. Поэтому аналитика должна агрегировать поведение в account-сущность, а не только в user.
…

Событие, а не цель: что такое event в продуктовой аналитике

В GA4, Amplitude, Mixpanel и Heap базовая единица измерения — событие (event). Это фиксируемое действие пользователя или системы: клик, просмотр, отправка формы, покупка, ошибка, запуск сценария. Событие отвечает на вопрос «что произошло», а не «кто это сделал» или «из какой кампании пришёл».

Частая путаница — с конверсией. Конверсия — это **событие, которое вы выделили как целевое и значимое для бизнеса**. То есть любая конверсия является событием, но не каждое событие — конверсия. Например, просмотр карточки товара и добавление в корзину могут быть событиями, а покупка — конверсией.

Типичные ошибки:
— Собирают слишком много событий без единой схемы именования.
— Путают событие с параметром: «страна» или «тариф» не событие, а свойство события.
— Ставят в конверсию микродействия, которые не связаны с выручкой или удержанием.
— Меняют названия событий после запуска и ломают исторические сравнения.

Пример: в B2B SaaS можно фиксировать `signup`, `invite_team`, `connect_integration`, `start_trial`. Само по себе `signup` — лишь событие. Но если анализ показывает, что пользователи, дошедшие до `connect_integration`, в 3 раза чаще оплачивают подписку, это событие стоит выделить как ключевое воронки и наблюдать отдельно.

GA4 vs Amplitude: почему я всё чаще делю “аналитику” на событие и решение

В 2026-м я всё чаще вижу одну и ту же картину: маркетинг-стек формально “всё умеет”, но бизнес получает слабый эффект от данных. Причина не в том, что GA4 или Amplitude «плохие». Причина в том, как мы трактуем их роль: как место, где копятся события, или как инструмент принятия решений.

Моя позиция простая: **я перестаю выбирать “что лучше”** и начинаю проектировать два слоя.

— Первый слой — “события как источник правды”. Это про корректность схемы (что считаем событием, какие параметры обязательны, как живёт идентификация пользователя). Здесь GA4, при дисциплине в event taxonomy, отлично закрывает базовые кейсы, особенно когда у команды уже есть привычки работы в Google-экосистеме.

— Второй слой — “события как механизм роста”. Это про быстрые гипотезы, сегментацию, ретроспективный анализ в разрезах, где решение должно быть принято на основе разницы между когортами, а не на основе средних по больнице. И вот тут Amplitude (и похожие по философии платформы) часто выигрывает: быстрее строятся аудитории, удобнее работать с поведенческими сценариями, проще доводить до экспериментов и post-mortem без бесконечных выгрузок.

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

2) В zero-click эпохе ценность приходит не с объёма трафика, а с собственной интерпретации поведения. Поэтому важнее не “сколько визитов”, а “какая последовательность действий привела к ценности” (активация, повтор, вовлечение в цикл продукта, путь к сделке в B2B). Событийный слой без сценарного — превращается в склад.

Практическое наблюдение из проектов
Мы однажды столкнулись с классической проблемой: в GA4 отлично считались события регистрации и покупок, но в Amplitude “ломалась” когортная логика, потому что идентификаторы пользователей в части потоков склеивались иначе. На уровне интерфейса всё выглядело правдоподобно, но на уровне принятия решений — нет. После того как мы синхронизировали правила идентификации (единый approach к user_id и правилам перегенерации при смене устройства/сессии) разница в конверсии по когортам сократилась не на проценты, а кратно по доверию команды к метрикам: от “похоже” к “можно действовать”.

Мой вывод
**GA4 и Amplitude я рассматриваю не как конкурентов, а как разные роли в одном контуре.** GA4 — часто лучший “операционный базис” для событийной гигиены, Amplitude — ускоритель сценарного мышления. Если у вас сейчас “одна система должна всё”, самое быстрое улучшение обычно не в миграции, а в архитектуре: определить, где заканчивается слой источника правды и начинается слой решения.

Вопрос к вам: у вас сейчас аналитика больше про “смотреть отчёты” или про “принимать решения между когортами”? Если второе — архитектура двух слоёв почти всегда даёт заметный выигрыш уже в первом цикле тестирования.

Соседняя редакция @MarketingBooksRoom недавно писала об этом под другим углом

Сверка аналитики: почему “мы меряем всё” почти всегда превращается в миф

В 2026 я всё чаще вижу один и тот же сценарий: бренд, B2B-платформа или e-commerce действительно “настроили аналитику” — события льются в GA4, дублируются в Amplitude или Mixpanel, а отдельные команды ещё и ковыряют Heap для UX. В таблицах есть конверсии, в дашбордах есть воронки, в отчётах — уверенность. Но когда доходит до решений, выясняется простое: **мы не измеряем одну и ту же реальность**.

Я формулирую это как правило редактора стека: если у вас нет процедур “кто и как сверяет”, то стек превращается в набор источников правды, которые спорят между собой.

Что конкретно ломает согласованность — без морали, только практика:

— Семантика событий разъезжается. В GA4 событие называется “lead_submit”, а в продуктовой аналитике оно же считается “form_submit”, и при этом один и тот же пользовательный путь даёт разные “лиды”.
— Разные окна атрибуции. Last-click — это уже не единственный ответ, но команды до сих пор сравнивают метрики, построенные на разных правилах: где-то 30 дней, где-то только в рамках сессии.
— Серверная часть (server-side) не одинаково отражает источник. Часть команд гоняет идентификаторы через клиент, другая — подписывает события на сервере. Итог: расхождение по пользователям и ретеншену.

Моё наблюдение из проектов по e-commerce и B2B: когда мы запускаем сверку на одном и том же наборе сценариев (1–2 ключевых user journey), расхождения между GA4 и продуктовой платформой обычно находятся в коридоре 5–25%. Причём это не “ошибка на 1%”, а систематическое смещение: как правило, из-за того, что определения конверсий различаются хотя бы на уровне фильтров или дедупликации.

Как я предлагаю чинить это без “пересборки вселенной”:

1) Жёстко зафиксировать “словарь метрик” — события, параметры, что считается конверсией и где происходит дедупликация. Не в одном документе на 40 страниц, а в коротком контракте: event_name + параметры + правила исключений.
2) Ввести регулярную “аналитическую контрольную точку”: один и тот же список сценариев и контрольных выборок прогоняется везде (GA4 / Amplitude / Mixpanel / Heap — что у вас реально стоит) с единым эталоном. Если расхождение растёт — ищем причину, а не успокаиваемся.
3) Приоритет — на измерение результата, а не на накопление событий. В эпоху privacy-first атрибуции и инкрементальности (incrementality) ценность получает то, что можно защитить на уровне методологии: когортный ретеншен, повторные покупки, повторные обращения, вклад по периодам.

Сейчас, когда рынок уходит от “просто лида” к RevOps (общая ответственность маркетинга, sales и customer success за выручку), цена несогласованных определений растёт. Не потому что “аналитика плохая”. А потому что решения принимаются быстрее, чем успевают договориться о смысле. В таком мире стек не должен быть коллекцией инструментов — он должен быть системой измерения.

Если хотите, в следующем посте разберу, как я обычно строю “контрольные сценарии” для сверки в B2B (MQL/SQL уже не достаточно) и как корректно отличать продуктовые конверсии от маркетинговых.

Соседняя редакция @BeautyCasesRu недавно писала об этом под другим углом

Растёт Topical Authority и AI-overviews, но «последний клик» всё чаще врёт. А в B2B и RevOps больно чинить воронку задним числом: какой событийный слой держит правду?

Вопрос: что вы считаете главным источником данных для решений в аналитике: GA4, Amplitude, Mixpanel или Heap?

ВАРИАНТЫ:
1. GA4 — если нужна связка с веб-экосистемой и стандартными отчетами
2. Amplitude — для поведенческих когорт и продуктовой аналитики
3. Mixpanel — когда важны события-воронки и удобная сегментация
4. Heap — если ловим всё автоматически и меньше думаем о тегах

GA4 не умер. Умерли ожидания, что он ответит на все вопросы

Я много раз вижу одну и ту же ошибку: GA4 пытаются использовать как единый источник правды для маркетинга, продукта и выручки. В результате его ругают за «сломанную аналитику», хотя проблема чаще в другом — в неверно собранной модели данных и в слишком широких ожиданиях от инструмента.

Моё мнение простое: **GA4 — это хороший слой для событийной веб- и приложенческой аналитики, но плохая замена аналитическому стеку**.

Что я имею в виду на практике.

— GA4 отлично ловит базовую поведенческую картину: источники, вовлечение, путь, конверсии на верхнем уровне.
— Но как только бизнесу нужно связать маркетинг с выручкой, LTV, повторными покупками и вкладом каналов в деньги, начинается боль.
— В B2B это ещё заметнее: лиды, сделки, длинный цикл, несколько касаний, участие sales и customer success. Тут GA4 сам по себе не тянет даже на «полуправду».

В 2026 году это особенно важно, потому что классический last-click всё хуже объясняет результат, а privacy-first подходы заставляют собирать картину из нескольких источников: server-side события, CRM, MMM, инкрементальность, поведенческие платформы. И вот здесь разница между GA4, Amplitude, Mixpanel и Heap становится не косметической, а архитектурной.

Я бы упростил выбор так:

— GA4 — для обязательного базового слоя и рекламной связки.
— Amplitude — когда нужен продуктовый анализ, сегменты, удержание, воронки по поведению.
— Mixpanel — когда важна скорость ответа на вопросы команды и чистая событийная логика.
— Heap — когда критична автоматическая сборка событий и быстрый старт без тяжёлой настройки.

**Но ни один из них не заменяет модель принятия решений.** Если у вас нет договорённости, какие метрики отвечают за привлечение, активацию, удержание и выручку, любой стек будет казаться «кривым».

Я обычно смотрю не на название инструмента, а на вопрос: какой бизнес-спор он должен закрыть за 15 минут? Если ответа нет, значит, вы выбираете не аналитику, а дорогую витрину цифр.

GA4 vs Amplitude vs Mixpanel: почему я перестал “верить” событиям как единице правды

За последний год я снова и снова вижу одну и ту же боль в analytics stack: команды сравнивают метрики между системами и получают несовпадения не потому, что “кто-то неправильно настроил”, а потому что они по-разному понимают, что такое событие и где лежит источник истины.

Моя практика такая. В начале проекта я прошу не “посчитать конверсию”, а ответить на 3 вопроса:
— что для нас событие (на уровне продукта и смысла)
— кто владелец схемы (events taxonomy) и как она версионируется
— где делаем дедупликацию и идентификацию пользователя/сессии

GA4, Amplitude и Mixpanel решают это разными механизмами, и это напрямую влияет на то, как выглядит “одна и та же” метрика.

GA4 часто воспринимают как “универсальный слой”, но там особенно важно различать параметры события, пользовательские свойства и то, как вы строите user journey. Плюс GA4 по умолчанию тянет за собой собственные допущения по идентификации пользователя и агрегациям. В итоге одинаковая строка “purchase” может давать разные числа, если один поток событий приходил с другой логикой идентификаторов (например, до и после логина).

Amplitude и Mixpanel обычно сильнее в продуктовой аналитике: они быстрее дают ценность в разрезе воронок, когорт и ретеншна, но там же часто “разъезжается” модель данных. Одна команда заводит событие “Lead created” с 7 параметрами и думает, что это гарантирует консистентность; другая — упрощает и отправляет только тип. Даже если названия совпали, семантика события уже разная. Для сравнения систем это критично: вы измеряете не purchase/lead, а “набор условий, при которых событие было принято и интерпретировано”.

Из практики наблюдение: у нас был кейс в B2B-сервисе, где расхождение по конверсии в MQL/SQL между Amplitude и GA4 оказалось в пределах 15–25%. При первичной настройке все выглядело одинаково: одинаковые названия событий, одинаковые параметры в документации. Разница всплыла только после того, как мы посмотрели на порядок событий вокруг идентификации: до логина срабатывал один триггер, после — другой, а дедупликация в одном из источников делала “склейку” иначе. В итоге событие оставалось тем же по имени, но не тем по жизненному циклу пользователя.

Почему я перестал делать ставку на “событие как единицу правды”. Потому что события в интерфейсе — это *представление*, а не истина. Истина — в контракте данных и правилах вычисления метрики. Поэтому я строю “слой правды” так:
— единая event taxonomy (название + обязательные параметры + версия)
— server-side нормализация (до отправки в BI/аналитику)
— отдельный вычислительный слой для ключевых метрик (конверсия, активация, ретеншн) с консистентной логикой

И вот тогда становится неважно, что вы используете: GA4, Amplitude или Mixpanel. Они перестают конкурировать, а начинают работать как витрины. А конкуренция, если честно, должна быть только в скорости вопросов к данным и удобстве интерпретации, а не в доверии к “одинаковым” событиям.

Если у вас сейчас воронки “плавают” между системами — начните не с калибровки дашбордов, а с аудита контракта: где происходит идентификация, где дедупликация и как версионируются события. Это быстрее, чем бесконечно спорить о том, почему “purchase” в одном месте честнее.

GA4 vs Amplitude vs Mixpanel: как Aviasales перешёл на event-аналитику и перестал спорить с отделами

В 2026-м большинство продуктовых команд живут в режиме “данные есть, но правды нет”: маркетинг меряет одно, продукт — другое, триггеры в CRM — третье, а итоговые отчёты разъезжаются на 10–30%. С этой проблемой в своё время столкнулся и Aviasales (тревел-сервис): разные определения конверсий и разные подходы к событиям делали невозможным нормальный RevOps-цикл (ответственность маркетинга, продаж и customer success за выручку).

Контекст
— Трафик: большой поток органики и performance-каналов, где ключевое — “что именно считать успешным шагом до покупки билета”.
— Продукт: много промежуточных состояний (поиск, выбор, переход к оплате, попытка оплаты, возврат, повторный выбор), и всё это зависит от платформы и сценария пользователя.
— Организация: маркетинг смотрит на воронки и качество лидов (MQL/SQL), продукт — на поведение в интерфейсе, CRM — на факт оплаты и выручку. На стыке возникали споры: “мы оптимизируем то, что реально приносит деньги, или то, что красиво выглядит в дашборде?”.

Задача
Свести “версии правды” к единой модели событий и атрибуции внутри аналитического стека. Конкретно нужно было:
— Перейти от разрозненных триггеров к event-аналитике с единым словарём событий.
— Надёжно связать поведение в приложении/вебе с бизнес-метриками (оплата, выручка, возвраты, повторные попытки).
— Уменьшить расход времени на разбор расхождений: чтобы решения по оптимизации принимались по одному набору метрик.
— Выстроить privacy-first подход (server-side сбор, меньше зависимости от last-click).

Решение
Команда Aviasales сделала ставку на “триангуляцию”: одно место для источника правды по поведению и отдельная прослойка для сверки с бизнес-результатами.

1) Словарь событий и правила именования
Они начали не с “какой инструмент лучше”, а с того, что GA4, Amplitude и Mixpanel называют по-разному: конверсия = это событие.
— ввели единый список событий (например, search_completed, seat_selected, checkout_viewed, payment_attempted, payment_succeeded);
— задали обязательные параметры (канал поиска, платформа, тип устройства, модель ошибки оплаты);
— договорились о правилах дедупликации (что считать “попыткой оплаты”: первая попытка в сессии или любая, но с ограничением по времени).

2) Слои аналитики: GA4 как baseline, Amplitude/Mixpanel как “глубина”
Практика была ближе к тому, как обычно сравнивают платформы в аналитике:
— GA4 использовали как базовую витрину для стандартных отчётов и быстрых проверок;
— Amplitude и Mixpanel — для более гибких когорт, ретеншн-аналитики и продвинутых воронок с параметрами событий.
Важно: “лучший” инструмент не выбирали по маркетинговым обещаниям, а по тому, где команда быстрее и стабильнее получает нужный разрез.

3) Server-side сбор и сверка с CRM/биллингом
Чтобы не жить в мире браузерных ограничений, внедрили сбор через server-side (плюс контроль дублей на стороне приёма событий). Затем настроили регулярную сверку:
— event funnel → “payment_attempted/payment_succeeded”;
— business факт из биллинга → фактическая выручка и статус оплаты.
Так они выявили, где расходятся трактовки: например, часть checkout-страниц открывалась, но оплата не начиналась (ошибка/отмена/возврат), и эти кейсы перестали смешиваться с успешными шагами.

4) Атрибуция без зависимости от last-click
Поскольку в тревеле путь длиннее и вариативнее, команда отказалась от “единственной магии” в стиле последнего клика. Вместо этого применяли комбинацию:
— инкрементальность (где возможно),
— смешивание измерений (server-side + агрегированные модели),
— согласование “куда оптимизируем”: не на абстрактные клики, а на события, которые коррелируют с выручкой.
…

GA4, Amplitude или Mixpanel: я бы выбирал не «лучший», а «наименее токсичный» для вашей команды

За последние два года я всё чаще вижу одну и ту же ошибку: маркетинг выбирает систему аналитики по чек-листу функций, а потом живёт с ней как с компромиссом. И это нормально — потому что в 2026 году главный вопрос уже не «что умеет платформа», а «сколько людей реально будут ей пользоваться каждый день».

Моё мнение простое:
**GA4 — база для охвата и связки с экосистемой Google, но не лучший центр принятия решений.**
Он хорош там, где нужен стандарт, доступность и быстрая интеграция. Но когда речь идёт о продуктовой аналитике, воронках, когортном поведении и нормальном разрезе по событиям, команда очень быстро упирается в неудобство модели данных.

**Amplitude — сильнее, если вам важны продуктовые сценарии и поведенческая глубина.**
Я бы ставил его в компании, где маркетинг уже работает не только на привлечение, но и на удержание, повторные визиты, LTV и совместную работу с продуктом. В RevOps-логике это особенно заметно: одна и та же метрика должна быть понятна и маркетингу, и sales, и customer success.

**Mixpanel — мой выбор, когда нужна скорость ответа и меньше «аналитического сопротивления» у команды.**
Он часто выигрывает не по количеству функций, а по тому, как быстро люди доходят до вопроса и ответа. Для продуктовых и growth-команд это критично: чем меньше трение, тем выше шанс, что аналитика станет рутиной, а не проектом «на квартал».

Heap я бы рассматривал, когда у команды слабая дисциплина трекинга и нужен более мягкий вход в событийную аналитику. Но чудес не бывает: если нет общей договорённости о событиях, названиях и владельцах метрик, любая платформа превращается в дорогой архив.

Один практический вывод из проектов: после внедрения «правильной» системы аналитики у нас почти всегда остаётся лишь 20–30% реально используемых отчётов. Остальное — цифровой мусор. Поэтому я советую выбирать не по списку возможностей, а по двум вопросам:
— кто будет пользоваться каждый день;
— какие 5–7 решений вы хотите принимать на основе этой системы.

Если этого нет, то проблема не в GA4, Amplitude или Mixpanel. Проблема в том, что аналитика куплена как инструмент, а не собрана как часть операционной модели.

Глубже разбирают этот метод в @CDProomRu

GA4 vs Amplitude: как за 7 дней настроить событийную модель под retention и связать в RevOps (без “универсальных” событий)

Если вы сейчас измеряете всё подряд, а в результате не можете ответить на простой вопрос “что именно удерживает пользователей и где теряется выручка”, проблема обычно не в инструменте, а в событийной модели. Ниже — практический план, как сделать её в GA4 и/или Amplitude за неделю так, чтобы данные уверенно использовались в аналитике и в работе RevOps (маркетинг–sales–customer success по выручке).

День 1. Зафиксируйте 1 “северную” метрику удержания
— Для e-com: повторная покупка за 30/60 дней или retention по когортам (customer retention rate).
— Для B2B: активность ключевого события в периоде (например, “получен первый ценностный результат” + отсутствие оттока в N дней).
Смысл: все события должны поддерживать эту метрику, а не просто “красиво заполнять дашборды”.

День 2. Составьте список событий по уровням (3 слоя)
Сделайте таблицу с колонками: событие → уровень → что измеряет → какие параметры нужны.
— Слой 1 (бизнес): purchase / trial-start / activation / renewal (в русской логике — покупка / старт пилота / активация / продление).
— Слой 2 (продукт): ключевые действия внутри продукта, которые ведут к “ценности”.
— Слой 3 (тех/качество): ошибки, падения, скроллы/просмотры только если это реально влияет на конверсию в ценность.
Правило: одно событие — один смысл. Не плодите “item_view_1 / item_view_2”.

День 3. Уберите из измерений “вечные” лишние события и выделите параметры-источники
— Определите 8–12 параметров, которые будут повторяться в событиях: channel (канал), plan/type (тип плана), device/locale, account_id/user_id, experiment_id (если есть), product_sku/category (если e-com), lead_source (для B2B).
— В GA4 оставьте минимум обязательных параметров в event parameters, в Amplitude — аналогично, но следите за тем, чтобы параметры были доступны до анализа (сквозная стабильность схемы важнее “широты”).
Результат дня: список параметров, по которым вы строите разрезы retention/оттока и связываете с выручкой.

День 4. Реализуйте identity и единый ключ пользователя
Сделайте это в первую очередь, потому что retention чаще всего “ломается” из‑за неправильной идентификации.
— В GA4: проверьте user_id (или аналог) и то, как вы передаёте client_id vs user_id. Если вы используете серверную передачу (server-side) — убедитесь, что она не разрывает идентичность.
— В Amplitude: настройте user_id и account_id (если B2B) так, чтобы к одной учётке/пользователю относились и веб, и продукт.
Проверка: в отладке (DebugView в GA4 / event inspector в Amplitude) убедитесь, что повторные визиты одного пользователя приходят как одно и то же лицо.

День 5. Постройте 2–3 “перехода” воронки к ценности (value funnel)
Нужно не 20 шагов, а 2–3 ключевых перехода, которые объясняют retention.
Примеры:
— e-com: landing → first_add_to_cart → first_purchase.
— B2B: lead_created → activation_event (первый ценностный результат) → first_seat_used (если применимо).
В Amplitude удобно запускать анализ retention по когортам, в GA4 — через пользовательские когорты/сегменты, но в обоих случаях важно, чтобы переходы опирались на бизнес-определения из дня 2.

День 6. Назначьте событиям статусы: “основные” и “диагностические”
— Основные (core): они используются в отчётах retention и в решениях по продукту/услугам.
— Диагностические (diagnostic): ошибки/латентность/обходы — для расследования причин, но не для KPI.
Это снижает хаос и делает аналитику устойчивой к “добавим ещё одно событие”.

День 7. Свяжите аналитику с RevOps через минимальный датасет
Сделайте экспорт/витрину данных для сквозного анализа:
— пользователь/аккаунт (user_id/account_id)
— когорта (дата первой ценности)
— событие активации (дата + параметры плана/канала)
— факт выручки/статус (purchase/renewal или стадия воронки B2B)
Дальше в RevOps вы сможете отвечать на вопросы:
— какие каналы дают удержание, а не только лиды;
— что отличает когорты, которые продлеваются;
— на каком шаге отваливаются пользователи до “ценности”.
…

GA4 уже не про «смотреть отчёты», а про дисциплину данных

В 2026 GA4 чаще выигрывает не как “лучшая аналитика”, а как базовый слой для всей системы измерения. Если у компании есть понятная событийная модель, GA4 нормально живёт рядом с Amplitude или Mixpanel: первый — для сквозной гигиены и связки с медиаканалами, вторые — для продуктовых разборов. А вот Heap в такой связке выглядит всё нишевее: удобно стартовать, но для зрелого B2B и retention-логики обычно быстро упираешься в ограничения.

Почему MMM станет новым стандартом в 2026

Эпоха, когда мы слепо верили атрибуции по последнему клику, окончательно уходит в прошлое. В условиях жесткой экономии и фокуса на удержании клиентов (retention), бизнес больше не готов платить за «видимость» эффективности. Мы видим, как компании массово переходят на маркетинговое моделирование микса (MMM). Это не попытка отказаться от детальных данных, а признание того, что в условиях конфиденциальности (privacy-first) только математические модели достоверно показывают вклад каждого канала в итоговую выручку. В связке с RevOps (единым подходом к доходам) это единственный способ адекватно оценить реальный вклад маркетинга в успех продукта.

Настройка парсинга URL в серверном GTM: чек-лист для чистоты данных

В эпоху privacy-first (приоритета конфиденциальности) и перехода на server-side (серверную) передачу данных, корректная обработка входящих HTTP-запросов становится фундаментом аналитики. Чтобы данные доходили до хранилищ и маркетинговых платформ без потерь, придерживайтесь следующего алгоритма:

— Установите шаблон URL Parser из галереи сообщества в серверный контейнер Google Tag Manager. Это позволит автоматически извлекать параметры запроса из длинных строк, которые не всегда корректно считываются стандартными средствами.

— Определите целевые параметры в входящем запросе. Выделите переменные, которые несут ценность для атрибуции (источник, кампания, идентификатор пользователя), и настройте их извлечение из HTTP-запроса, направляемого в серверный контейнер.

— Настройте маппинг (сопоставление) данных для передачи в сторонние системы. Убедитесь, что разобранные параметры корректно транслируются в формат, ожидаемый вашим аналитическим стеком, будь то GA4 или специализированные базы данных.

— Исключите передачу персональных данных (PII). Перед отправкой данных на сервер или во внешние системы используйте фильтры шаблона, чтобы зашифровать или удалить чувствительную информацию из URL, сохраняя только технические параметры.

— Протестируйте цепочку в режиме Preview (предпросмотра). Проверьте, корректно ли серверный контейнер «видит» входящий запрос и правильно ли переменная URL Parser извлекает нужные значения до момента отправки данных дальше.

— Верифицируйте поступление данных в конечные системы. Сравните сырые данные (raw data) в сервере с тем, что отображается в целевом интерфейсе, чтобы исключить потерю данных при их трансформации.

Это пригодится, когда нужно настроить надежный трекинг в условиях блокировок сторонних файлов cookie и при интеграции сложных серверных цепочек передачи данных.

Выбор системы продуктовой аналитики в 2026 году: чек-лист для RevOps-команд

В эпоху, когда классическая модель сбора лидов (потенциальных клиентов) уступает место RevOps (объединенной системе управления выручкой), выбор инструмента аналитики определяет точность прогнозирования LTV (пожизненной ценности клиента). Если ваша цель — уход от поверхностных метрик к моделированию выручки, следуйте этому алгоритму выбора стека.

— Оцените объем событий. Если ваш продукт генерирует более 50 миллионов событий в месяц, Heap становится экономически невыгодным из-за стоимости хранения. В этом случае смотрите в сторону Amplitude, где модель ценообразования гибче при масштабировании, либо переходите на архитектуру с хранилищем данных (Data Warehouse) и инструментом визуализации поверх него.

— Проверьте требования к атрибуции. Если вы строите стратегию на основе server-side (серверной) передачи данных для обхода ограничений приватности, Mixpanel предлагает более прозрачную интеграцию с API (программными интерфейсами), чем GA4. Последний в 2026 году остается базовым инструментом для веб-аналитики, но проигрывает в детализации поведения внутри приложения.

— Протестируйте работу с Historical Data (историческими данными). При переезде с GA4 на специализированные инструменты критически важно наличие функции обратной загрузки данных. Убедитесь, что выбранная система позволяет импортировать сырые события, иначе вы потеряете контекст долгосрочного retention (удержания) пользователей.

— Сопоставьте инструмент с глубиной вашего AI-стека. Если вы используете генеративные модели для создания персонализированных путей пользователя, выбирайте систему с развитым API для передачи предсказательных сегментов обратно в маркетинговые каналы в режиме реального времени.

— Проведите тест на «Zero-click» атрибуцию. Выбирайте систему, которая позволяет строить отчеты по пути пользователя, не ограничиваясь последним кликом. В условиях снижения среднего чека важно видеть влияние контента на каждом этапе воронки, а не только момент транзакции.

**Примите решение по архитектуре до квартального планирования:** если первичные данные разрознены, начните с внедрения единого хранилища данных, а не покупки новой лицензии. Инструмент — это лишь витрина, качество атрибуции зависит от чистоты потока данных из вашего бэкенда.