OpenRTB 3.0 ломает привычный bidstream: где арбитраж чаще всего теряет деньги

OpenRTB 3.0 ломает привычный bidstream: где арбитраж чаще всего теряет деньги

OpenRTB 3.0 для performance-команд — не «новый JSON», а другая модель запроса. Если в интеграции остались ожидания от 2.x, сначала проверьте, где у вас живут source, context и data: в 3.0 они разнесены по объектам, и часть сигналов перестаёт быть «наследуемой» по умолчанию.

Три зоны риска в арбитраже:
— маппинг placement/site/app: если источник трафика собран криво, bidder видит не тот инвентарь и режет bid;
— user-идентификаторы: не все ID должны идти в каждый запрос, иначе растёт шум и падает match;
— schain и supply chain: без корректной цепочки сложнее отлавливать лишние hops и скрытые реселлы.

Для паблишера и медиабаера полезен один чек-лист: сверить обязательные блоки request/response, отдельно протестировать lossless-миграцию полей из 2.x, а потом сравнить bid density до и после на одном и том же placement set. Если меняется fill, смотрите не только в DSP, но и в структуру самого request.

Ещё одна типовая ошибка — пытаться «протолкнуть» в 3.0 старую логику waterfall. В 3.0 лучше работает дисциплина: минимальный набор сигналов, корректный schain, чистый taxonomy и предсказуемый consent path. Тогда bidstream становится короче, а SPO — измеримее.