RevOps-отчёт в Looker Studio для Aviasales: как свели разрозненные воронки в один “источник правды” и перестал

RevOps-отчёт в Looker Studio для Aviasales: как свели разрозненные воронки в один “источник правды” и перестали спорить с цифрами

В 2026-м большинство маркетинг-команд упираются не в “где взять больше трафика”, а в вопрос: кто отвечает за выручку и на каком участке цепочки маркетинг реально влияет. Для Aviasales логика стала особенно важной из‑за природы продукта: пользователи могут пройти несколько касаний (поиск, брендовые запросы, рекламные каналы), а покупка/бронь — это лишь финальная точка. Если в отчётах нет единой модели, то каждая команда видит свою реальность: маркетинг — одно, performance — другое, продукт — третье.

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

Задача
Построить в Looker Studio управленческий отчёт в логике RevOps (маркетинг + продажи + customer success за общую выручку), который:
— собирает ключевые метрики в одном месте (не “по ведомствам”);
— даёт единые определения этапов воронки: просмотр/поиск → бронь/заказ → оплата;
— позволяет анализировать эффект каналов с учётом запаздывания конверсий;
— ускоряет принятие решений: меньше ручного экспорта, больше сравнения периодов и сегментов.

Решение
Команда Aviasales сделала отчёт не “витриной красивых графиков”, а рабочей моделью с обязательными проверками.

1) Единый слой данных (Data Model)
— События из продуктовой аналитики и рекламных кабинетов сводились через один календарь и единую временную зону.
— Конверсии “бронь/оплата” разносили по этапам: отдельно считали микроконверсии (например, старт сценария бронирования) и финальные (оплата).
— Для устранения дубликатов ввели ключ события (user/session + идентификатор попытки брони), чтобы повторные действия не раздували знаменатели.

2) Маппинг каналов под управленческие категории
Вместо “как пришло из UTM” сделали слой классификации:
— бренд (брендовые запросы и бренд-реклама);
— performance-каналы (небрендовые кампании);
— партнерские/реферальные источники (если применимо);
— direct/unknown (как отдельная категория с прозрачным правилом).

Критично: в отчёте было два режима — “как есть” (raw) и “управленческая группировка”. Так команда могла доверять данным и при необходимости проверять источник.

3) Аналитика с учётом задержек
Чтобы не сравнивать несопоставимое “сегодня показали — завтра купили”, в Looker Studio заложили модель окна атрибуции:
— метрики верхнего уровня (поиски/просмотры) считались по стандартному диапазону дат;
— метрики нижнего уровня (бронь/оплата) — с лагом и возможностью менять lookback-период в фильтрах отчёта.

4) “Срезы для решений”, а не для отчётности
На дашборде закрепили набор карточек, которые руководители реально используют:
— доля броней к ключевому шагу (бронь / старт бронирования);
— доля оплат к броням (оплата / бронь);
— стоимость шага (CPA по броням, если это релевантно) и стоимость финального шага (CPO по оплатам);
— вклад каналов в выручку/заказы (внутри одной модели группировок).

Важная деталь: вместо абстрактных “конверсия выросла” показывали конкретное изменение по датам и сегментам. Например, если performance-канал дал рост оплат, отчёт показывал, за счёт чего именно: растёт доля броней или улучшается оплата из броней.

5) Доверие к цифрам через контроль качества
В Looker Studio добавили блок “проверки целостности”:
— доля “unknown” по каналам не превышает порог;
— нет провалов в регистрации событий (gap-check);
— стабильность определений (например, одна и та же логика конверсии на всех страницах отчёта).
…