GA4 vs Amplitude в Aviasales: как выстроили единый “слой истины” и не потеряли данные в zero-click-эпоху

GA4 vs Amplitude в Aviasales: как выстроили единый “слой истины” и не потеряли данные в zero-click-эпоху

Aviasales — хороший пример того, как тревожные симптомы “данные есть, решений нет” лечатся не очередным инструментом, а архитектурой аналитики. В 2026-м это особенно больно: растёт доля поиска с быстрыми ответами (zero-click), органика частично уходит в AI-overviews (пользователь не всегда доходит до сайта), а в перформансе побеждают privacy-first подходы (server-side, incrementality, MMM), вытесняя привычный last-click.

Контекст
У Aviasales несколько витрин: продуктовая аналитика по поведению пользователей, маркетинговая по кампаниям/каналам, плюс отдельные цепочки для конверсий в бронирование. Раньше часть команды жила в GA4 (события и воронки), другая — в Amplitude (когортный анализ, ретеншн-метрики, поведение по сессиям). Итог — разночтения: одни и те же “конверсии” на разных дашбордах считались по-разному, а при изменениях в трекинге (новые источники, редизайн формы, изменения логики поиска) расхождения могли проявляться уже через пару дней.

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

Решение
1) “Контракт событий” и единые определения
— Сформировали словарь: что такое *поиск выполнен*, *карточка перелёта открыта*, *выбрано*, *начато бронирование*, *успешно забронировано*, *отказ*.
— Для критичных событий ввели строгие параметры: currency/segment (сегмент), trip_type (тип поездки), origin/destination bucket, error_code.
— В обоих инструментах закрепили одинаковую семантику: GA4 и Amplitude больше не спорят “что считается конверсией”, они получают один и тот же контракт.

2) Server-side трекинг вместо “полагаться на браузер”
— Перенесли часть событий на server-side (серверная отправка) с единым middleware-слоем.
— Это снизило влияние баннерных блокировщиков/нестабильных куки и сделало подсчёт более воспроизводимым между системами.

3) Корректировка атрибуции: от last-click к проверке инкрементальности
— Для маркетинга перестали воспринимать last-click как истину. Дальше использовали подходы incrementality (инкрементальный замер) на уровне кампаний и MMM (моделирование маркетингового микса) для “верхнего” понимания вклада каналов.
— В дашбордах GA4 оставили операционные воронки, а Amplitude использовали как слой продуктовых когорт: именно там стало видно, что часть “успешных” каналов даёт краткосрочный всплеск, но хуже удерживает сценарии повторного поиска.

4) Единый пайплайн качества данных (Data QA)
— Ввели ежедневные проверки: объём событий по ключевым неймспейсам, доля “битых” параметров, согласованность идентификаторов user_id/session_id.
— Если расхождение между GA4 и Amplitude превышало порог (например, по успешным бронированиям больше чем на несколько процентов, а не “на глаз”), изменение откатывалось на уровне сборки события, а не руками правили отчёты.

Результат
По внутренним метрикам команды эффект был измерим:
— расхождения по ключевым конверсиям между GA4 и Amplitude сократились в разы (с “существенных расхождений” до уровней, где расхождение уже не влияло на решения по оптимизации)
— время на внедрение новой версии трекинга сократилось: вместо нескольких итераций сверки — быстрый прогон через QA-пайплайн
— маркетинговые решения стали опираться на поведение пользователя, а не только на факт клика: стало яснее, какие кампании дают качество сценария до бронирования и какие ухудшают повторный путь
— в логике RevOps “боли” customer success (например, возвраты/повторные обращения после неудачных сценариев поиска) стали прослеживаться назад к качеству события на этапе выбора и начала бронирования
…