OpenRTB 3.0 для арбитража: где ломается bid request и как это ловить

OpenRTB 3.0 для арбитража: где ломается bid request и как это ловить

В 3.0 главный сдвиг — структура запроса становится объектной, а не плоской. Для арбитражной команды это означает одно: нельзя смотреть только на bid.price и device.ua, нужно валидировать связки source / seat / source.ext, user, regs и content как единый контракт.

— source: проверяйте цепочку supply chain, иначе SPO-отчёты будут врать.
— user: идентификаторы и сегменты могут жить в разных ветках; потеря одного поля не всегда видна в логах bidder’а.
— regs: consent и privacy-флаги нельзя просто прокинуть «как есть» из старого payload.
— imp: placement, format и ext должны совпадать с тем, что реально уходит в wrapper или SDK.

Практика простая: делайте mapping-слой между legacy 2.x и 3.0, а не «прямой прокид». Иначе часть трафика тихо уедет в no-bid из-за пустых обязательных объектов, а часть — в неверный floor, когда ext не распарсился на стороне bidder’а.

Если вы держите свои Prebid / SSP / DSP-интеграции на object-based модели, проверяйте не только наличие полей, но и их вложенность, типы и согласованность между source, user и imp. Тогда OpenRTB 3.0 перестаёт быть проблемой схемы и становится нормальным инструментом для чистого bid stream.