OpenRTB 3.0 для арбитража: где чаще всего ломают bidstream при миграции

OpenRTB 3.0 для арбитража: где чаще всего ломают bidstream при миграции

OpenRTB 3.0 полезен не «новой магией», а тем, что заставляет явно описывать supply chain. Для арбитражной команды это значит: меньше двусмысленности в request, больше контроля над тем, кто именно продаёт инвентарь и где теряется маржа.

Ключевые поля, на которые смотрят в первую очередь:
— source / schain: проверяйте полный путь до exchange и resellers
— item: не путайте с legacy impression-level логикой
— context: отделяйте page, app, connected TV и нестандартные форматы
— data: не тащите мусорные сегменты, если bidder их не использует

Для паблишера миграция упирается в нормализацию supply path. Если в 2.x у вас часть логики жила в ad unit naming и кастомных key-value, в 3.0 это надо вынести в явные объекты. Иначе bidder видит request, но не может корректно сопоставить inventory, floor и deal metadata.

Для DSP/SSP-интеграции типовая ошибка одна: ответ ещё строят как «impression-centric», а request уже «object-centric». В итоге ломаются mapping, deal matching и post-auction analytics. Проверяйте, чтобы auction id, seller identity и source chain совпадали в логах по всей цепочке.

Если вы ведёте арбитражный стек, миграцию лучше делать через параллельный парсинг 2.x и 3.0 на одном трафике: сравнить bid rate, no-bid причины и долю потерянных запросов. Потом уже резать legacy-ветку. Иначе потери прячутся не в CPM, а в несовпадении схемы.