SSP как “узкое горлышко”: как мы нашли причину падения дохода и стабилизировали postback

SSP как “узкое горлышко”: как мы нашли причину падения дохода и стабилизировали postback

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

Решение (разбор по слоям, как в инженерной диагностике):

1) Разделили “видимую” и “учётную” часть контура
— Сверили количество событий на стороне браузера (пиксель) и на стороне сервера (server-side сбор).
— Убрали из сравнения задержки: смотрели не на “сколько пришло сегодня”, а на когорту по времени клика/события.

Результат: обнаружили разрыв — часть заказов доходила в витрину аналитики, но не проходила в трекинг-систему как конверсия для оптимизации. То есть оптимизатор “видел меньше”, чем реально происходило.

2) Проверили postback пайплайн как систему с очередями
— Прогнали аудит цепочки: отправка postback → приёмник → обработчик → дедупликация → запись в витрину атрибуции.
— В логах у обработчика выделили класс ошибок: “несовпадение идентификаторов” (часть заказов приходила без нужного связующего ключа, который должен связывать click_id/session_id и заказ).

Контекст 2026: в privacy-first мире это часто проявляется как неустойчивое сопоставление между кликом и событием — особенно когда меняются cookie/consent-режимы или часть событий уходит в сервер раньше/позже, чем ожидает модель.

3) Нашли конкретный триггер ошибки
Оказалось, что в период обновления на одной из витрин произошла смена порядка вызова скриптов: событие “purchase” уходило до того, как модуль успевал подтянуть/сформировать нужный идентификатор для постбэка. На уровне UI всё выглядело корректно (покупка была в отчётах), но для ad-атрибуции ключ не проставлялся.

4) Зафиксировали архитектурно: “идентификатор до события” и дедупликация
— Перестроили серверную схему так, чтобы связующий ключ формировался до отправки purchase в трекинг-систему.
— Добавили жёсткую дедупликацию по order_id (чтобы при повторных отправках не раздувать конверсии).
— Поставили контрольные метрики на границе: доля purchase-ивентов без ключа, доля отклонённых postback, время доставки.

Конкретный результат (из фактуры кейса + измерение после фикса):
— Доля purchase-событий, которые уходили в postback без нужного связующего ключа, снизилась с 6.2% до 0.7% (по логам приёмника).
— В течение 10 дней доход с программатик закупки вернулся к уровню “до просадки” с последующей стабилизацией: -1…-2% относительно периода-эталона вместо -8…-12% в пик проблемы.
— Opt-метрики (конверсии для оптимизации) перестали расходиться с фактами в e-com-отчётах: разница между “сколько атрибутировали” и “сколько реально оплатили” сократилась в 3 раза.

Урок для читателя (что перенести в свой стек без фантазий):
— Всегда измеряйте связку “клик → событие → postback → запись в атрибуцию”, а не только итоговый отчёт. Если клики есть, а доход падает, первым делом проверьте *целостность идентификаторов* и *маршрут postback*.
— Разрыв чаще всего находится не в “SSP как источнике”, а в промежутке между purchase на витрине и конверсией, которую видит рекламная система.
— Контрольные метрики на границе (доля событий без ключа, доля отклонённых postback, задержка доставки) окупаются быстрее любых пересборок кампаний: вы чините не гипотезу, а данные.

Если хотите — могу описать чек-лист диагностики именно для server-side трекинга и postback (с какими логами/срезами начать, чтобы за 1–2 дня локализовать проблему).

— @AdOpsRoom

Параллельный взгляд на тему — @AImarketingTrendsRu