Postback, который “сломал” атрибуцию: как Aviasales восстановил цепочку конверсий в серверной аналитике

Postback, который “сломал” атрибуцию: как Aviasales восстановил цепочку конверсий в серверной аналитике

В 2026-м даже у белого performance случается системный фейл не в креативах, а в данных. Aviasales (публично известный игрок на поиске и метапоиске) столкнулся с типовой проблемой: пик показов и кликов рос, а качество и скорость оптимизации по лидам (заявка/переход в покупку) деградировали — модели обучались на неполных событиях. В эпоху privacy-first это особенно больно: last-click “прощает” многое, но server-side (серверная отправка) и postback (уведомления о событиях) требуют строгой связности.

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

Задача
Выявить, почему отчёты по “целевым” событиям разъехались с фактическими пользователями, и восстановить измеримость для оптимизации. Требования были инженерные: единый user/session key, консистентная временная логика и дедупликация (устранение дублей) в postback.

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

2) Контроль ключей и дедупликация
— Ввелись единые ключи на сервере: `client_id` + `session_id` + `event_fingerprint` (отпечаток события).
— В правила постбеков добавили дедуп по `event_fingerprint` и окно допустимой задержки. Практически: если подтверждение пришло повторно в пределах X минут — учитывали только первый валидный экземпляр.

3) Валидация “таймлайна”
— Проверили, что конверсия не отправляется раньше события просмотра/клика.
— Убрали из postback отправки “холодные” события, где не было связки с входным touchpoint (точкой касания). Это снизило шум в обучении.

4) Инкрементальная проверка (вместо веры в last-click)
— Для наиболее проблемных кампаний запустили тест измерения влияния (incrementality, инкрементальность): контрольные группы получали ограниченный показ, а сравнение строилось на серверных конверсиях и их распределении по когортам.

Результат
— Доля конверсий без связки ключей снизилась с **3,8% до 0,4%**.
— Количество дублей по постбеку упало на **67%** (по серверным метрикам, а не по кабинету).
— Время до “нормальной” оптимизации сократилось: модели/правила стали стабильнее, и целевое событие перестало “прыгать”.
— По итогам инкрементального блока оптимизация дала рост эффективности: **+12% к конверсиям при сохранении spend** на тестовом сегменте, а общий перекос атрибуции относительно серверной правды уменьшился.

Урок
— В 2026 performance выигрывают не те, у кого “больше пикселей”, а те, кто умеет инженерно гарантировать согласованность цепочки: ключи, таймлайн, дедуп, postback-валидация.
— Server-side и postback — это контракт данных. Нарушение контракта выглядит как “падение спроса”, хотя на деле падает измеримость.
— Если рекламная оптимизация чувствует себя нестабильно, первым делом проверяйте не креативы, а целостность: от touchpoint до подтверждённой конверсии, и только потом — аллокацию бюджета.

— @AdOpsRoom