Header bidding и DSP-стек: что проверить до запуска, чтобы не потерять выкуп

Header bidding и DSP-стек: что проверить до запуска, чтобы не потерять выкуп

Header bidding часто ломается не на уровне кода, а на стыке таймаутов, приоритетов и маппинга инвентаря. Если запросы уходят в аукцион, но DSP видит не тот сегмент или пустой слот, bid request считается, а показ уходит в direct или в fallback.

Проверяйте базу:
• один ли и тот же placement ID во всех связках;
• не режет ли таймаут победителя более быстрый line item;
• совпадают ли floor price, deal ID и креативные размеры;
• не конфликтуют ли server-side и client-side цепочки в одном стеке.

В DSP-стеке чаще всего теряются не деньги, а атрибуция. Если postback, macro и click ID живут в разных шаблонах, вы видите расхождение между выигранными аукционами и фактическими конверсиями. Отдельно смотрите на frequency cap, viewability и blacklist по доменам: эти фильтры могут срезать объём сильнее, чем кажется по отчету.

Для диагностики полезно идти от одного слота: запрос, bid response, победа, рендер, событие, postback. Любой разрыв между этими точками — повод проверять не креатив, а маршрут данных. Если стек сложный, фиксируйте его схему до теста: кто отдаёт bid, кто назначает приоритет, кто пишет конверсию.

Чем прозрачнее цепочка от аукциона до постбэка, тем меньше ложных выводов о «плохом трафике» и «слабом DSP».