GA4 против Amplitude: где чаще всего ломается аналитика (и почему “правильная” настройка не спасает)
Я регулярно вижу одну и ту же картину: в компании настроили события в GA4 «как в методичке», сделали воронки, включили косты (стоимость) и вроде бы всё заработало. Потом приходит Amplitude (или Mixpanel/Heap), команда делает параллельную аналитику — и выясняется, что цифры не сходятся. Не на 1–2%, а радикально: конверсия в воронке то растёт, то падает, а когорты «плавают». На мой взгляд, проблема почти никогда не в инструменте. Проблема в модели измерения: как именно вы определяете пользователя, событие, сессию и “момент истины”.
Моё наблюдение из практики: чаще всего расхождения рождаются в трёх местах.
1) Идентификация пользователя: device id vs login id
В GA4 и Amplitude по-разному реализованы механики user identity и маппинга между анонимным и авторизованным состоянием. Если в одной системе “пользователь” — это device, а в другой — устойчивый login, то вы получите разные когорты и разные retention-показатели. Технически оба могут быть “правильными”. Бизнес-метрика при этом — нет.
2) Дублирование событий из-за серверной/клиентской отправки
Когда подключают server-side (отправку событий с сервера) или используют теги, которые дублируют one-time события (например, view → снова view при повторной отрисовке), разъезжаются и MAU, и воронки. В GA4 это особенно видно, когда событие попадает в несколько «сценариев» через разные источники. В Amplitude — если вы не закладываете идемпотентность (в логике “одно событие — один раз”).
3) Единый язык метрик не закреплён документом
Команды называют одинаковыми словами разные вещи: “lead” в одном месте — это submit формы, в другом — успешный handoff в sales (или даже переход в статус квалификации). В результате вы сравниваете несопоставимые события, и кажется, что инструмент «врёт». На самом деле инструмент просто показывает то, что вы ему разрешили.
Как я это чиню в stack-подходе (без религии GA4/Amplitude)
— Делаю **контракт событий**: список событий + формальные определения (что является триггером, какие поля обязательны, какие значения допустимы).
— Ввожу “контрольные” метрики: 3–5 событий, которые нельзя трактовать по-разному (например, login success, purchase completed, signup submitted).
— Согласую identity-стратегию: что первично до логина, что происходит после логина, как меряем пользователя в когортном разрезе.
Одна цифра из недавнего кейса: после наведения порядка в identity и запрета дублей мы получили разницу по конверсии на первом шаге воронки не «на десятки процентов», а в пределах 3–5%. До этого расхождение достигало ~22%. Суть была не в том, что GA4 или Amplitude “плохие”, а в том, что метрика “пользователь” определялась по-разному, и эта разница размножалась по цепочке: от воронок до retention.
Мой вывод: в analytics stack побеждает не тот, у кого больше фич, а тот, у кого лучше измерительная дисциплина. Инструмент можно менять. **Определение метрики — нельзя.**
— @AnalyticsStackRu
Соседняя редакция @MessengerMarketingRu недавно писала об этом под другим углом
Я регулярно вижу одну и ту же картину: в компании настроили события в GA4 «как в методичке», сделали воронки, включили косты (стоимость) и вроде бы всё заработало. Потом приходит Amplitude (или Mixpanel/Heap), команда делает параллельную аналитику — и выясняется, что цифры не сходятся. Не на 1–2%, а радикально: конверсия в воронке то растёт, то падает, а когорты «плавают». На мой взгляд, проблема почти никогда не в инструменте. Проблема в модели измерения: как именно вы определяете пользователя, событие, сессию и “момент истины”.
Моё наблюдение из практики: чаще всего расхождения рождаются в трёх местах.
1) Идентификация пользователя: device id vs login id
В GA4 и Amplitude по-разному реализованы механики user identity и маппинга между анонимным и авторизованным состоянием. Если в одной системе “пользователь” — это device, а в другой — устойчивый login, то вы получите разные когорты и разные retention-показатели. Технически оба могут быть “правильными”. Бизнес-метрика при этом — нет.
2) Дублирование событий из-за серверной/клиентской отправки
Когда подключают server-side (отправку событий с сервера) или используют теги, которые дублируют one-time события (например, view → снова view при повторной отрисовке), разъезжаются и MAU, и воронки. В GA4 это особенно видно, когда событие попадает в несколько «сценариев» через разные источники. В Amplitude — если вы не закладываете идемпотентность (в логике “одно событие — один раз”).
3) Единый язык метрик не закреплён документом
Команды называют одинаковыми словами разные вещи: “lead” в одном месте — это submit формы, в другом — успешный handoff в sales (или даже переход в статус квалификации). В результате вы сравниваете несопоставимые события, и кажется, что инструмент «врёт». На самом деле инструмент просто показывает то, что вы ему разрешили.
Как я это чиню в stack-подходе (без религии GA4/Amplitude)
— Делаю **контракт событий**: список событий + формальные определения (что является триггером, какие поля обязательны, какие значения допустимы).
— Ввожу “контрольные” метрики: 3–5 событий, которые нельзя трактовать по-разному (например, login success, purchase completed, signup submitted).
— Согласую identity-стратегию: что первично до логина, что происходит после логина, как меряем пользователя в когортном разрезе.
Одна цифра из недавнего кейса: после наведения порядка в identity и запрета дублей мы получили разницу по конверсии на первом шаге воронки не «на десятки процентов», а в пределах 3–5%. До этого расхождение достигало ~22%. Суть была не в том, что GA4 или Amplitude “плохие”, а в том, что метрика “пользователь” определялась по-разному, и эта разница размножалась по цепочке: от воронок до retention.
Мой вывод: в analytics stack побеждает не тот, у кого больше фич, а тот, у кого лучше измерительная дисциплина. Инструмент можно менять. **Определение метрики — нельзя.**
— @AnalyticsStackRu
Соседняя редакция @MessengerMarketingRu недавно писала об этом под другим углом
GA4 vs «плагины Universal Analytics»: как не потерять события при миграции
Если у вас в прошлых проектах были «универсальные аналитические плагины» (Universal Analytics Plugins) и вы сейчас переносите логику в GA4 или в свой аналитический стек, проверьте риски как методический аудит. Не «вспомнить», а системно восстановить соответствия событий.
— Инвентаризируйте плагины и их области действия
Составьте таблицу: название плагина, что именно менял (валидации, фильтрация, обогащение), на каких страницах/событиях работал. Дальше это станет картой соответствий для GA4 событий.
— Зафиксируйте правила трансформаций в исходном виде
Плагины часто меняют поля до отправки: формат, параметры, структуру категории/действия. Перенесите логику в описание: какие входные поля → какие выходные, какие условия срабатывания.
— Подсветите «тихие потери» данных при переносе
В UA часть логики могла не доходить до отчётов как ожидается (например, если плагин блокировал событие или корректировал параметры). Проверьте, какие события в UA были «всегда» и какие внезапно могут стать редкими в GA4.
— Переведите аналитику в контролируемые конвейеры (GTM/сервер)
Вместо «вшитых» UA-плагинов заложите трансформации в более управляемый слой: тег-менеджер или серверная прослойка (server-side), чтобы правила были воспроизводимыми и тестируемыми.
— Сделайте сопоставление UA-параметров с GA4-структурой
Сформируйте маппинг: category/action/label и прочие UA-поля → в какие параметры GA4 event (имя события, параметры, пользовательские/сессионные свойства). Цель — чтобы отчётность и воронки строились на одинаковом смысле.
— Проведите регрессионное тестирование на одинаковых сценариях
Прогоните 5–10 пользовательских путей (лендинг → форма → отправка → навигация) и сравните: полный набор событий, обязательные параметры, кратность, порядок. Сравнение делайте не «по ощущению», а по экспортам сырья.
— Документируйте правила для RevOps/контроля качества выручки
Раз GA4/стек становится частью ответственности маркетинга-сейлза-customer success за выручку, добавьте в регламенты: какие события считаются конверсией, какие — поддержкой, где ошибка превращается в неверный MQL/SQL (и как это отлавливать до релиза).
когда это пригодится: при миграции с Universal Analytics и разборе расхождений по событиям в GA4 после изменений в тегах или измерениях.
— @AnalyticsStackRu
Если у вас в прошлых проектах были «универсальные аналитические плагины» (Universal Analytics Plugins) и вы сейчас переносите логику в GA4 или в свой аналитический стек, проверьте риски как методический аудит. Не «вспомнить», а системно восстановить соответствия событий.
— Инвентаризируйте плагины и их области действия
Составьте таблицу: название плагина, что именно менял (валидации, фильтрация, обогащение), на каких страницах/событиях работал. Дальше это станет картой соответствий для GA4 событий.
— Зафиксируйте правила трансформаций в исходном виде
Плагины часто меняют поля до отправки: формат, параметры, структуру категории/действия. Перенесите логику в описание: какие входные поля → какие выходные, какие условия срабатывания.
— Подсветите «тихие потери» данных при переносе
В UA часть логики могла не доходить до отчётов как ожидается (например, если плагин блокировал событие или корректировал параметры). Проверьте, какие события в UA были «всегда» и какие внезапно могут стать редкими в GA4.
— Переведите аналитику в контролируемые конвейеры (GTM/сервер)
Вместо «вшитых» UA-плагинов заложите трансформации в более управляемый слой: тег-менеджер или серверная прослойка (server-side), чтобы правила были воспроизводимыми и тестируемыми.
— Сделайте сопоставление UA-параметров с GA4-структурой
Сформируйте маппинг: category/action/label и прочие UA-поля → в какие параметры GA4 event (имя события, параметры, пользовательские/сессионные свойства). Цель — чтобы отчётность и воронки строились на одинаковом смысле.
— Проведите регрессионное тестирование на одинаковых сценариях
Прогоните 5–10 пользовательских путей (лендинг → форма → отправка → навигация) и сравните: полный набор событий, обязательные параметры, кратность, порядок. Сравнение делайте не «по ощущению», а по экспортам сырья.
— Документируйте правила для RevOps/контроля качества выручки
Раз GA4/стек становится частью ответственности маркетинга-сейлза-customer success за выручку, добавьте в регламенты: какие события считаются конверсией, какие — поддержкой, где ошибка превращается в неверный MQL/SQL (и как это отлавливать до релиза).
когда это пригодится: при миграции с Universal Analytics и разборе расхождений по событиям в GA4 после изменений в тегах или измерениях.
— @AnalyticsStackRu