SSP/DSP changelog: как отличить полезный апдейт от маркетингового шума

SSP/DSP changelog: как отличить полезный апдейт от маркетингового шума

Апдейт платформы стоит читать по месту в цепочке bid request → decisioning → billing. Если изменение не трогает поля запроса, аукцион, таргетинг, отчётность или деньги — для интеграции это низкий приоритет.

Проверяйте 5 точек:
— новые или удалённые поля в bid request/response;
— обязательность параметров: floor, deal ID, schain, consent;
— таймауты, throttling, QPS-limit;
— расхождение UI-метрик и log-level отчётов;
— fallback: passback, no-bid, default creative.

Отдельно фиксируйте, где именно изменение: SSP, DSP, exchange или wrapper. «Support for identity signal» может быть простым прокидыванием поля, а может менять match rate, frequency capping и deduplication.

Рабочее правило: каждый апдейт превращать в карту риска — какие endpoints затронуты, нужен ли regression test, меняются ли алерты, можно ли откатить фичу без релиза.

Финал: не внедряйте SSP/DSP-апдейты по описанию в кабинете. Сначала найдите объект данных и место, где он влияет на аукцион.