GA4-кейc: как Aviasales перешёл от «смотрим трафик» к контролю качества лида через события и cohort-и

GA4-кейc: как Aviasales перешёл от «смотрим трафик» к контролю качества лида через события и cohort-и

Контекст
В 2025–2026 большинство тревожных сигналов у performance-команд выглядят одинаково: пользователи стали экономить (покупка реже), а средняя конверсия “в заказ” сильнее зависит от финального выбора и повторных касаний. Для travel-продуктов это особенно больно: часть сценариев уходит в “обдумывание”, часть — в “сравнение цен” и возврат позже. В такой реальности last-click (последний клик) перестаёт объяснять вклад кампаний, а маркетинг всё чаще отвечает за выручку вместе с продажами и поддержкой (RevOps — общая ответственность за результат).

Задача
Aviasales нужно было перестать мерить эффективность только по сессиям и кликам и начать управлять качеством лида (lead quality) на уровне воронки:
— сколько пользователей дошли до “намерения” (например, поиск/выбор маршрута)
— сколько дошли до “готовности” (оформление заявки/переход к оплате)
— и главное: насколько это намерение коррелирует с фактическим выполнением в пределах жизненного цикла (cohort — когортный период)

Решение (рецепт по шагам в логике GA4)
Шаг 1. События разделили на 3 слоя по смыслу, а не по источнику трафика
— “намерение”: просмотр результатов поиска, выбор рейса/направления, заполнение ключевых полей
— “готовность”: старт оформления, переход к способу оплаты, создание бронирования (если доступно)
— “документ”: финальный статус (успешно/неуспешно) с нормализацией причин отказа
Ключ: события называли единообразно и договорились об обязательных параметрах (страна, валюта, тип устройства, сегмент путешествия). Это позволило дальше строить отчёты без “зоопарка” названий.

Шаг 2. В ввели сквозную идентификацию без попытки “победить мир”
— использовали один и тот же User-ID там, где это возможно
— для остального опирались на server-side передачу событий (server-to-server), чтобы уменьшить потери из‑за блокировщиков и проблем на клиенте
— сверяли расхождения с бэкендом по статусам бронирования
Практический эффект: мы перестали гадать “почему GA4 показывает одно, а продукт другое”.

Шаг 3. Настроили конверсии не “по желанию”, а по модели принятия решения
Вместо одной конверсии “заказ” сделали несколько уровней:
— primary: финальный статус (успешно)
— mid: “создание бронирования”/“старт оплаты”
— proxy: “достижение намерения” (раньше, чтобы ловить качество до кассы)
Дальше в кампании оптимизацию вели не только по последнему клику, а по тому proxy/ mid, который лучше предсказывает успешную конверсию.

Шаг 4. Cohort-анализ качества лида: смотрели не даты, а устойчивость
Собрали когорты по дате события “намерение” и проследили долю перехода в “готовность” и “успешно” в окнах, например 1 день / 7 дней / 30 дней. Это критично для travel: часть пользователей возвращается позже, и “ранние” кампании могут казаться слабее, если мерить только вчерашнюю конверсию.

Результат
После внедрения новой event-структуры и cohort-логики команда получила управляемую картину:
— доля успешных конверсий внутри “готовности” выросла за счёт лучшего отбора кампаний/аудиторий: кампании, дававшие много “клика” без перехода в “готовность”, стали хуже попадать в оптимизацию
— расхождения между GA4 и бэкендом по ключевым событиям статусов сократились (контроль позволил быстро чинить маппинги и пропущенные параметры)
— отчёты перестали быть “историей трафика” и стали “историей решений”: маркетинг начал обсуждать с продажами (и поддержкой) показатели жизненного цикла, а не только MQL/SQL-воронки

Литературный “сухой остаток” для редакции GA4: когда вы строите воронку по смыслам и проверяете устойчивость через cohort-и, вы снижаете риск оптимизироваться под шум.
…