RevOps в BigQuery: как Aviasales связал маркетинг и выручку без last-click

RevOps в BigQuery: как Aviasales связал маркетинг и выручку без last-click

В 2026 год “чистого” direct/last-click уже не хватает: атрибуция становится privacy-first (server-side, инкрементальность, MMM), а классическая связка лид → MQL → SQL заметно проседает в B2B-логике и частично в e-commerce. На этом фоне Aviasales, будучи продуктом с сильной долей performance-каналов и долгим циклом решения, столкнулся с типовой проблемой: маркетинг видел заявки/переходы, но бизнес хотел понимать вклад кампаний в выручку и удержание (повторные бронирования, допродажи, “второй шаг”).

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

Решение
1) Единая модель событий в BigQuery
Aviasales построил таблицы событий в BigQuery с нормализацией полей: идентификатор пользователя/сессии, timestamp, источник (UTM/внутренний трекинг), параметры кампаний, действие на сайте/в приложении, и ключевые транзакционные события. Важный момент — разделили “сырые” логи и витрины:
— raw_* для неизменяемого источника
— mart_* для аналитики и расчётов

2) Server-side сбор и дедупликация
Чтобы не зависеть от потерь в браузерах и мобильных SDK, маркетинговые параметры стали приходить на сервер вместе с событиями. Дедупликация по event_id и контролями на временные окна уменьшила “размножение” конверсий. По внутренним проверкам это дало снижение расхождений между потоками трекинга на **до 30%** на уровне атрибутированных событий (в сравнении с прежней схемой на клиентских куках).

3) “Мост” к выручке: от клика к брони и повторным действиям
Бронь/платёж — отдельная сущность: Aviasales связал её с пользовательским путём через ключи и временные допуски (например, связывание по ближайшему релевантному действию в окне). Затем добавили модель жизненного цикла: первое бронирование → повтор → доп. сервисы, чтобы оценивать не только первичную конверсию, но и retention-эффект.

4) Инкрементальность и чистка канальных искажений
Вместо предположения “если конверсия выросла — канал принёс вклад” они стали мерить приращение (incrementality): A/B-кампании/holdout на уровне сегментов и контрольные группы, где возможно; остальное — оценка влияния через согласование с MMM (marketing mix modeling) для проверки здравого смысла по миксу. Это помогло уйти от переоценки last-click.

Результат
— Появился единый дашборд для RevOps: метрики по кампании стали считаться от событий до выручки и повторных действий, а не от клика.
— На практике рост эффективности оптимизаций подтвердился на отдельных когортах: при сохранении бюджета выручка по “инкрементальным” группам увеличивалась, тогда как кампании с “клик-влиянием без выручки” стали проседать в приоритете. В отчётах это выразилось как снижение доли кампаний с нулевым инкрементом и более точный подбор сегментов для масштабирования.
— Команда перестала спорить в терминах “у нас стало больше конверсий” и перешла к формулировкам “у нас стало больше выручки на инкрементальной группе”, что ускорило решения по бюджету.

Урок
1) BigQuery — это не “место для отчётов”, а слой, где вы фиксируете определения: событие, конверсия, выручка, связка с пользователем.
2) Переход от last-click к оценке влияния требует дисциплины: server-side сбор, дедупликация, окна атрибуции и валидация.
3) RevOps в 2026 выигрывает у изолированных воронок: когда маркетинг видит путь к выручке и retention, решения по миксу становятся быстрее и доказуемее.

Если хотите, в следующем посте разберу конкретно: какую схему таблиц (raw/mart) удобно собирать под связку “кампания → бронь → LTV” и как проверять целостность данных в BigQuery на примерах SQL-проверок.

— @BigQuery4MarketingPro