Server-side postback в Aviasales: как вылечили «провалы» в атрибуции и вернули управляемость расходами

Server-side postback в Aviasales: как вылечили «провалы» в атрибуции и вернули управляемость расходами

Aviasales — хороший пример того, как в 2026 году меряется не «красота отчётов», а способность системы принимать решения в реальном времени. Рынок дорос до privacy-first: часть событий перестаёт доходить через классические пиксели из браузера. Параллельно растёт роль сервера-атрибуции, incrementality и постбэков (передача итогового события/результата из CRM обратно в рекламные контуры).

Контекст
В один из периодов Aviasales столкнулся с типичной для performance-уровня проблемой: по части рекламных источников лиды и покупки в отчётах выглядели заниженными. На уровне кабинетов это проявлялось так:
— доля «незаполненных» значений по воронке (от клика до подтверждённого бронирования) выросла
— оптимизация шла по неполным сигналам, CPA (стоимость события) «плавал» без связи с реальностью
— маркетинг и аналитика спорили о причинах, но решения принимались вслепую

Задача
Нужно было:
— восстановить корректность атрибуции после потерь в browser-side событиях
— унифицировать postback: чтобы одно и то же событие везде имело сопоставимые идентификаторы
— дать алгоритмам (и людям) сигнал качества: покупка/бронь только после фактического результата, а не по «предварительным» прокси-событиям
— сделать это так, чтобы система не деградировала при изменениях в браузерах и настройках согласий

Решение
Команда построила server-side цепочку событий и постбэк-слой поверх собственной инфраструктуры:
— Веб-события продолжали собираться, но «истина» переносилась на сервер: пользовательские идентификаторы привязывались к сессии и сохранялись в первой точке контроля.
— Сервер отправлял провайдерским контент- и конверсионные события не из браузера напрямую, а через прокси-эндпоинт. Это позволило стабилизировать доставку и ретраи.
— Postback на покупку/бронь уходил только после подтверждения в бэкенде Aviasales: то есть в атрибуцию попадал результат, а не намерение.
— Дальше включили правила дедупликации по ключу события (user/session + событие + временное окно), чтобы исключить двойной учёт при ретраях и повторных нажатиях.
— Для контроля качества добавили мониторинг: доля принятых postback, задержка до подтверждения, доля дублей, доля «некоррелированных» событий.

Результат
После внедрения измерения стали «сшитыми»:
— конверсионные события стали приходить с меньшей дисперсией по источникам (пропуски снизились, оптимизация перестала ориентироваться на шум)
— исчезла часть расхождений между данными рекламных кабинетов и внутренней отчётностью: postback начал отражать фактические брони
— управляемость расходов выросла: команды увидели, какие кампании действительно генерируют подтверждённый спрос, а какие — только клики/визиты

Если перевести на инженерный язык: пропали разрывы между *event* и *outcome*. Вместо “кто-то что-то нажал” система стала отвечать “кто-то довёл до результата”.

Урок
1) Пиксель сам по себе — это не аналитика. Аналитика — это согласованная цепочка идентификаторов и подтверждённый outcome, зафиксированный на сервере.
2) Postback нужно проектировать как продукт: с дедупликацией, мониторингом и SLA по доставке. Иначе вы просто масштабируете ошибку.
3) В privacy-first эре качество сигналов важнее количества: лучше меньше событий, но с высокой корреляцией с внутренней истиной.
4) RevOps-логика (маркетинг + продажи + customer success за выручку) требует, чтобы конверсия считалась там, где она становится бизнес-результатом — в момент подтверждения брони, а не на первом действии пользователя.

Если хотите, могу накидать чек-лист аудита postback для вашего кейса: какие поля обязаны быть, где ловятся дубль/дрифт, и как поставить контрольные метрики так, чтобы ошибки видны были раньше, чем их увидят финансы.

— @AdOpsRoom