Programmatic Deep — RTB и header bidding

MOAT считает viewability и внимание, но не видит весь путь до конверсии

MOAT полезен там, где нужно отделить реальный показ от мусора: in-view, время в зоне видимости, exposure, иногда attention-сигналы. В programmatic это закрывает базовый вопрос — был ли шанс у креатива вообще быть замеченным.

Но у интеграции есть слепые зоны:
— MOAT не равен revenue quality: высокий viewability не гарантирует post-click/post-view ценность.
— Внутри медиафлоу легко потерять контекст: домен, placement, size, iframe nesting, refresh-policy.
— Если supply-path кривой, метрика будет честно измерять плохой инвентарь, а не исправлять его.

Важный момент для ad-ops: MOAT лучше читать вместе с bid stream и отчётами SSP/GAM. Ищите расхождения по placement ID, сопоставляйте render time, ad unit depth, invalid traffic flags и частоту refresh. Если viewability растёт после смены продавца, это не всегда победа — иногда просто поменялся mix инвентаря.

Для интеграции проверяйте три вещи:
— где стоит JS тег и не режется ли он CSP/iframe policy;
— передаются ли стабильные placement identifiers;
— совпадает ли логика counting с вашим waterfall / header bidding setup.

MOAT — это слой измерения, а не арбитр качества. Если не сверять его с supply-path и post-bid логикой, можно оптимизировать красивую метрику и оставить утечку денег в тех же местах.

OpenRTB 3.0 для арбитража: где ломается интеграция и теряется bid stream

OpenRTB 3.0 полезен не «как новый стандарт», а как более строгая схема для контроля источника, устройства и объекта запроса. В арбитражных связках это важно в двух местах: когда вы считаете supply-path и когда сверяете, почему один и тот же трафик уходит в разные аукционы.

Ключевые зоны проверки:
— source: цепочка реселла, идентификаторы площадки и посредников
— context и item: что именно продаётся, а не только «какой инвентарь»
— device/user: консистентность ID между SSP, wrapper и DSP
— regs: не терять consent/ограничения в промежуточных сервисах

Для арбитражной команды это означает простой чек-лист: не маппить 2.5-поля «по привычке», не выкидывать неизвестные объекты в parser, не нормализовать request до потери иерархии. Если в логах нет sourceid или ext обрезан на промежуточном сервере, SPO-аналитика становится шумом: вы видите win rate, но не видите маршрут денег.

На практике миграция почти всегда начинается не с bidder, а с логирования. Сначала снимите raw bid request, потом сравните, где именно теряются поля: в endpoint wrapper, в exchange adapter или в DSP-парсере. И только после этого переписывайте маппинг в конфиге.

Итог: OpenRTB 3.0 нужен не ради «поддержки стандарта», а ради более чистого bid stream. Если цепочка полей сохраняется end-to-end, проще резать мусорный supply и точнее считать, где утекает маржа.

Frequency capping cross-platform ломается не в DSP, а в identity stitching и окнах синхронизации

Если один и тот же юзер видит креатив в web, in-app и CTV, local cap на стороне канала почти всегда даёт утечку. Нужен единый счетчик на уровне decisioning layer, где к одному audience key привязываются события impressions, clicks и conversions.

Базовая схема:
— key: UID2 / RampID / first-party id, а если его нет — stable device graph id
— storage: KV с TTL, разбитый по campaign_id + user_key + window
— sync: online write после win notice, batch reconcile для delayed logs
— policy: отдельные caps по channel, geo и creative group, а не один глобальный лимит

Критичные ошибки:
— считать только cookie в browser: app и CTV выпадут из контроля
— обновлять счетчик на win bid, а не на confirmed impression
— не учитывать dedup по event_id: ретраи логов раздувают cap
— держать разные окна в разных системах без общего clock source

Если нужен строгий cross-platform cap, делайте server-side счетчик и версионируйте policy вместе с audience key. Иначе вы ограничите не частоту контакта, а только видимость ошибки.

Bid shading в DSP: где именно DSP режет цену и как не сломать аукцион

Bid shading — это не «магия снижения CPM», а корректировка bid price относительно вероятности победы и уровня конкуренции в конкретном auction. DSP берёт сырые сигналы из bid stream, оценивает clearing price и подаёт не максимальную готовность платить, а цену с запасом, чтобы не переплатить за тот же инвентарь.

Технически шейдинг обычно упирается в 3 слоя:
— входные фичи: geo, device, publisher, placement, time bucket, floor, deal/open auction;
— модель вероятности win: где цена победы зависит от спроса, floor и density конкурентов;
— policy-ограничения: нельзя шейдить так, чтобы просадить win rate на узких supply-path или в PMPs.

Ошибки появляются там, где DSP считает шейдинг по усреднённому рынку, а не по конкретному path. Тогда одна и та же ставка в двух SSP ведёт себя по-разному: в одном случае вы выигрываете почти всегда, в другом теряете объём из-за агрессивного floor или более дорогой конкуренции. Поэтому production-логика почти всегда должна учитывать seller, deal id, traffic quality и historical clearance curve.

Проверять шейдинг надо не только по win rate. Смотрите на revenue per mille для паблишера, post-shading conversion efficiency для рекламодателя, долю missed wins на high-value сегментах и расхождение между predicted clearing price и фактическим win notice. Если эти кривые расходятся, модель уже не описывает auction.

Итог простой: bid shading работает только тогда, когда DSP шейдит цену на уровне path + сегмент, а не «средней температуры по инвентарю».