Почему SSP и DSP «не сходятся» на одном трафике — и где искать разрыв
У большинства расхождений одна и та же природа: SSP отдает поток по одной логике, DSP оценивает его по другой. На стыке ломаются сегментация, фильтры, частота и атрибуция, а в отчётах это выглядит как «потерянные показы» или «непонятный недобор».
Проверьте сначала базу: идентификаторы площадки и приложения, формат инвентаря, consent-поля, гео и язык, тип устройства, ad size, floor price. Если в bid request одно, а в логах SSP или post-bid другое — расхождение уже заложено до аукциона.
Дальше смотрите логику фильтров: DSP может резать по deal_id, creative attributes, app-ads.txt / ads.txt, schain, seller.json, domain / bundle, а SSP — по policy, brand safety и IVT. Частая ошибка — искать проблему в bidder, когда запрос не проходит валидацию на уровне exchange.
Для сверки полезен простой порядок: 1) request-level sampling, 2) сравнение win notice и render, 3) проверка match rate по каждому обязательному полю, 4) разбор, где именно пропадает цепочка: request → bid → win → impression. Если на одном из этапов нет консистентности, оптимизация ставки бессмысленна.
Вывод простой: сначала чините семантику запроса и отчётности, потом уже торгуйтесь за CPM. Когда SSP и DSP считают разные сущности, любой медиаплан превращается в спор о метриках.
AdTech Pulse — SSP / DSP / OpenRTB
@adtech_pulse_aff
Почему SSP и DSP «не сходятся» на одном трафике — и где искать разрыв
Этот пост опубликован в Telegram-канале AdTech Pulse — SSP / DSP / OpenRTB. Подписаться можно по ссылке: @adtech_pulse_aff.