<b>OpenRTB ломается не в протоколе, а в полях, которые вы заполнили «как-нибудь»</b>

<b>OpenRTB ломается не в протоколе, а в полях, которые вы заполнили «как-нибудь»</b>

В интеграциях чаще всего путают три слоя: обязательные поля запроса, расширения `ext` и локальные договорённости между SSP и DSP. Если `imp`, `site/app`, `device`, `user`, `tmax` и `cur` заполнены непоследовательно, а `badv`, `bcat`, `regs`, `source` живут отдельной логикой, аукцион начинает вести себя «странно» уже на уровне матчей.

Проверяйте базовый набор:
— `imp.id` должен быть стабилен внутри запроса и совпадать в ответе.
— `banner`/`video`/`native` не должны конфликтовать с реальным форматом места.
— `schain` и `supplychain` должны описывать реальный путь инвентаря, иначе buyer-side фильтры режут трафик.
— `device.ifa`, `ip`, `ua`, `consent` и `regs` надо передавать консистентно, без дублирования и подмен.

Отдельная зона риска — приоритеты. Если DSP ждёт `floor`, а SSP отдаёт его в нестандартном `ext`, вы получаете не ошибку, а молча проигранные показы. То же самое с `wseat`, `dealid`, `at`, `mimes`, `protocols`: формально запрос валиден, но bidding logic уже не сходится с ожиданиями интеграции.

Самый полезный чек-лист перед запуском: сверить JSON-схему, прогнать один и тот же запрос через логи SSP и DSP, сравнить нулевые ответы, 204 и bid responses. Если поле влияет на таргетинг, биллинг или privacy, оно должно быть задокументировано и одинаково трактоваться на обеих сторонах.