OpenRTB ломается не в bid request, а на стыках полей и ожиданий сторон

OpenRTB ломается не в bid request, а на стыках полей и ожиданий сторон

OpenRTB часто считают «просто JSON для аукциона», но большинство багов появляется не в транспорте, а в семантике. Один и тот же объект у SSP, DSP и bidder’а может трактоваться по-разному: где-то поле optional, где-то обязано быть заполнено, где-то значение допустимо, но бизнес-логика его отбрасывает.

Проверьте базовые узлы интеграции:
— imp: совпадают ли тип инвентаря, размеры и приоритеты креатива;
— site/app: не смешиваются ли web и app-поля;
— device: корректны ли ua, ifa, ip и их fallback-поведение;
— regs и user: не теряются ли consent и privacy-сигналы при проксировании.

Отдельный класс проблем — нативка, видео и multi-format. Если обменник шлёт несколько форматов в одном imp, DSP должен явно понимать, какой креатив имеет право отвечать. Иначе вы получаете «валидный» bid, который не может быть отрендерен без кастомной логики на стороне ad server.

Ещё один чек: стабильность request/response на уровне идентификаторов. id, impid, bidid, seat и currency должны проходить трассировку без переименований и потерь. Если логирование не позволяет собрать цепочку целиком, дебажить аукцион почти невозможно.

Самый надёжный способ жить с OpenRTB — вести матрицу соответствий полей и контракт тестов на каждый exchange: что приходит, что обязательно, что можно игнорировать, а что должно падать в error, а не в silent fail.