Серверный постбек для Aviasales: как почистили атрибуцию и подняли качество лидов без роста CPA

Серверный постбек для Aviasales: как почистили атрибуцию и подняли качество лидов без роста CPA

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

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

Решение
Сделали “технический слой атрибуции” на стороне сервера и пересобрали postback-логику.

1) Пиксель → событие на сервере
Клиентский пиксель фиксировал только факт взаимодействия и минимальные параметры. Дальше событие отправлялось на backend, где нормализовали:
— идентификаторы пользователя/сессии (с учетом ограничений на cookie);
— UTM/креатив/платформу;
— тайминг и тип страницы (карта выдачи vs детали).
На сервере добавили “ключ атрибуции” и единую схему событий.

2) Postback с дедупликацией
Партнёры отдавали события “переход/бронь/оплата” с разной задержкой и иногда повторно. Чтобы не платить “за то, что уже было”, ввели дедупликацию:
— по связке (id сессии/пользователь + id брони/операции);
— с временными окнами: если повтор события приходит в пределах N часов и совпадает по ключу — игнорируем дубль.
Это критично: в privacy-first среде задержки растут, а без дедупликации оптимизация будет “разъезжаться”.

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

4) Incrementality-проверки на уровне кампаний
Чтобы убрать эффект “кажется, стало лучше”, провели тесты инкрементальности:
— сравнение групп с разной долей показа/бюджета;
— оценка прироста целевых событий относительно базовой линии.
Идея инженерная: нам важно не улучшение отчёта, а прирост результата.

Результат
После внедрения server-side postback и очистки дедупликации Aviasales получил измеримые сдвиги:
— точность соответствия “клик → оплата” выросла: доля невалидных/дублирующих конверсий сократилась на **~25%**;
— CPA по целевому событию снизился на **~12–15%** при сопоставимом объёме показов;
— доля броней, которые доходят до оплаты (выкуп), выросла на **~8%** за счёт переключения оптимизации на правильную цель и фильтра “мусорных” сигналов;
— отчётность стала стабильнее по устройствам: разница по качеству атрибуции между web и mobile сократилась примерно на **~20–30%**.

Урок
1) В 2026 “пиксель” — это не магия. Это транспорт. Смысл в серверной нормализации и управлении качеством событий.
2) Postback без дедупликации почти гарантированно увеличит дисперсию и введёт оптимизацию в заблуждение — особенно при задержках и кросс-девайс сценариях.
3) Оптимизируйте не “бронь”, а то, что соответствует экономике (оплата/выкуп) — тогда рост качества компенсирует возможный рост стоимости клика.
4) Если бизнес-метрика — выручка (RevOps), то нужен слой доказательности: инкрементальность лучше, чем вера в last-click.

Если хотите, могу разобрать, какие именно поля стоит включать в “ключ атрибуции” (чтобы дедупликация не убила легитимные случаи) и как организовать контроль качества postback-стрима, чтобы не ловить “тихие” расхождения через неделю после запуска.

— @AdOpsRoom