OpenRTB 3.0 для арбитража: какие поля ломают сопоставление bid stream и postbacks

OpenRTB 3.0 для арбитража: какие поля ломают сопоставление bid stream и postbacks

OpenRTB 3.0 полезен не «как новый формат», а как более жёсткая схема, где арбитражу приходится точнее связывать impression, source и device. Если вы сравниваете win rate, postback и revenue, смотрите не только на bidrequest, но и на то, как у вас проставлены source, seat, dspsource и auction context.

Главные места, где чаще всего теряются деньги:
— source / seller: при кривой атрибуции падает SPO-аналитика и начинается мусор в отчётах;
— device / ip / geo: если часть полей пустая, антифрод и сегментация расходятся с логикой DSP;
— regs / consent: бид может приходить, но монетизация режется на уровне фильтрации;
— content / inventory: без нормальной taxonomy ID невозможно нормально резать площадки.

Для паблишера и арбитражной команды правило одно: не пытайтесь «перевести» 3.0 как JSON-обёртку вокруг старых сущностей. Сначала проверьте, что у вас одинаково маппятся ad unit, placement, seller, source chain и auction type между wrapper, analytics и отчётами в DSP/SSP.

Если в логах есть расхождение между request-id и impression-id, ищите проблему в маппинге, а не в аукционе. OpenRTB 3.0 хорошо работает там, где у всех сторон один словарь полей; иначе это просто ещё один слой потерь.