<b>OpenRTB 3.0 ломает привычный bidstream: где у арбитражника начнутся интеграционные ошибки</b>

<b>OpenRTB 3.0 ломает привычный bidstream: где у арбитражника начнутся интеграционные ошибки</b>

OpenRTB 3.0 — это не «ещё один JSON». В версии меняется сама модель запроса: вместо россыпи плоских полей появляется более строгая структура `source` / `request` / `item` / `data`. Для тех, кто привык парсить `imp[]` и искать всё в одном объекте, это означает перепроверку маппинга на каждом слое.

Главное для арбитражной команды:
— `source` и `ext` больше нельзя воспринимать как свалку для произвольных полей;
— `item` ближе к конкретному инвентарю и условиям сделки, чем старый `imp`;
— идентификаторы и контекст часто переезжают в более вложенные блоки, и старый code path может тихо терять значения;
— если у вас middleware между SSP и bidder, он должен уметь валидировать схему, а не только логировать payload.

Типовая ошибка — пытаться «подружить» 3.0 с 2.x через простую трансформацию ключей. Это работает только для части полей. В реальности ломаются deal-условия, price floors, device/user-метаданные и трекинг атрибуции, если не обновить schema mapping целиком.

Что проверить до миграции:
— поддерживает ли ваш bidder/adapter именно OpenRTB 3.x schema;
— есть ли в логах отдельная валидация `source` и `item`;
— не теряются ли `schain`, consent, supply metadata и deal IDs при конвертации.

Если у вас в стеке есть кастомный parser, OpenRTB 3.0 лучше считать не апдейтом, а отдельным контрактом. Иначе поломка будет не в аукционе, а в вашем маппинге.