Aviasales: как re-engagement в web push и in-app помог удержать пользователей, когда “первый клик” перестал ре

Aviasales: как re-engagement в web push и in-app помог удержать пользователей, когда “первый клик” перестал решать всё

В 2026-м логика маркетинга стала ближе к RevOps: выручка “едет” не только на отдел продаж, но и на поддержку и клиентский опыт. На этом фоне e-commerce и сервисы с высокой конкуренцией столкнулись с эффектом: средний чек снижается (люди экономят), а чистый acquisition всё чаще упирается в дорогую атрибуцию и перегрев креативов. У Aviasales это проявилось в том, что часть аудитории перестала возвращаться после поиска/просмотра без покупки, особенно после очистки части идентификаторов и смещения модели измерения в privacy-first (server-side, MMM, incrementality вместо last-click).

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

Задача
Сделать re-engagement (возвращение) для пользователей, которые:
— открывали результаты поиска или просмотрели подходящие варианты,
— но не совершили покупку/бронь,
— и при этом не хотели получать “пустые” пуши раз в день “просто потому что можно”.

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

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

2) Динамический триггер цены/условий
В коммуникациях использовали не “акции бренда”, а релевантные сигналы:
— изменение доступности/условий по маршруту (в рамках того, что приложение/сервис реально видит),
— напоминание “вернись к тому, что уже смотрел” с персональным контекстом.
Для web push добавили связку с переходом в конкретный экран, а не просто на главную.

3) Контроль частоты и частотные окна
Чтобы не превратить re-engagement в раздражитель, ввели:
— частотные лимиты по пользователю,
— разные окна доставки в зависимости от сегмента (например, тем, у кого уже были попытки покупки, показывали чаще в ближнем окне после ухода).

4) In-app как усилитель, а не дубль пушей
Push — триггер внимания, но in-app (внутри сессии) использовали для “дожима”:
— если пользователь открыл приложение после пуша, предлагали тот же сценарий, который он бросил,
— если не открыл — оставляли web push “мягким” напоминанием без давления.

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

Результат
По итогам внедрения (в одном из периодов тестирования) получили:
— рост конверсии повторного действия (возврат к бронированию) на 18% относительно исходной логики отправок,
— снижение доли отписок/жалоб на 22% за счёт точнее настроенных сегментов и контроля частоты,
— заметный прирост доли re-engagement пользователей среди тех, кто приносит выручку повторно (раньше большая часть этой ценности “терялась” между сессиями).

Если кратко: система перестала “стрелять по всем подряд” и начала догонять именно тех, кто завис на релевантном шаге в поиске.
…