OpenRTB 3.0 для арбитража: где ломается интеграция и теряется bid stream

OpenRTB 3.0 полезен не «как новый стандарт», а как более строгая схема для контроля источника, устройства и объекта запроса. В арбитражных связках это важно в двух местах: когда вы считаете supply-path и когда сверяете, почему один и тот же трафик уходит в разные аукционы.

Ключевые зоны проверки:
— source: цепочка реселла, идентификаторы площадки и посредников
— context и item: что именно продаётся, а не только «какой инвентарь»
— device/user: консистентность ID между SSP, wrapper и DSP
— regs: не терять consent/ограничения в промежуточных сервисах

Для арбитражной команды это означает простой чек-лист: не маппить 2.5-поля «по привычке», не выкидывать неизвестные объекты в parser, не нормализовать request до потери иерархии. Если в логах нет sourceid или ext обрезан на промежуточном сервере, SPO-аналитика становится шумом: вы видите win rate, но не видите маршрут денег.

На практике миграция почти всегда начинается не с bidder, а с логирования. Сначала снимите raw bid request, потом сравните, где именно теряются поля: в endpoint wrapper, в exchange adapter или в DSP-парсере. И только после этого переписывайте маппинг в конфиге.

Итог: OpenRTB 3.0 нужен не ради «поддержки стандарта», а ради более чистого bid stream. Если цепочка полей сохраняется end-to-end, проще резать мусорный supply и точнее считать, где утекает маржа.