Эволюция атрибуции в эпоху Zero-click: как Lamoda перешла от last-click к модели жизненного цикла клиента
Контекст: В 2026 году классическая модель атрибуции по последнему клику (last-click) окончательно утратила статус «золотого стандарта». В условиях, когда поиск все чаще выдает готовые ответы в AI-обзорах, а пользователи совершают покупки без прямого перехода на сайт из выдачи, маркетологам пришлось искать альтернативы для оценки эффективности каналов.
Задача: Lamoda столкнулась с тем, что performance-маркетинг (эффективное продвижение) начал показывать перегретую стоимость привлечения, в то время как вклад контентных интеграций и охватных кампаний оставался невидимым. Нужно было понять, какой вклад в LTV (пожизненную ценность клиента) вносят неочевидные точки касания, чтобы не допустить сокращения бюджетов на каналы с отложенным спросом.
Решение: Компания внедрила систему гибридной аналитики, объединив серверную атрибуцию (server-side tracking) и эконометрическое моделирование (MMM).
— В Amplitude построили воронки, которые учитывали не только факт транзакции, но и «касания» клиента с полезным контентом внутри приложения.
— Сравнили данные GA4 с собственным хранилищем данных, чтобы выявить расхождения между «рекламным» трафиком и реальными сессиями.
— Отказались от оценки по первому или последнему переходу в пользу модели распределения ценности на основе данных о повторных покупках.
Результат: Выяснилось, что 35% аудитории, приходящей через органические обзоры и тематические статьи, совершают повторную покупку в течение 90 дней, тогда как «горячий» трафик с контекстной рекламы в 40% случаев ограничивался одной покупкой. Перераспределение бюджета в пользу каналов с высоким коэффициентом удержания (retention) позволило снизить стоимость привлечения клиента на 12% при сохранении общего объема выручки. Компания перешла от стратегии «продажа здесь и сейчас» к RevOps (общей ответственности команд маркетинга и продаж за выручку), где метрикой успеха стала не стоимость лида, а маржинальность жизненного цикла пользователя.
Урок: В условиях экономики, ориентированной на экономию, данные о первой покупке — лишь верхушка айсберга. Уход от линейных моделей атрибуции в сторону анализа накопленного влияния каждого касания — единственный способ выжить, когда SEO-трафик теряет привычную форму. Если ваш стек аналитики все еще опирается на события, происходящие только внутри браузера, вы упускаете из виду до половины ценности, которую генерирует ваш контент и бренд-коммуникация. В 2026 году побеждает не тот, кто первым дотянулся до кошелька клиента, а тот, кто выстроил наиболее устойчивую экосистему повторных взаимодействий.
Контекст: В 2026 году классическая модель атрибуции по последнему клику (last-click) окончательно утратила статус «золотого стандарта». В условиях, когда поиск все чаще выдает готовые ответы в AI-обзорах, а пользователи совершают покупки без прямого перехода на сайт из выдачи, маркетологам пришлось искать альтернативы для оценки эффективности каналов.
Задача: Lamoda столкнулась с тем, что performance-маркетинг (эффективное продвижение) начал показывать перегретую стоимость привлечения, в то время как вклад контентных интеграций и охватных кампаний оставался невидимым. Нужно было понять, какой вклад в LTV (пожизненную ценность клиента) вносят неочевидные точки касания, чтобы не допустить сокращения бюджетов на каналы с отложенным спросом.
Решение: Компания внедрила систему гибридной аналитики, объединив серверную атрибуцию (server-side tracking) и эконометрическое моделирование (MMM).
— В Amplitude построили воронки, которые учитывали не только факт транзакции, но и «касания» клиента с полезным контентом внутри приложения.
— Сравнили данные GA4 с собственным хранилищем данных, чтобы выявить расхождения между «рекламным» трафиком и реальными сессиями.
— Отказались от оценки по первому или последнему переходу в пользу модели распределения ценности на основе данных о повторных покупках.
Результат: Выяснилось, что 35% аудитории, приходящей через органические обзоры и тематические статьи, совершают повторную покупку в течение 90 дней, тогда как «горячий» трафик с контекстной рекламы в 40% случаев ограничивался одной покупкой. Перераспределение бюджета в пользу каналов с высоким коэффициентом удержания (retention) позволило снизить стоимость привлечения клиента на 12% при сохранении общего объема выручки. Компания перешла от стратегии «продажа здесь и сейчас» к RevOps (общей ответственности команд маркетинга и продаж за выручку), где метрикой успеха стала не стоимость лида, а маржинальность жизненного цикла пользователя.
Урок: В условиях экономики, ориентированной на экономию, данные о первой покупке — лишь верхушка айсберга. Уход от линейных моделей атрибуции в сторону анализа накопленного влияния каждого касания — единственный способ выжить, когда SEO-трафик теряет привычную форму. Если ваш стек аналитики все еще опирается на события, происходящие только внутри браузера, вы упускаете из виду до половины ценности, которую генерирует ваш контент и бренд-коммуникация. В 2026 году побеждает не тот, кто первым дотянулся до кошелька клиента, а тот, кто выстроил наиболее устойчивую экосистему повторных взаимодействий.
Эволюция атрибуции: почему Lamoda перешла от last-click к моделированию маркетингового микса
Контекст: в условиях 2026 года, когда стоимость привлечения клиента растет, а эпоха «нулевых кликов» (когда пользователь получает ответ прямо в поисковой выдаче без перехода на сайт) обесценивает классические цепочки касаний, привычная аналитика по последнему клику (last-click) стала давать критические искажения. Для крупных игроков в сфере электронной коммерции это означает необоснованное завышение бюджета на performance-каналы в ущерб брендингу.
Задача: Lamoda столкнулась с тем, что вклад медийной рекламы в долгосрочный рост LTV (пожизненной ценности клиента) оставался «невидимым» для стандартных отчетов GA4. При снижении среднего чека на 6% по рынку, компании требовалось понять, какие именно каналы реально влияют на повторные покупки, а не просто перехватывают трафик на этапе готовности к транзакции.
Решение: переход на гибридную аналитическую модель. Команда внедрила MMM (маркетинговое моделирование микса) в связке с server-side (серверной) передачей данных. Вместо опоры только на cookie-файлы, которые блокируются браузерами, компания стала использовать собственные данные о пользователях в Amplitude для построения прогнозируемых моделей оттока и удержания. Интеграция с Mixpanel позволила сегментировать аудиторию не по источнику входа, а по глубине взаимодействия с контентом сайта.
Результат:
— Снижение расходов на «каннибализирующие» каналы (контекстная реклама по брендовым запросам) на 12%.
— Перераспределение 15% бюджета в пользу охватных кампаний, которые показали накопленный эффект через 3-4 недели после первого касания.
— Рост показателя удержания (retention) на 4,5% за счет более точной настройки рекламных сообщений на основе AI-генерации под конкретные сегменты интересов, выявленные через Amplitude.
Урок для индустрии: в эпоху privacy-first (приоритета приватности) точность до конкретного клика — это иллюзия. Основные выводы для аналитиков:
— Перестаньте слепо доверять GA4 в вопросах оценки медийного охвата. Инструмент отлично считает конверсии, но не видит влияние бренда на принятие решения.
— MMM — это не атавизм, а единственный способ оценить эффективность в мире без сторонних cookie-файлов.
— RevOps-подход требует объединения данных о продажах и маркетинговых затратах в единый дашборд. Если аналитик не видит вклад маркетинга в стоимость удержания (CAC/LTV), он работает только с половиной картины.
Сегодня выигрывает не тот, кто первым поставил тег отслеживания, а тот, кто научился моделировать влияние каждого вложенного рубля на выручку всей системы, а не отдельного рекламного кабинета.
Контекст: в условиях 2026 года, когда стоимость привлечения клиента растет, а эпоха «нулевых кликов» (когда пользователь получает ответ прямо в поисковой выдаче без перехода на сайт) обесценивает классические цепочки касаний, привычная аналитика по последнему клику (last-click) стала давать критические искажения. Для крупных игроков в сфере электронной коммерции это означает необоснованное завышение бюджета на performance-каналы в ущерб брендингу.
Задача: Lamoda столкнулась с тем, что вклад медийной рекламы в долгосрочный рост LTV (пожизненной ценности клиента) оставался «невидимым» для стандартных отчетов GA4. При снижении среднего чека на 6% по рынку, компании требовалось понять, какие именно каналы реально влияют на повторные покупки, а не просто перехватывают трафик на этапе готовности к транзакции.
Решение: переход на гибридную аналитическую модель. Команда внедрила MMM (маркетинговое моделирование микса) в связке с server-side (серверной) передачей данных. Вместо опоры только на cookie-файлы, которые блокируются браузерами, компания стала использовать собственные данные о пользователях в Amplitude для построения прогнозируемых моделей оттока и удержания. Интеграция с Mixpanel позволила сегментировать аудиторию не по источнику входа, а по глубине взаимодействия с контентом сайта.
Результат:
— Снижение расходов на «каннибализирующие» каналы (контекстная реклама по брендовым запросам) на 12%.
— Перераспределение 15% бюджета в пользу охватных кампаний, которые показали накопленный эффект через 3-4 недели после первого касания.
— Рост показателя удержания (retention) на 4,5% за счет более точной настройки рекламных сообщений на основе AI-генерации под конкретные сегменты интересов, выявленные через Amplitude.
Урок для индустрии: в эпоху privacy-first (приоритета приватности) точность до конкретного клика — это иллюзия. Основные выводы для аналитиков:
— Перестаньте слепо доверять GA4 в вопросах оценки медийного охвата. Инструмент отлично считает конверсии, но не видит влияние бренда на принятие решения.
— MMM — это не атавизм, а единственный способ оценить эффективность в мире без сторонних cookie-файлов.
— RevOps-подход требует объединения данных о продажах и маркетинговых затратах в единый дашборд. Если аналитик не видит вклад маркетинга в стоимость удержания (CAC/LTV), он работает только с половиной картины.
Сегодня выигрывает не тот, кто первым поставил тег отслеживания, а тот, кто научился моделировать влияние каждого вложенного рубля на выручку всей системы, а не отдельного рекламного кабинета.
GA4 — это не «плохая аналитика». Это хороший компромисс, если вам нужно жить в экосистеме Google
За последние два года я всё чаще вижу один и тот же спор: «почему GA4 неудобен и зачем вообще он нужен, если есть Amplitude, Mixpanel или Heap». Мой ответ простой: у этих инструментов разная работа.
GA4 я считаю не продуктовой аналитикой, а **универсальным слоем наблюдения за маркетингом**. Он полезен там, где нужно связать каналы, кампании, события на сайте и базовую выручку. Но как только задача становится глубже — понять, почему пользователь возвращается, где ломается активация, как меняется поведение когорт, — GA4 быстро упирается в потолок.
Я это хорошо вижу на проектах, где есть и рекламный трафик, и продуктовая воронка. В одном B2B-кейсе после переноса событий из GA4 в Amplitude мы нашли, что форма заявки была не главной проблемой. Оказалось, что 38% пользователей доходили до демо, но не завершали его из-за провала между первым и вторым шагом онбординга. В GA4 это выглядело как обычная просадка конверсии. В Amplitude — как конкретный разрыв сценария.
Моя позиция такая:
— GA4 нужен почти всем, потому что он закрывает базовую связку маркетинга и веб-аналитики.
— Amplitude и Mixpanel нужны там, где вы строите продуктовые сценарии, когорты, удержание и поведение по шагам.
— Heap силён, когда вы хотите меньше зависеть от ручной разметки и быстрее ловить неожиданные паттерны.
— Но ни один из них не заменяет нормальную постановку вопросов. Плохая модель данных убивает даже лучший стек.
В 2026 году это особенно заметно: last-click слабеет, RevOps требует общей картины, а AI-overviews и zero-click делают ценнее не отчёты «сколько было», а ответы «что влияет на выручку». Поэтому я всегда начинаю не с выбора платформы, а с выбора уровня задачи. Если нужен обзор — GA4. Если нужен разбор поведения — продуктовая аналитика. Если нужен рост выручки — уже нужен стек, а не один инструмент.
За последние два года я всё чаще вижу один и тот же спор: «почему GA4 неудобен и зачем вообще он нужен, если есть Amplitude, Mixpanel или Heap». Мой ответ простой: у этих инструментов разная работа.
GA4 я считаю не продуктовой аналитикой, а **универсальным слоем наблюдения за маркетингом**. Он полезен там, где нужно связать каналы, кампании, события на сайте и базовую выручку. Но как только задача становится глубже — понять, почему пользователь возвращается, где ломается активация, как меняется поведение когорт, — GA4 быстро упирается в потолок.
Я это хорошо вижу на проектах, где есть и рекламный трафик, и продуктовая воронка. В одном B2B-кейсе после переноса событий из GA4 в Amplitude мы нашли, что форма заявки была не главной проблемой. Оказалось, что 38% пользователей доходили до демо, но не завершали его из-за провала между первым и вторым шагом онбординга. В GA4 это выглядело как обычная просадка конверсии. В Amplitude — как конкретный разрыв сценария.
Моя позиция такая:
— GA4 нужен почти всем, потому что он закрывает базовую связку маркетинга и веб-аналитики.
— Amplitude и Mixpanel нужны там, где вы строите продуктовые сценарии, когорты, удержание и поведение по шагам.
— Heap силён, когда вы хотите меньше зависеть от ручной разметки и быстрее ловить неожиданные паттерны.
— Но ни один из них не заменяет нормальную постановку вопросов. Плохая модель данных убивает даже лучший стек.
В 2026 году это особенно заметно: last-click слабеет, RevOps требует общей картины, а AI-overviews и zero-click делают ценнее не отчёты «сколько было», а ответы «что влияет на выручку». Поэтому я всегда начинаю не с выбора платформы, а с выбора уровня задачи. Если нужен обзор — GA4. Если нужен разбор поведения — продуктовая аналитика. Если нужен рост выручки — уже нужен стек, а не один инструмент.
GA4 не умер. Умерла иллюзия, что одной аналитики хватит
Я часто вижу одну и ту же ошибку: команды выбирают систему аналитики как будто это покупка «единственного правильного» инструмента. На практике GA4, Amplitude, Mixpanel и Heap закрывают разные управленческие задачи — и спор «что лучше» обычно маскирует вопрос «что мы вообще измеряем».
Моя позиция простая: в 2026 году стек аналитики должен собираться не вокруг отчётов, а вокруг решения. Если у вас B2B с длинным циклом сделки и общими метриками маркетинга, продаж и customer success, то вам нужен не просто продуктовый анализ, а связка с RevOps-логикой. Если вы строите продукт и хотите быстро отвечать на вопросы про поведение, когорты и удержание, то Amplitude или Mixpanel дадут больше скорости, чем попытка выжать всё из GA4. Heap силён там, где команде важна полнота событий и меньше ручной настройки на старте.
GA4 я считаю базой, но не центром вселенной. Он хорош для связки с вебом, рекламой и верхнеуровневой картиной спроса. Но как только бизнес начинает жить retention-метриками, сегментами и сценариями поведения, вы упираетесь в ограничения интерфейса и логики данных.
Из практики: в одном B2B-проекте после переноса ключевых продуктовых вопросов из GA4 в отдельный поведенческий инструмент время на подготовку регулярного отчёта сократилось примерно на 40%. Не потому, что «красивее графики», а потому что команда перестала вручную собирать ответы из трёх источников.
Мой вывод: **не ищите лучшую платформу. Собирайте стек под управленческое решение**.
- GA4 — для маркетингового и веб-контекста
- Amplitude / Mixpanel — для продуктовой аналитики и поведения
- Heap — когда важна скорость старта и полнота трекинга
А если у вас в компании до сих пор один вопрос звучит так: «какой инструмент поставить?», значит, сначала нужно договориться не про софт, а про вопросы бизнеса.
—
Продолжение про marketing — @MarTechStackRuPro
Я часто вижу одну и ту же ошибку: команды выбирают систему аналитики как будто это покупка «единственного правильного» инструмента. На практике GA4, Amplitude, Mixpanel и Heap закрывают разные управленческие задачи — и спор «что лучше» обычно маскирует вопрос «что мы вообще измеряем».
Моя позиция простая: в 2026 году стек аналитики должен собираться не вокруг отчётов, а вокруг решения. Если у вас B2B с длинным циклом сделки и общими метриками маркетинга, продаж и customer success, то вам нужен не просто продуктовый анализ, а связка с RevOps-логикой. Если вы строите продукт и хотите быстро отвечать на вопросы про поведение, когорты и удержание, то Amplitude или Mixpanel дадут больше скорости, чем попытка выжать всё из GA4. Heap силён там, где команде важна полнота событий и меньше ручной настройки на старте.
GA4 я считаю базой, но не центром вселенной. Он хорош для связки с вебом, рекламой и верхнеуровневой картиной спроса. Но как только бизнес начинает жить retention-метриками, сегментами и сценариями поведения, вы упираетесь в ограничения интерфейса и логики данных.
Из практики: в одном B2B-проекте после переноса ключевых продуктовых вопросов из GA4 в отдельный поведенческий инструмент время на подготовку регулярного отчёта сократилось примерно на 40%. Не потому, что «красивее графики», а потому что команда перестала вручную собирать ответы из трёх источников.
Мой вывод: **не ищите лучшую платформу. Собирайте стек под управленческое решение**.
- GA4 — для маркетингового и веб-контекста
- Amplitude / Mixpanel — для продуктовой аналитики и поведения
- Heap — когда важна скорость старта и полнота трекинга
А если у вас в компании до сих пор один вопрос звучит так: «какой инструмент поставить?», значит, сначала нужно договориться не про софт, а про вопросы бизнеса.
—
Продолжение про marketing — @MarTechStackRuPro
Смерть атрибуции по последнему клику и почему 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, продуктовой аналитики и рекламных площадок в единую модель данных, иначе вы продолжите оптимизировать кампании, которые не приносят денег.
В эпоху, когда классическая модель сбора лидов (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 (эпохе без переходов).
Инструмент — это лишь зеркало вашей стратегии. Если стратегия строится на устаревших метриках, даже самый дорогой стек аналитики будет лишь красиво визуализировать ваше падение.
Мы окончательно перешли в эпоху, где классическая модель атрибуции по последнему клику (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 может быть не «количество регистраций», а «число активных команд, которые еженедельно используют ключевую функцию». Это ближе к реальной ценности, чем верхнеуровневый трафик или лиды.
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-модель, выигрывает тот, кто измеряет не визит, а путь к выручке.
В 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 становятся разными “линзами”, а не конкурентами за право считаться истиной.
Миф: если выбрать один продукт (например, 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
В 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.
…
Маркетинг в 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, 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-м я всё чаще вижу одну и ту же картину: маркетинг-стек формально “всё умеет”, но бизнес получает слабый эффект от данных. Причина не в том, что 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 недавно писала об этом под другим углом
В 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, 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 пытаются использовать как единый источник правды для маркетинга, продукта и выручки. В результате его ругают за «сломанную аналитику», хотя проблема чаще в другом — в неверно собранной модели данных и в слишком широких ожиданиях от инструмента.
Моё мнение простое: **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” в одном месте честнее.
За последний год я снова и снова вижу одну и ту же боль в 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 + агрегированные модели),
— согласование “куда оптимизируем”: не на абстрактные клики, а на события, которые коррелируют с выручкой.
…
В 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
За последние два года я всё чаще вижу одну и ту же ошибку: маркетинг выбирает систему аналитики по чек-листу функций, а потом живёт с ней как с компромиссом. И это нормально — потому что в 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 и/или 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 вы сможете отвечать на вопросы:
— какие каналы дают удержание, а не только лиды;
— что отличает когорты, которые продлеваются;
— на каком шаге отваливаются пользователи до “ценности”.
…