Server-side postback для Aviasales: как “дожать” атрибуцию в privacy-first мире

Server-side postback для Aviasales: как “дожать” атрибуцию в privacy-first мире

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

Задача
Нужно было перейти от модели “посчитали конверсии на сайте и радуемся” к модели, где можно:
— стабильно передавать конверсии в рекламные системы с учётом потерь идентификаторов
— корректно связывать события с пользователями до и после оплаты (booking/ticketing)
— отделить реальные покупки от “шумных” событий (например, просмотр без завершения)
— сделать postback воспроизводимым для разных рекламных платформ

Решение
Команда выстроила серверную передачу конверсий (server-side tracking) и postback-логику в несколько этапов.

1) Разделили источники событий
— Frontend собирал “сырьё”: page_view, begin_checkout, payment_intent, но не объявлял покупку финальной.
— Backend (сервер приложений) определял момент, когда покупка подтверждена: это важно, потому что фронт может не дождаться финального статуса.

2) Сформировали “конверсионный контракт”
Для оплаты/брони ввели единый набор полей, которые уходят в трекер и дальше в рекламные системы:
— event_name (например, Purchase)
— уникальный id брони (transaction_id / booking_id)
— сумма, валюта, тип продукта
— timestamp подтверждения оплаты
— параметры кампании/объявления (id, placement и т.п.)
Ключ: transaction_id использовали как ключ дедупликации.

3) Добавили дедупликацию и окна повторов
Частая проблема — дубль постбэков из-за ретраев сети или повторных статусов.
Логи на сервере фиксировали: если booking_id уже отправляли как Purchase — повтор не отправляем. Повторы допустили только для “предварительных” событий, где финал ещё может меняться.

4) Подключили постбэк так, чтобы он не зависел от браузера
Вместо “напрямую из браузера” сделали цепочку: сервер → conversion endpoint платформы.
С точки зрения приватности это сокращает зависимость от third-party идентификаторов и делает атрибуцию более устойчивой к ограничениям cookie.

5) Ввели контроль качества измерений
Перед массовой отправкой прогнали “сухой прогон”:
— сверка количества booking_id в трекере и в биллинге
— доля дублей (должна стремиться к нулю)
— доля покупок без корректного transaction_id
После запуска добавили мониторинг: если расхождение с биллингом растёт, событие помечается как “требует проверки”.

Результат
По публичным практикам рынка (и типичным эффектам таких внедрений в e-com/тревеле) ожидаемые метрики после корректного server-side postback выглядят примерно так:
— доля корректно сопоставленных purchase-событий выросла на 15–30% (за счёт устойчивости к потере идентификаторов и финализации на сервере)
— количество дублей конверсий снизилось в 2–5 раз (за счёт дедупликации по booking_id)
— качество оптимизации кампаний улучшилось: CPM/CPC часто не “падает навсегда”, но модель начинает получать меньше мусора и чаще обучается на реальных покупках
— управляемость в reporting: вы перестаёте спорить “почему в одном месте конверсия есть, а в другом — нет”, потому что везде один источник истины (подтверждённый статус на backend)

Урок
1) В 2026 атрибуция — не про “настроить пиксель”, а про измеримый контракт событий. Purchase должен быть *финальным статусом*, а не фронтенд-оптимизмом.
2) Postback без дедупликации почти всегда даёт ложный рост конверсий — это ломает и оптимизацию, и инкрементальность.
3) Если вы хотите уйти от last-click в privacy-first, делайте цепочку передачи событий воспроизводимой: сервер как точка истины, transaction_id как ключ, мониторинг как страховка.

— @AdOpsRoom