Кейс: как Aviasales собрала управленческий отчёт в Looker Studio и перешла от “трафик-аналитики” к RevOps

Кейс: как Aviasales собрала управленческий отчёт в Looker Studio и перешла от “трафик-аналитики” к RevOps

В 2026 году многие команды авиа- и travel-секторов столкнулись с одним и тем же: воронка стала длиннее, верхняя часть выдаёт всё меньше “чистых” сигналов из‑за privacy-first подходов, а рост упирается не в клики, а в конверсию на следующих шагах (подбор → бронь → повторные сценарии). Для RevOps (общей ответственности маркетинга, продаж и customer success за выручку) это значит: отчёт должен отвечать на вопросы “где теряем деньги” и “какие изменения реально двигают выручку”, а не только “что случилось с трафиком”.

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

Задача
Нужно было собрать единый управленческий отчёт в Looker Studio, где:
— одна модель метрик на весь путь пользователя (по ключевым событиям);
— прозрачная логика атрибуции (без “магии last-click”);
— разрезы по сегментам, источникам и этапам (lead quality по сути, но для travel — качество намерения к покупке);
— опора на инкрементальность: понимать, что именно приносит прирост, а не просто “перераспределяет” трафик внутри воронки.

Решение
1) Единый дата-март на события
В основу легла связка “событие → пользователь/сессия → источник → этап”. В Looker Studio подключили источники данных так, чтобы каждая строка в отчёте соответствовала одному этапу: просмотр/поиск, переход к бронированию, успешное подтверждение. Это убрало привычный разрыв: когда маркетинг считает конверсии от клика, а продукт — от более поздних событий.

2) Метрики в одном месте, а не в каждом графике
В отчёте ввели “каноничные” поля: конверсия этапа, доля потерь между этапами, выручка на пользователя по сегментам, а также валидирующие контрольные метрики (например, доля событий с нужным статусом). Важно: один и тот же расчёт применялся во всех вкладках, чтобы не было “в другой диаграмме иначе”.

3) Сегментация под управленческие решения
Сделали срезы, которые дают ответ на RevOps-вопросы:
— бренд/небренд (когда спрос формируется намеренно или “поднимается” контентом);
— устройства (мобильные сценарии чаще требуют донастройки UX/скорости);
— гео/язык (в некоторых рынках меняется качество намерения);
— источник трафика, сгруппированный по типам кампаний (чтобы не смешивать поисковый спрос и медийный прогрев в один поток).

4) Модуль “что изменилось”
Вместо “ещё один график динамики” добавили сравнение периодов и аннотации: запуск кампании/изменение сайта/партнёрская интеграция. Это помогло команде перестать спорить “почему просело” и перейти к проверке гипотез.

5) Принцип privacy-first: осторожность с атрибуцией
В отчёт встроили ограничение: last-click не используется как единственный ответ. Там, где важно решение, опирались на комбинацию моделей (по сути: доли конверсий и тренды инкрементальности/прироста) и контрольные срезы, чтобы исключать ситуации “кликнули сегодня — продали завтра, а данные не совпали”.

Результат
После внедрения управленческого отчёта команда получила:
— единый набор метрик, по которому руководители видят одну картину воронки (снижение времени на согласование цифр);
— рост качества управленческих решений за счёт анализа потерь не на уровне “CTR/клик”, а на уровне этапов, ведущих к выручке;
— ускорение цикла проверки гипотез: вместо недель на сбор разрозненных таблиц — анализ в Looker Studio “в тот же день”.
…