Дашборд “путь клиента” для Aviasales: как связали маркетинг, бронь и повторные покупки без last-click

Дашборд “путь клиента” для Aviasales: как связали маркетинг, бронь и повторные покупки без last-click

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

Задача
Раньше команда смотрела в разрезе каналов: CTR, CPA, доля брендового спроса. Но бизнес-метрики не сходились:
— лиды и клики росли, а доля бронирований по когортам не всегда улучшалась
— ретаргет “догонял” пользователей, но непонятно было, какой вклад он дает именно в инкрементальность
— маркетинг хотел управлять в логике RevOps (общая ответственность маркетинга, продаж и customer success за выручку), а данные в разрезах “канал → бронирование” были неполными

Решение
В Power BI построили модель данных и дашборд “Путь клиента” (funnel + cohort + инкрементальность-логика). Что сделали по шагам:

1) Единый ключ и витрина событий
— сквозная цепочка: просмотр/клик → переход → бронь → оплата → повторная поездка
— данные сводили в витрину с временными метками, чтобы анализировать задержки (time lag) и не смешивать события разных недель

2) Сегментация по намерению, а не только по каналу
— сегменты: бренд/небренд, высокий/средний/низкий интент (по поведению до брони)
— так маркетинг перестал спорить “это работал баннер или SEO”, и начал управлять вероятностью конверсии по смысловым группам

3) Cohort-таблицы вместо “сегодня к вчера”
— когорты по неделе первого контакта
— метрики: конверсия в бронь, доля оплаты, доля повторной поездки, LTV (на 60/90 дней)

4) Модуль “инкрементальности” через прокси
Из-за ограничений на чистый last-click использовали proxy-подход:
— сравнение контрольных/неэкспонированных сегментов (там, где есть возможность)
— проверка стабильности на “гео/тайм-окнах” и анализ lift в конверсиях, а не в кликах
Цель: не пытаться получить “идеальную магию”, а отсечь кампании, которые лишь перераспределяют спрос.

5) Архитектура дашборда под решение, а не под отчёт
— верх: KPI выручки и LTV по когортам
— середина: воронка с задержками и сегментами намерения
— низ: вклад каналов/кампаний в *изменение* конверсий (а не в факт трафика)
Фильтры: продукт/направление, тип устройства, период контакта, сегмент интента.

Результат
После внедрения дашборда команда пересобрала план бюджетов и KPI:
— перестали масштабировать кампании с высоким расходом и “красивыми” кликами, но без прироста в бронях по когортам
— сфокусировались на сегментах с устойчивой повторной поездкой: именно там LTV рос быстрее, чем затраты
— согласовали единый язык между маркетингом и продажами в логике RevOps: обсуждали не “CPA”, а “сколько выручки добавили когортам, которые иначе не забронировали бы”

По внутренним оценкам (после перехода на cohort + proxy lift): доля кампаний, дающих инкрементный эффект по брони/оплате, выросла, а контроль “трафик ради трафика” стал автоматизированным. Дополнительно снизили ручной анализ: время на подготовку еженедельного отчёта сократилось за счет модели и предрасчитанных мер.

Урок
1) В 2026 недостаточно дашборда “канал → клик”. Нужны когорты и связь с повторными покупками/выручкой.
2) RevOps выигрывает там, где Power BI дает одинаковые определения: что считаем конверсией, как измеряем вклад и какую метрику обсуждаем с бизнесом.
3) Privacy-first мир не отменяет эффективности — он меняет форму измерения: уходите от last-click-логики к инкрементальности через контрольные сравнения и прокси.

Если хотите, разберу структуру модели (таблицы фактов/измерений, какие меры стоит считать в первую очередь) под ваш текущий стек атрибуции и данные событий.

Дополнительный контекст — @ProductAnalyticsMK