OpenRTB: какие изменения в спецификации ломают интеграции и отчётность

OpenRTB: какие изменения в спецификации ломают интеграции и отчётность

OpenRTB редко меняют «косметически». Обычно правки касаются полей, которые дальше цепляют DSP, SSP, трекеры и постбэки: ID, device, schain, user data, consent, floor, native-объекты.

Перед внедрением новой версии или расширения проверьте три слоя:
— какие поля стали обязательными или deprecated;
— не поменялась ли семантика значений, а не только названия;
— поддерживают ли это оба конца цепочки, а не только одна сторона.

Отдельно смотрите на идентификаторы и приватность. Если в запросе меняется формат device/user IDs или правила передачи consent, ломаются матчи, частота, антифрод и склейка событий. На бумаге аукцион проходит, но в отчётах появляется расхождение, которое потом принимают за «просадку трафика».

Безопасный порядок внедрения такой: сначала тестовый supply-path, потом валидация логов, затем сверка win rate и postback-атрибуции. Любая новая сущность в OpenRTB должна пройти через маппинг на уровне схемы, а не руками в интерфейсе.

Если спецификацию не прогнать через логи и сверку событий, ошибка всплывёт не в интеграции, а в деньгах.