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

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

OpenRTB 3.0 полезен не “новизной”, а тем, что жёстче описывает контекст запроса и уменьшает серые зоны между DSP, SSP и exchanges. Для арбитражной команды это значит одно: меньше магии в маппинге и больше полей, которые надо валидировать на входе.

Смотрите в первую очередь на:
— source/request: не теряете ли chain of custody и seller identity;
— site/app/device: не дублируются ли ключи при прокидке из wrapper;
— regs/user: не режется ли consent при трансформации в backend;
— imp: один инвентарь — один корректный impression object, без “склейки” разных placement.

Типовая ошибка в арбитраже — пытаться маппить 2.5-структуру в 3.0 “как есть”. В итоге bidder видит пустой publisher, ломается категоризация, а downstream-модели начинают покупать мусорный трафик как premium. Второй класс проблем — кастомные расширения, которые живут только в одном adapter’е и исчезают при SSP-роутинге.

Что проверить перед миграцией:
1) сверить JSON-схему входящего bid request и ответов bidder’ов;
2) логировать потери полей на каждом hop;
3) отдельно тестировать consent, device, ext и seller metadata;
4) не смешивать transport-слой и business-логіку в одном mapper.

Если хотите использовать OpenRTB 3.0 без деградации ROI, сначала стройте поле-поле аудит bidstream, а уже потом включайте новый формат в прод.