OpenRTB ломается не на аукционе, а на кривом составе bid request

OpenRTB ломается не на аукционе, а на кривом составе bid request

OpenRTB — это не «просто JSON». В нормальной интеграции важны обязательные поля, согласованный floor, единицы измерения, тайминг и одинаковая трактовка device/site/app. Если SSP и DSP по-разному читают один и тот же запрос, дальше уже не помогает ни хороший bidder, ни сильный кабинет.

Проверьте базовые места:
— imp не должен приходить пустым;
— cur и price model должны совпадать между сторонами;
— app и site нельзя смешивать в одном запросе;
— ext используйте только для расширений, а не для критичных полей;
— schain, gpp, regs и user должны быть консистентны, иначе часть спроса просто отрежется.

Отдельный класс ошибок — неверная семантика идентификаторов. id, bidid, impid, seat, dealid должны жить как связанная цепочка, а не как набор случайных строк. Если теряется один ключ, постбек, антифрод и аналитика начинают расходиться между логами SSP и DSP.

Еще одна точка поломки — креатив и валидация ответа. Размеры баннера, типы медиа, VAST-структура, разрешенные протоколы и ограничения по duration должны проверяться до отправки в рендер. Иначе вы видите «bid win», но не видите показ.

Если вы интегрируете OpenRTB, думайте не про аукцион, а про контракты полей: чем строже валидация на входе и выходе, тем меньше фантомных win rate и странных расхождений в отчетах.