<b>Prebid 9: что ломается в конфиге и как пройти миграцию без просадки fill</b>

<b>Prebid 9: что ломается в конфиге и как пройти миграцию без просадки fill</b>

Главные точки риска — bidder API, timeout logic и кастомные hooks в wrapper’е. Если у вас сидят адаптеры с ручной обработкой bidResponse, первым делом проверьте поля, которые вы прокидываете в auction: часть legacy-схемы уже не должна быть «тихим дефолтом». Второй слой — consent и schain: если они собираются на лету, любая нестыковка в порядке мидлварей даёт пустые запросы или деградацию CPM.

Что сделать до выката:
— снять inventory по всем bidder’ам и отметить те, что завязаны на старый response object;
— прогнать тестовый auction с full logging: request, bid, render, win notice;
— сравнить timeout по гео и device, отдельно для slow bidders;
— проверить, не дублируются ли user sync и identity modules.

Отдельно смотрите на Prebid Server: если у вас гибридная схема, breaking changes часто проявляются не в JS-wrapper, а в server-side chain. Типовая ошибка — обновили фронт, но оставили старый contract на стороне adapter mapping: в bid stream это выглядит как «есть запрос, нет валидного бидa».

Переход делайте через canary: один slot, один geo, один набор bidder’ов. Сначала добейтесь идентичного win rate и только потом расширяйте поверхность. Иначе вы не поймёте, где именно отвалился auction: в timeout, в identity, в adapter mapping или в rendering.