OpenRTB ломается не в коде, а на стыке полей, таймингов и допущений

OpenRTB ломается не в коде, а на стыке полей, таймингов и допущений

OpenRTB — это не «один JSON для всех», а контракт между DSP, SSP и exchange. Ошибка обычно не в самом bidder’е, а в том, что одна сторона заполняет поле по умолчанию, а другая трактует его как обязательное. Самые частые зоны риска: imp, site/app, device, user, regs и ext.

Проверьте три вещи перед интеграцией:
— есть ли у вас единый маппинг полей и их приоритетов;
— совпадает ли логика для web, in-app и CTV;
— одинаково ли вы обрабатываете пустое поле, null и отсутствие ключа.

Отдельно смотрите на timeout, seatbid и deals. Если таймауты на стороне DSP и SSP не согласованы, вы теряете ответы без видимой ошибки. Если dealid есть в запросе, но price floor или targeting не совпали, bid может формально быть валидным и фактически не выиграть. В OpenRTB это обычная история: протокол ответил, а сделка не собралась.

Хорошая интеграция — это когда каждый обязательный атрибут имеет одно значение по умолчанию, а все спорные поля описаны в спецификации маппинга. Тогда отладка превращается не в гадание по логам, а в проверку конкретного узла цепочки.