OpenRTB 3.0 для арбитража: где ломается маппинг и теряются деньги

OpenRTB 3.0 для арбитража: где ломается маппинг и теряются деньги

OpenRTB 3.0 полезен не “новыми словами”, а тем, что жёстче раскладывает запрос по сущностям: source, site/app, device, regs, user, content, auction. Для арбитражной команды это означает одно: если вы парсите bid stream как плоский JSON, часть сигналов уедет в null или в неверный namespace.

— Проверьте маппинг source: supply chain, schain, publisher, inventory source. Ошибка здесь ломает SPO-аналитику и сравнение путей.
— Отдельно разведите site/app: гибридные трафик-пулы часто теряют контекст и получают неверный bidfloor или таргетинг.
— Не тащите legacy-поля “как есть”: в 3.0 часть атрибутов живёт в вложенных объектах, а bidder response должен отражать ту же структуру, иначе win notice и billing расходятся.

Для арбитража критичны три проверки: совпадает ли source chain с sellers.json, не теряется ли consent/IFA в user/device, и совпадает ли auction type с тем, что ждёт downstream DSP. Если у вас mixed-stack с header bidding, любая нестыковка между Prebid adapter и OpenRTB-3 endpoint даёт скрытую потерю fill или CPM, которую в отчёте видно только как “просадку качества”.

Практика простая: заведите JSON-schema валидацию на входе, логируйте diffs между 2.x и 3.0, и тестируйте не только bid request, но и bid response/win notice как единый контракт. Тогда миграция перестаёт быть “переклейкой полей” и становится контролем экономии аукциона.