OpenRTB ломается не на bid-response, а на плохом mapping полей

OpenRTB ломается не на bid-response, а на плохом mapping полей

OpenRTB — это не «один JSON на все случаи», а контракт между SSP и DSP. Самые частые поломки появляются там, где одна сторона заполняет поле «по смыслу», а другая ждёт строгое поведение: imp.id, placement, site/app, device, user, regs. Если хотя бы один ключевой объект пустой или дублируется, аукцион может пройти, но таргетинг, frequency capping и атрибуция начнут врать.

Проверяйте на интеграции три слоя:
— идентификаторы: request.id, imp.id, device.ifa, user.id;
— контекст: site vs app, publisher, domain, bundle, cat;
— права и ограничения: regs, consent, lmt, coppa, gpp.

Ещё одна типовая ошибка — смешивать обязательные и опциональные поля. Например, sending ext без понятной схемы не делает запрос «гибким»: DSP либо игнорирует его, либо начинает завязывать логику на нестабильный payload. Лучше держать ext только для реально согласованных расширений и документировать их отдельно от ядра OpenRTB.

Для отладки полезно сравнивать не только request, но и response: seatbid[].bid[].adm, nurl, burl, price, crid, cid. Если креатив не матчится с impression, ищите не в трейдинге, а в контракте полей, size, MIME, macros и допустимых доменах.

Если OpenRTB-интеграция «работает, но не даёт качества», первым делом проверьте семантику полей, а не биддер — в programmatic чаще ломается не аукцион, а договорённость о данных.