CDP в Aviasales: как связали поведение до покупки с ценностью после бронирования

CDP в Aviasales: как связали поведение до покупки с ценностью после бронирования

В 2026 году у многих e-com и маркетплейсов упирается не в «привести трафик», а в способность измерять эффект по всей цепочке: от поиска до удержания. Особенно больно это ощущают travel-платформы: длинные циклы принятия решения, повторные просмотры, влияние метапоиска и промо, плюс privacy-first атрибуция (server-side, инкрементальность) постепенно вытесняет last-click.

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

Задача
1) Собрать данные в Customer Data Platform (CDP) так, чтобы связать события “поиск/фильтрация/просмотр цены/клик по предложению” с исходом “бронь/оплата/отмена”.
2) Наладить корректную модель сегментации: разные типы намерений (например, “ищет и возвращается” vs “дошёл до оплаты”) должны получать разные сообщения и разные условия.
3) Перейти от атрибуции по клику к измерению влияния по когортам: нужно понимать, где маркетинг реально сдвигает вероятность брони, а где только “поймал уже готового”.

Решение
Подход строился вокруг трёх слоёв данных.

1) Identity resolution (разрешение идентичностей)
- Склеивание идентификаторов пользователя: device-id, cookie, аккаунт (если есть логин), а также утонение по событиям в рамках session/window.
- Добавили “событийный ключ” для маршрутов: чтобы один и тот же сценарий поиска не расползался по разным профилям из‑за изменения браузера/устройства.

2) Единая event-структура и каталог событий
- Описали минимальный набор событий с бизнес-смыслом: *search_performed, price_viewed, offer_opened, booking_started, booking_paid, booking_canceled*.
- Для каждого события закрепили параметры: география, направление, тип тарифа, стадия воронки, промокод/канал первичного касания (внутри своей системы, без “магии” last-click).

3) Revenue-слой поверх CDP
- В CDP сформировали таблицы “бронь как объект”: статус, сумма, валюта, время события, связка с поисковым контекстом.
- Далее — когортные витрины для маркетинга-операций: вероятность оплаты в зависимости от того, какие события и как часто повторялись до оплаты.

Практика сегментов и активаций
- Сегмент “высокое намерение” строили не по факту клика на объявление, а по последовательности событий: просмотр предложения → повторный возврат → старт бронирования в пределах окна N дней.
- Каналы и креативы оптимизировали под стадию: тем, кто “дошёл до оплаты”, — меньше промо-стимулов и больше снижения трения (условия, поддержка, прозрачность), тем, кто “только сравнивает”, — другой контент и напоминания.

Результат
После внедрения связки “поведение → бронь → ценность” компания смогла перейти к управлению не только конверсией, но и качеством потока:

— Поведенческие сегменты стали давать более стабильную предсказуемость вероятности оплаты по когортам (устранили проблему, когда один и тот же пользователь “переезжал” между сегментами из‑за разрывов identity).
— Маркетинг получил возможность считать lift инкрементальности на уровне групп пользователей: сравнение тех, кому показали кампанию, с контрольными группами по вероятности оплаты в окне после контакта (а не только по клику).
— Уменьшили долю решений “по ощущению” в performance: приоритет сместился на сценарии, которые реально повышают шанс оплаты, а не просто на каналы с высокой last-click конверсией.

Точные цифры в публичных релизах Aviasales обычно не раскрываются до уровня внедрения CDP, но логика измерения и воронки — типовой “рельс” CDP-проектов: ключ — когортные метрики и корректная склейка профилей, иначе любая инкрементальность разваливается.
…