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

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

OpenRTB редко меняют «по-крупному» одним релизом. Обычно ломают не заголовки, а поля: обязательность, типы, вложенность, трактовку пустых значений и новые объекты в bid request/bid response.

Смотреть нужно на четыре вещи:
— какие поля стали required и где допускается fallback;
— не поменялся ли формат идентификаторов, enum и массивов;
— не добавили ли новый объект, который старый парсер молча режет;
— совпадает ли трактовка privacy, consent и seller chain у bidder и SSP.

Если спецификация добавляет extension, это не значит, что можно игнорировать его сразу. Для части площадок новый объект сначала необязателен, а потом внезапно становится условием для нормального матчингa или таргетинга.

Перед внедрением проверяют не только код, но и логику аукциона: как обрабатываются empty values, дубли, unknown fields, timeout, multi-format и multi-size. Большая часть инцидентов возникает не из-за самой спецификации, а из-за того, что одна сторона читает поле строго, а другая — «на глаз».

Если держать отдельный слой парсинга и валидации под OpenRTB, интеграции переживают обновления без ручного переписывания всей связки.