Как читать changelog SSP/DSP, чтобы не сломать биддер на ровном месте

Как читать changelog SSP/DSP, чтобы не сломать биддер на ровном месте

Апдейт платформы — это не только «добавили формат». Для интеграции важнее, меняется ли контракт между сторонами: bid request, bid response, макросы, таймауты, billing events, причины no-bid.

Мини-чек-лист перед выкладкой:
— новые поля: optional или фактически required;
— deprecated-поля: когда перестанут приходить;
— enum-значения: не падает ли парсер на неизвестном;
— auction logic: менялись ли floor, first-price, deal priority;
— reporting: совпадает ли событие показа с billable impression.

Отдельно проверяйте backward compatibility. Хороший адаптер не должен ломаться от неизвестного поля в OpenRTB JSON. Плохой паттерн — строгая схема без allowlist/ignore для расширений ext.

Для байера главный риск — неверная интерпретация инвентаря и переплата. Для паблишера — потеря спроса из-за тихих no-bid после изменения параметров запроса.

Правило: любой changelog SSP/DSP сначала прогоняется через diff контракта, потом через sandbox/log replay, и только после этого — в прод.