ROAS attribution в programmatic ломается не в модели, а в отчётном фреймворке
Считать ROAS по last click в programmatic — значит смешать auction signal, post-view и post-click в одну корзину. Для нормальной отчётности сначала фиксируйте границы: окно атрибуции, тип конверсии, уровень агрегации и то, какие события вообще попадают в расчёт.
Базовый фреймворк:
— separate отчёты по post-click и post-view;
— один primary KPI на срез: revenue, orders или LTV;
— раздельно считать incremental lift и ассисты, не склеивая их в ROAS;
— помечать traffic source, exchange, deal id, placement, device и geo.
Дальше нужен контроль качества данных. Если в цепочке нет стабильных click_id / impression_id, а postback приходит с задержкой, ROAS начинает мигрировать между каналами из-за latency, а не из-за эффективности. Для этого полезны cohort-отчёты по дате показа и отдельный view-through sanity check: доля view-through не должна расти без изменения медиасплита.
На уровне анализа держите три слоя: campaign-level для бюджета, supply-path для площадки, creative-level для креатива. Когда один слой показывает рост, а другой падение, смотрите не на средний ROAS, а на распределение по placements и frequency. Именно там обычно прячется переатрибуция.
Если хотите управлять ROAS, а не спорить о нём, сначала сделайте отчётность несмешиваемой: одно событие — один контур, одна логика окна, одна версия truth source.
Считать ROAS по last click в programmatic — значит смешать auction signal, post-view и post-click в одну корзину. Для нормальной отчётности сначала фиксируйте границы: окно атрибуции, тип конверсии, уровень агрегации и то, какие события вообще попадают в расчёт.
Базовый фреймворк:
— separate отчёты по post-click и post-view;
— один primary KPI на срез: revenue, orders или LTV;
— раздельно считать incremental lift и ассисты, не склеивая их в ROAS;
— помечать traffic source, exchange, deal id, placement, device и geo.
Дальше нужен контроль качества данных. Если в цепочке нет стабильных click_id / impression_id, а postback приходит с задержкой, ROAS начинает мигрировать между каналами из-за latency, а не из-за эффективности. Для этого полезны cohort-отчёты по дате показа и отдельный view-through sanity check: доля view-through не должна расти без изменения медиасплита.
На уровне анализа держите три слоя: campaign-level для бюджета, supply-path для площадки, creative-level для креатива. Когда один слой показывает рост, а другой падение, смотрите не на средний ROAS, а на распределение по placements и frequency. Именно там обычно прячется переатрибуция.
Если хотите управлять ROAS, а не спорить о нём, сначала сделайте отчётность несмешиваемой: одно событие — один контур, одна логика окна, одна версия truth source.
This media is not supported in your browser
VIEW IN TELEGRAM
Google заставляет махать руками перед камерой
Google запустила новую капчу на основе распознавания движений — требует включённую камеру и помах руки перед экраном для подтверждения. Система отслеживает 21 точку-координату положения руки в реальном времени, а данные удаляются сразу после проверки. Для арбитражников это усложнит автоматизацию — обход вероятно будет работать через перехват хэша с положительным ответом. Капча пока на тестировании, но предвещает новый уровень защиты от ботов в и…
➡️ Читайте на сайте: https://aff.top/blog/google-zastavliaet-makhat-rukami-pered-kameroi
🧠 Ещё больше инсайтов → в канале AFF.top
Google запустила новую капчу на основе распознавания движений — требует включённую камеру и помах руки перед экраном для подтверждения. Система отслеживает 21 точку-координату положения руки в реальном времени, а данные удаляются сразу после проверки. Для арбитражников это усложнит автоматизацию — обход вероятно будет работать через перехват хэша с положительным ответом. Капча пока на тестировании, но предвещает новый уровень защиты от ботов в и…
➡️ Читайте на сайте: https://aff.top/blog/google-zastavliaet-makhat-rukami-pered-kameroi
🧠 Ещё больше инсайтов → в канале AFF.top
Логи RTB: какие поля сохранять, чтобы потом не гадать по CPM и fill
Если сохраняете только bid price и win notice — аналитика ломается на первом же спорном кейсе. Для разбора аукциона нужен не «лог события», а связка request → response → render.
В базовый набор кладите: request id, auction id, timestamp, publisher/app/site, placement/ad unit, imp id, floor, currency, device, geo, user agent, consent string, schain, ads.txt path, bidder name, timeout, bid price, net/gross, deal id, creative id, loss reason, win reason. Без request/imp id вы не склеите цепочку, без schain и floor не разберёте SPO и price pressure.
Отдельно храните контекст, который часто теряют: language, referrer, viewability signals, cache status, render fail, timeout bucket, no-bid reason, error code от adapter’а, response latency, seat id, domain/app bundle, consent status, user sync status. Именно эти поля объясняют, почему одинаковый placement даёт разный revenue.
Практика простая: raw-логи храните отдельно от агрегатов, нормализуйте названия полей, и не режьте «лишнее» до того, как построите дашборды по latency, bid density, win rate и loss reason. Тогда разбор деградации займёт минуты, а не ручной ресёрч по трём системам.
Если сохраняете только bid price и win notice — аналитика ломается на первом же спорном кейсе. Для разбора аукциона нужен не «лог события», а связка request → response → render.
В базовый набор кладите: request id, auction id, timestamp, publisher/app/site, placement/ad unit, imp id, floor, currency, device, geo, user agent, consent string, schain, ads.txt path, bidder name, timeout, bid price, net/gross, deal id, creative id, loss reason, win reason. Без request/imp id вы не склеите цепочку, без schain и floor не разберёте SPO и price pressure.
Отдельно храните контекст, который часто теряют: language, referrer, viewability signals, cache status, render fail, timeout bucket, no-bid reason, error code от adapter’а, response latency, seat id, domain/app bundle, consent status, user sync status. Именно эти поля объясняют, почему одинаковый placement даёт разный revenue.
Практика простая: raw-логи храните отдельно от агрегатов, нормализуйте названия полей, и не режьте «лишнее» до того, как построите дашборды по latency, bid density, win rate и loss reason. Тогда разбор деградации займёт минуты, а не ручной ресёрч по трём системам.
This media is not supported in your browser
VIEW IN TELEGRAM
Как заработать 2500$ с УБТ трафика из Twitter’а не привлекая внимания санитаров
Арбитражник проkил органическbq трафик с X (Twitter) через связку с dating-офферами, используя маскировку ссылок под видеопревью. После полугода залива с марта по октябрь 2025-го он заработал скромный, но стабильный доход, внедрив динамическую генерацию страниц, обфускацию ссылок и cookie-разделение трафика для увеличения конверсии на треть. Основной вызов — постоянные баны доменом из-за обновлений Google и требований антифрода, из…
➡️ Читайте на сайте: https://aff.top/blog/kak-zarabotat-2500-s-ubt-trafika-iz-twitter-a-ne-privlekaia-vnimaniia-sanitarov
🧠 Ещё больше инсайтов → в канале AFF.top
Арбитражник проkил органическbq трафик с X (Twitter) через связку с dating-офферами, используя маскировку ссылок под видеопревью. После полугода залива с марта по октябрь 2025-го он заработал скромный, но стабильный доход, внедрив динамическую генерацию страниц, обфускацию ссылок и cookie-разделение трафика для увеличения конверсии на треть. Основной вызов — постоянные баны доменом из-за обновлений Google и требований антифрода, из…
➡️ Читайте на сайте: https://aff.top/blog/kak-zarabotat-2500-s-ubt-trafika-iz-twitter-a-ne-privlekaia-vnimaniia-sanitarov
🧠 Ещё больше инсайтов → в канале AFF.top
Prebid 9: какие изменения ломают конфиги и как пройти миграцию без сюрпризов
Если у вас живёт большой wrapper, проверяйте не только adUnits, но и весь контракт между page code, bidderAdapter и analytics. В Prebid 9 чаще всего больно не там, где “сломался бид”, а там, где тихо меняется форма данных и старые допущения уже не проходят.
Что обычно требует ревизии:
— bidder params: строгая валидация, мусорные поля лучше вычищать до релиза;
— events / hooks: если завязаны на кастомные тайминги, проверьте порядок вызовов;
— user sync и consent: CMP-логика должна быть явной, без неочевидных fallback’ов;
— floors / timeout / schain: убедитесь, что значения доходят до bidder без обрезки.
Переходный план простой: сначала прогоняете текущий конфиг через тестовый стек и смотрите, где валится schema validation. Потом сравниваете bid stream до и после миграции: количество bid responses, no-bid, timeout, cache hit. Отдельно проверяете adapters, которые живут на кастомных параметрах или нестандартных event listeners.
Если в wrapper есть свои плагинные слои, не тащите их “как есть”: лучше оставить минимальный core, а всё нестандартное вынести в отдельный модуль с явными контрактами. Так обновление Prebid перестаёт быть лотереей и становится обычной заменой зависимостей.
Если у вас живёт большой wrapper, проверяйте не только adUnits, но и весь контракт между page code, bidderAdapter и analytics. В Prebid 9 чаще всего больно не там, где “сломался бид”, а там, где тихо меняется форма данных и старые допущения уже не проходят.
Что обычно требует ревизии:
— bidder params: строгая валидация, мусорные поля лучше вычищать до релиза;
— events / hooks: если завязаны на кастомные тайминги, проверьте порядок вызовов;
— user sync и consent: CMP-логика должна быть явной, без неочевидных fallback’ов;
— floors / timeout / schain: убедитесь, что значения доходят до bidder без обрезки.
Переходный план простой: сначала прогоняете текущий конфиг через тестовый стек и смотрите, где валится schema validation. Потом сравниваете bid stream до и после миграции: количество bid responses, no-bid, timeout, cache hit. Отдельно проверяете adapters, которые живут на кастомных параметрах или нестандартных event listeners.
Если в wrapper есть свои плагинные слои, не тащите их “как есть”: лучше оставить минимальный core, а всё нестандартное вынести в отдельный модуль с явными контрактами. Так обновление Prebid перестаёт быть лотереей и становится обычной заменой зависимостей.
Curated marketplaces: где SSP режет long tail и зачем это паблишеру
Curated marketplace — это не «приватка с красивым названием», а отбор инвентаря и данных поверх open auction. SSP собирает supply, сегменты, правила доступа и продаёт пакет не по всему трафику, а по заранее описанному набору: домены, app bundle, geo, device, viewability, audience. Для buyer это меньше мусора в bid stream, для publisher — выше контроль над тем, кто вообще видит inventory.
Рабочая схема обычно такая: — curated пакет живёт как deal ID или отдельный PMPslot; — в deal попадают whitelist/blacklist, floor, format, allowed buyers; — иногда добавляют audience overlay из clean room или DMP. Главное тут не «премиальность», а предсказуемость: меньше SSP hops, меньше случайных bidders, меньше дублей между каналами.
Где curated marketplace полезен:
— на дорогом инвентаре, который нельзя отдавать в общий аукцион без фильтра;
— когда нужен SPO-контроль и прозрачный путь до buyer;
— когда у sales нет сил вручную собирать PMPs под каждого рекламодателя.
Риски тоже типовые: слишком узкий сегмент убивает конкуренцию, слишком широкий превращает curated в обычный open exchange с лишней комиссией. Проверяйте, есть ли у deal нормальный deal ID, не дублируется ли inventory в нескольких пакетах, и не теряется ли при этом bid density.
Если curated marketplace не меняет путь до buyer и не снижает мусор в аукционе — это просто новый ярлык на старом supply.
Curated marketplace — это не «приватка с красивым названием», а отбор инвентаря и данных поверх open auction. SSP собирает supply, сегменты, правила доступа и продаёт пакет не по всему трафику, а по заранее описанному набору: домены, app bundle, geo, device, viewability, audience. Для buyer это меньше мусора в bid stream, для publisher — выше контроль над тем, кто вообще видит inventory.
Рабочая схема обычно такая: — curated пакет живёт как deal ID или отдельный PMPslot; — в deal попадают whitelist/blacklist, floor, format, allowed buyers; — иногда добавляют audience overlay из clean room или DMP. Главное тут не «премиальность», а предсказуемость: меньше SSP hops, меньше случайных bidders, меньше дублей между каналами.
Где curated marketplace полезен:
— на дорогом инвентаре, который нельзя отдавать в общий аукцион без фильтра;
— когда нужен SPO-контроль и прозрачный путь до buyer;
— когда у sales нет сил вручную собирать PMPs под каждого рекламодателя.
Риски тоже типовые: слишком узкий сегмент убивает конкуренцию, слишком широкий превращает curated в обычный open exchange с лишней комиссией. Проверяйте, есть ли у deal нормальный deal ID, не дублируется ли inventory в нескольких пакетах, и не теряется ли при этом bid density.
Если curated marketplace не меняет путь до buyer и не снижает мусор в аукционе — это просто новый ярлык на старом supply.
Открытые DSP вне big tech: где искать контролируемый стек без закрытого black box
Если нужен DSP, который можно интегрировать, ревьюить и не зависеть от одной экосистемы, смотрите на открытые и полу-открытые варианты вокруг RTB-стека, а не только на UI в кабинете.
Критерии отбора простые:
— есть документация по bid request / bid response и логам;
— можно подключить свой ID layer, deal-логики и pacing;
— понятны правила атрибуции win notice, loss reason, auction type;
— есть экспорт событий в свой BI, а не только агрегаты в дашборде.
Для self-hosted или гибридной схемы важны не «красивые фичи», а API вокруг core-функций: campaign management, frequency capping, budget control, seat-level permissions, creative QA. Если DSP не отдаёт сырые event logs, SPO и fraud-ревью будут слепыми.
Отдельно проверьте, можно ли работать с OpenRTB без vendor-specific расширений. Чем больше закрытых полей в request/response, тем дороже миграция и тем меньше шансов собрать единый supply-path pipeline между DSP, SSP и аналитикой. 🙂
Практика простая: сначала валидируйте прозрачность логов и контрактов, потом — медиакласс и инвентарь. В programmatic выигрывает не тот, у кого громче UI, а тот, у кого меньше невидимых слоёв между bid stream и отчётом.
Если нужен DSP, который можно интегрировать, ревьюить и не зависеть от одной экосистемы, смотрите на открытые и полу-открытые варианты вокруг RTB-стека, а не только на UI в кабинете.
Критерии отбора простые:
— есть документация по bid request / bid response и логам;
— можно подключить свой ID layer, deal-логики и pacing;
— понятны правила атрибуции win notice, loss reason, auction type;
— есть экспорт событий в свой BI, а не только агрегаты в дашборде.
Для self-hosted или гибридной схемы важны не «красивые фичи», а API вокруг core-функций: campaign management, frequency capping, budget control, seat-level permissions, creative QA. Если DSP не отдаёт сырые event logs, SPO и fraud-ревью будут слепыми.
Отдельно проверьте, можно ли работать с OpenRTB без vendor-specific расширений. Чем больше закрытых полей в request/response, тем дороже миграция и тем меньше шансов собрать единый supply-path pipeline между DSP, SSP и аналитикой. 🙂
Практика простая: сначала валидируйте прозрачность логов и контрактов, потом — медиакласс и инвентарь. В programmatic выигрывает не тот, у кого громче UI, а тот, у кого меньше невидимых слоёв между bid stream и отчётом.
Bid request enrichment ломает экономику аукциона, если не понимать, что именно доклеил SSP
В bid request enrichment SSP часто добавляет не только очевидные поля, но и скрытые допущения: гео по IP, device class, supply chain, доменный контекст, признаки инвентаря, derived floor. В итоге одна и та же impression в двух SSP выглядит как два разных аукциона.
Проверяйте, где поле пришло из publisher payload, а где сгенерировано на стороне SSP:
— geo / region / city: IP-based, not user-based
— schain / seller_id / pub_id: кто реально продаёт трафик
— content / cat / page / domain: нормализован или переписан
— device.ua / os / browser: иногда режется или агрегируется
— floor / deal info / pmp flags: может быть переупакован под свой routing
Главный риск — принимать enriched request как truth source. Тогда SPO-отчёт, фильтр по качеству и правила pacing начинают работать по чужой нормализации. Отсюда ложные выводы: “низкий bid density”, “плохой geo”, “не тот формат”, хотя проблема в том, что SSP дообогатила запрос своим слоем.
Практика простая: храните raw request отдельно от enriched, сравнивайте дельты по ключевым полям и помечайте, что пришло upstream, а что сгенерировано посредником. Это особенно важно для bidder debugging и reconciliation: без такой разметки bid stream превращается в набор красивых, но невалидируемых атрибутов.
В bid request enrichment SSP часто добавляет не только очевидные поля, но и скрытые допущения: гео по IP, device class, supply chain, доменный контекст, признаки инвентаря, derived floor. В итоге одна и та же impression в двух SSP выглядит как два разных аукциона.
Проверяйте, где поле пришло из publisher payload, а где сгенерировано на стороне SSP:
— geo / region / city: IP-based, not user-based
— schain / seller_id / pub_id: кто реально продаёт трафик
— content / cat / page / domain: нормализован или переписан
— device.ua / os / browser: иногда режется или агрегируется
— floor / deal info / pmp flags: может быть переупакован под свой routing
Главный риск — принимать enriched request как truth source. Тогда SPO-отчёт, фильтр по качеству и правила pacing начинают работать по чужой нормализации. Отсюда ложные выводы: “низкий bid density”, “плохой geo”, “не тот формат”, хотя проблема в том, что SSP дообогатила запрос своим слоем.
Практика простая: храните raw request отдельно от enriched, сравнивайте дельты по ключевым полям и помечайте, что пришло upstream, а что сгенерировано посредником. Это особенно важно для bidder debugging и reconciliation: без такой разметки bid stream превращается в набор красивых, но невалидируемых атрибутов.
Bid shading в DSP: где именно режется ставка и почему эффект не линейный
DSP шейдит не «ставку вообще», а собственную оценку вероятности победы в аукционе. Внутри обычно живут 3 слоя: модель clearing price, поправка на конкуренцию по площадке / supply path и ограничение по pacing. На вход идут bidstream, win notice, post-auction logs и история по конкретному inventory cluster.
Технически shading строится не от CPM в вакууме, а от распределения clearing prices по сегменту. Если DSP видит, что 80-й перцентиль выигрывает чаще, чем медиана, ставка сдвигается вниз до уровня, где marginal win rate ещё держит объём. Важно: одна и та же формула не переносится между geo, device, deal_id и time bucket.
Типичные ошибки:
— шейдить по всему exchange одним коэффициентом;
— не разделять open auction и PMP;
— игнорировать latency и timeout: «дешёвый» bid, пришедший поздно, = ноль;
— обучать модель на win rate без post-bid outcome, тогда она начинает экономить слишком агрессивно. 📉
Проверка простая: смотрите не только CPM, но и изменение win rate, spend, frequency of lost auctions on close price, а ещё долю запросов, где bid ушёл ниже floor. Если после shading растёт fill, но падает conversion-quality proxy, модель режет слишком глубоко.
Правильный shading — это не экономия любой ценой, а поиск точки, где margin растёт быстрее, чем теряется инвентарь.
DSP шейдит не «ставку вообще», а собственную оценку вероятности победы в аукционе. Внутри обычно живут 3 слоя: модель clearing price, поправка на конкуренцию по площадке / supply path и ограничение по pacing. На вход идут bidstream, win notice, post-auction logs и история по конкретному inventory cluster.
Технически shading строится не от CPM в вакууме, а от распределения clearing prices по сегменту. Если DSP видит, что 80-й перцентиль выигрывает чаще, чем медиана, ставка сдвигается вниз до уровня, где marginal win rate ещё держит объём. Важно: одна и та же формула не переносится между geo, device, deal_id и time bucket.
Типичные ошибки:
— шейдить по всему exchange одним коэффициентом;
— не разделять open auction и PMP;
— игнорировать latency и timeout: «дешёвый» bid, пришедший поздно, = ноль;
— обучать модель на win rate без post-bid outcome, тогда она начинает экономить слишком агрессивно. 📉
Проверка простая: смотрите не только CPM, но и изменение win rate, spend, frequency of lost auctions on close price, а ещё долю запросов, где bid ушёл ниже floor. Если после shading растёт fill, но падает conversion-quality proxy, модель режет слишком глубоко.
Правильный shading — это не экономия любой ценой, а поиск точки, где margin растёт быстрее, чем теряется инвентарь.
Логи RTB бесполезны, если не сохранять поля, которые объясняют bid loss и win rate
Сохраняйте не только request/response, а связку идентификаторов: auction id, imp id, request id, seat id, bidder name, source / schain, seller id, site/app id, placement id. Без этого не собрать путь запроса через wrapper, SSP и downstream.
Из полезного в bid request обычно хватает:
— timestamp в UTC;
— device: ua, ip, ifa/uid, geo;
— geo, language, os, browser;
— adunit: format, size, floor, prebid timeout;
— consent/regs, deal id, adomain, currencies.
Из bid response фиксируйте:
— bid price, currency, ad markup type;
— ttl / exp, creative id, advertiser domain;
— dealid, meta: advertiser / network / agency если есть;
— errors, no-bid reason, timeout reason;
— rendered / viewable / win notice, если трекинг доходит до события.
Важно хранить не только сырые JSON, но и нормализованные поля для аналитики. Иначе одна и та же сущность будет называться по-разному в разных логах, а SPO и floor-аналитика развалятся на несовместимые таблицы. Отдельно сохраняйте версию схемы и source of truth для каждого поля.
Минимальный набор для дешборда: auction id, bidder, adunit, geo, floor, timeout, bid, win, deal, consent, reason. Этого хватает, чтобы искать утечки в bid stream, оценивать влияние таймаута и понимать, где режется fill rate.
Если место ограничено, режьте креативные детали, а не идентификаторы и причины отказа: именно они потом объясняют, почему аукцион не сошёлся.
Сохраняйте не только request/response, а связку идентификаторов: auction id, imp id, request id, seat id, bidder name, source / schain, seller id, site/app id, placement id. Без этого не собрать путь запроса через wrapper, SSP и downstream.
Из полезного в bid request обычно хватает:
— timestamp в UTC;
— device: ua, ip, ifa/uid, geo;
— geo, language, os, browser;
— adunit: format, size, floor, prebid timeout;
— consent/regs, deal id, adomain, currencies.
Из bid response фиксируйте:
— bid price, currency, ad markup type;
— ttl / exp, creative id, advertiser domain;
— dealid, meta: advertiser / network / agency если есть;
— errors, no-bid reason, timeout reason;
— rendered / viewable / win notice, если трекинг доходит до события.
Важно хранить не только сырые JSON, но и нормализованные поля для аналитики. Иначе одна и та же сущность будет называться по-разному в разных логах, а SPO и floor-аналитика развалятся на несовместимые таблицы. Отдельно сохраняйте версию схемы и source of truth для каждого поля.
Минимальный набор для дешборда: auction id, bidder, adunit, geo, floor, timeout, bid, win, deal, consent, reason. Этого хватает, чтобы искать утечки в bid stream, оценивать влияние таймаута и понимать, где режется fill rate.
Если место ограничено, режьте креативные детали, а не идентификаторы и причины отказа: именно они потом объясняют, почему аукцион не сошёлся.
This media is not supported in your browser
VIEW IN TELEGRAM
Как уходят из арбитража трафика: интервью с бывшим медиабайером
Интервью с арбитражником, который отработал в сфере с 2019 года и ушёл в другую профессию. Герой рассказывает о работе в Adcombo с тизерками, переходе в криптовертикаль и прямом выкупе трафика, а затем о причинах ухода: выгорание, сложности с поиском новой позиции и переоценка приоритетов. Статья развенчивает миф о лёгких деньгах в арбитраже — это обычная работа с высокими рисками, дефицитом информации и эмоциональным истощением. Выво…
➡️ Читайте на сайте: https://aff.top/blog/kak-ukhodiat-iz-arbitrazha-trafika-interviu-s-byvshim-mediabaierom
🧠 Ещё больше инсайтов → в канале AFF.top
Интервью с арбитражником, который отработал в сфере с 2019 года и ушёл в другую профессию. Герой рассказывает о работе в Adcombo с тизерками, переходе в криптовертикаль и прямом выкупе трафика, а затем о причинах ухода: выгорание, сложности с поиском новой позиции и переоценка приоритетов. Статья развенчивает миф о лёгких деньгах в арбитраже — это обычная работа с высокими рисками, дефицитом информации и эмоциональным истощением. Выво…
➡️ Читайте на сайте: https://aff.top/blog/kak-ukhodiat-iz-arbitrazha-trafika-interviu-s-byvshim-mediabaierom
🧠 Ещё больше инсайтов → в канале AFF.top
OpenRTB 3.0 для арбитража: где ломается маппинг и теряются деньги
OpenRTB 3.0 полезен не “новыми словами”, а тем, что жёстче раскладывает запрос по сущностям: source, site/app, device, regs, user, content, auction. Для арбитражной команды это означает одно: если вы парсите bid stream как плоский JSON, часть сигналов уедет в null или в неверный namespace.
— Проверьте маппинг
— Отдельно разведите
— Не тащите legacy-поля “как есть”: в 3.0 часть атрибутов живёт в вложенных объектах, а bidder response должен отражать ту же структуру, иначе win notice и billing расходятся.
Для арбитража критичны три проверки: совпадает ли source chain с sellers.json, не теряется ли consent/IFA в user/device, и совпадает ли auction type с тем, что ждёт downstream DSP. Если у вас mixed-stack с header bidding, любая нестыковка между Prebid adapter и OpenRTB-3 endpoint даёт скрытую потерю fill или CPM, которую в отчёте видно только как “просадку качества”.
Практика простая: заведите JSON-schema валидацию на входе, логируйте diffs между 2.x и 3.0, и тестируйте не только bid request, но и bid response/win notice как единый контракт. Тогда миграция перестаёт быть “переклейкой полей” и становится контролем экономии аукциона.
OpenRTB 3.0 полезен не “новыми словами”, а тем, что жёстче раскладывает запрос по сущностям: source, site/app, device, regs, user, content, auction. Для арбитражной команды это означает одно: если вы парсите bid stream как плоский JSON, часть сигналов уедет в null или в неверный namespace.
— Проверьте маппинг
source: supply chain, schain, publisher, inventory source. Ошибка здесь ломает SPO-аналитику и сравнение путей.— Отдельно разведите
site/app: гибридные трафик-пулы часто теряют контекст и получают неверный bidfloor или таргетинг.— Не тащите legacy-поля “как есть”: в 3.0 часть атрибутов живёт в вложенных объектах, а bidder response должен отражать ту же структуру, иначе win notice и billing расходятся.
Для арбитража критичны три проверки: совпадает ли source chain с sellers.json, не теряется ли consent/IFA в user/device, и совпадает ли auction type с тем, что ждёт downstream DSP. Если у вас mixed-stack с header bidding, любая нестыковка между Prebid adapter и OpenRTB-3 endpoint даёт скрытую потерю fill или CPM, которую в отчёте видно только как “просадку качества”.
Практика простая: заведите JSON-schema валидацию на входе, логируйте diffs между 2.x и 3.0, и тестируйте не только bid request, но и bid response/win notice как единый контракт. Тогда миграция перестаёт быть “переклейкой полей” и становится контролем экономии аукциона.
DV360 API с 10 июня откроет Demand Gen ресурсы: rollout растянут на 2 недели
Google объявил: support для Demand Gen resources в Display & Video 360 API стартует 10 июня 2026.
Функцию раскатывают на партнёров в течение двух недель; к 24 июня она должна быть доступна всем.
После выката API получит
Для тех, кто держит DV360 automation, это прямой апдейт в работе с Demand Gen inventory и targeting через API.
Если у вас есть интеграции под campaign ops, стоит заранее проверить, где у вас зашиты ограничения на CRUD по этим сущностям и как это ляжет в пайплайн синхронизации.
Закрытая beta шла с 14 апреля — теперь это уже не тестовый контур, а нормальный production rollout.
Google наконец довёл API до ручек, которые нужны не только для read-only обвязки.
Google объявил: support для Demand Gen resources в Display & Video 360 API стартует 10 июня 2026.
Функцию раскатывают на партнёров в течение двух недель; к 24 июня она должна быть доступна всем.
После выката API получит
get, create, delete и patch для этих ресурсов.Для тех, кто держит DV360 automation, это прямой апдейт в работе с Demand Gen inventory и targeting через API.
Если у вас есть интеграции под campaign ops, стоит заранее проверить, где у вас зашиты ограничения на CRUD по этим сущностям и как это ляжет в пайплайн синхронизации.
Закрытая beta шла с 14 апреля — теперь это уже не тестовый контур, а нормальный production rollout.
Google наконец довёл API до ручек, которые нужны не только для read-only обвязки.
This media is not supported in your browser
VIEW IN TELEGRAM
ByteDance анонсировала новую версию SeeDance версии 2.5
ByteDance готовит релиз Seedance 2.5 — видеогенератора нового уровня. Главное улучшение: модель сможет создавать 30-секундные видео за один прогон без склеек, вместо нынешних 15 секунд. Добавили локальный монтаж отдельных кадров, поддержку 3D-болванок для управления камерой, возможность использовать до 50 референсов и генерацию в 4К сразу. Закрытый бета-тест идёт сейчас, открытый релиз ожидается в начале июля. Технологически это шаг вперёд, но д…
➡️ Читайте на сайте: https://aff.top/blog/bytedance-anonsirovala-novuiu-versiiu-seedance-versii-2-5
🧠 Ещё больше инсайтов → в канале AFF.top
ByteDance готовит релиз Seedance 2.5 — видеогенератора нового уровня. Главное улучшение: модель сможет создавать 30-секундные видео за один прогон без склеек, вместо нынешних 15 секунд. Добавили локальный монтаж отдельных кадров, поддержку 3D-болванок для управления камерой, возможность использовать до 50 референсов и генерацию в 4К сразу. Закрытый бета-тест идёт сейчас, открытый релиз ожидается в начале июля. Технологически это шаг вперёд, но д…
➡️ Читайте на сайте: https://aff.top/blog/bytedance-anonsirovala-novuiu-versiiu-seedance-versii-2-5
🧠 Ещё больше инсайтов → в канале AFF.top
This media is not supported in your browser
VIEW IN TELEGRAM
Codex уничтожит твой SSD за год
Разработчик обнаружил критический баг в Codex CLI от OpenAI: агент непрерывно записывает логи в локальную SQLite-базу, перезаписывая за 21 день 37 ТБ данных. При таком темпе типичный SSD объёмом 1 ТБ (рассчитанный на 600 ТБ перезаписей) выходит из строя менее чем за год. OpenAI осведомлена о проблеме, но пока не исправляет её. Пользователям остаётся либо ждать обновления, либо переключиться на альтернативные CLI-инструменты без подобных недостат…
➡️ Читайте на сайте: https://aff.top/blog/codex-unichtozhit-tvoi-ssd-za-god
🧠 Ещё больше инсайтов → в канале AFF.top
Разработчик обнаружил критический баг в Codex CLI от OpenAI: агент непрерывно записывает логи в локальную SQLite-базу, перезаписывая за 21 день 37 ТБ данных. При таком темпе типичный SSD объёмом 1 ТБ (рассчитанный на 600 ТБ перезаписей) выходит из строя менее чем за год. OpenAI осведомлена о проблеме, но пока не исправляет её. Пользователям остаётся либо ждать обновления, либо переключиться на альтернативные CLI-инструменты без подобных недостат…
➡️ Читайте на сайте: https://aff.top/blog/codex-unichtozhit-tvoi-ssd-za-god
🧠 Ещё больше инсайтов → в канале AFF.top
Bid request enrichment у SSP: какие поля реально добавляют ценность, а какие шумят
SSP часто расширяет bid request не только ради удобства, а чтобы поднять match rate, фильтровать supply и дать bidder'у больше сигналов для price discovery. Но не каждый enrichment полезен: чем больше полей, тем выше риск мусора, дублирования и расхождений между источниками.
Что обычно добавляют:
— site/app metadata: bundle, domain, pagecat, content, keywords
— device signals: UA, language, IP-производные, connection type, ifa/ifa_type
— seller context: seller_id, schain, ads.txt/app-ads.txt relations
— audience hints: segment IDs, cohort labels, GDPR/TCF consent flags
— transaction layer: deals, floors, auction type, ext-объекты
Главная проверка — не наличие поля, а его стабильность. Если enrichment плавает между SSP, bidder начинает переоценивать inventory или, наоборот, выкидывать его из-за low-confidence сигналов. Особенно это заметно на pagecat/content и audience segments: один и тот же supply может выглядеть как разные объекты в разных upstream.
Практика для валидации простая: логируйте raw request, сравнивайте заполненность по SSP, отмечайте поля, которые реально коррелируют с win rate и CPM, и отдельно режьте то, что только увеличивает payload. В SPO-отчётах enrichment полезен, когда он объясняет, почему один path продаётся лучше другого, а не когда просто раздувает JSON.
Чем чище enrichment, тем проще bidder'у принимать решение: оставляйте только те сигналы, которые меняют bid, а не те, которые красиво выглядят в схеме.
SSP часто расширяет bid request не только ради удобства, а чтобы поднять match rate, фильтровать supply и дать bidder'у больше сигналов для price discovery. Но не каждый enrichment полезен: чем больше полей, тем выше риск мусора, дублирования и расхождений между источниками.
Что обычно добавляют:
— site/app metadata: bundle, domain, pagecat, content, keywords
— device signals: UA, language, IP-производные, connection type, ifa/ifa_type
— seller context: seller_id, schain, ads.txt/app-ads.txt relations
— audience hints: segment IDs, cohort labels, GDPR/TCF consent flags
— transaction layer: deals, floors, auction type, ext-объекты
Главная проверка — не наличие поля, а его стабильность. Если enrichment плавает между SSP, bidder начинает переоценивать inventory или, наоборот, выкидывать его из-за low-confidence сигналов. Особенно это заметно на pagecat/content и audience segments: один и тот же supply может выглядеть как разные объекты в разных upstream.
Практика для валидации простая: логируйте raw request, сравнивайте заполненность по SSP, отмечайте поля, которые реально коррелируют с win rate и CPM, и отдельно режьте то, что только увеличивает payload. В SPO-отчётах enrichment полезен, когда он объясняет, почему один path продаётся лучше другого, а не когда просто раздувает JSON.
Чем чище enrichment, тем проще bidder'у принимать решение: оставляйте только те сигналы, которые меняют bid, а не те, которые красиво выглядят в схеме.
Открытая DSP без big tech: где реально собирать стек и не зависеть от одного кабинета
Открытые DSP живут не как «волшебная кнопка», а как набор модулей: bidder, decisioning, pacing, reporting, anti-fraud, identity. Если собирать стек вне big tech, смотрите не на бренд, а на три вещи: есть ли доступ к raw bid stream, можно ли контролировать auction logic, и вытаскиваются ли события в свой warehouse без ручного экспорта.
Базовый чек-лист для оценки:
— OpenRTB поддержка без урезания полей source, schain, regs, user, imp.ext
— нормальная работа с first-party IDs и consent string
— прозрачный path к logs, win notices, bid responses
— возможность подключать собственный pre-bid filtering и SPO rules
— нормальный seat / deal / domain governance без «черного ящика»
Для publisher-side это особенно важно: если DSP не отдает нормальные логи и не объясняет, почему бид отклонен, вы не увидите ни leakage, ни перекосы по geo/device, ни проблемы в floor strategy. Для in-house performance-команд главный риск другой: закрытый decisioning ломает эксперименты с pacing, frequency capping и inventory split.
Собирайте стек так, чтобы заменять один слой без миграции всего контура. Иначе любой рост CPM превращается в зависимость от одного вендора, а SPO остается только в презентации.
Открытые DSP живут не как «волшебная кнопка», а как набор модулей: bidder, decisioning, pacing, reporting, anti-fraud, identity. Если собирать стек вне big tech, смотрите не на бренд, а на три вещи: есть ли доступ к raw bid stream, можно ли контролировать auction logic, и вытаскиваются ли события в свой warehouse без ручного экспорта.
Базовый чек-лист для оценки:
— OpenRTB поддержка без урезания полей source, schain, regs, user, imp.ext
— нормальная работа с first-party IDs и consent string
— прозрачный path к logs, win notices, bid responses
— возможность подключать собственный pre-bid filtering и SPO rules
— нормальный seat / deal / domain governance без «черного ящика»
Для publisher-side это особенно важно: если DSP не отдает нормальные логи и не объясняет, почему бид отклонен, вы не увидите ни leakage, ни перекосы по geo/device, ни проблемы в floor strategy. Для in-house performance-команд главный риск другой: закрытый decisioning ломает эксперименты с pacing, frequency capping и inventory split.
Собирайте стек так, чтобы заменять один слой без миграции всего контура. Иначе любой рост CPM превращается в зависимость от одного вендора, а SPO остается только в презентации.
This media is not supported in your browser
VIEW IN TELEGRAM
Google ужесточает модерацию финансовой вертикали
Google ужесточает модерацию финансовых офферов в ЕС и ЕЭЗ, введя двухэтапную верификацию через G2 Risk Solutions и Google Ads. Проверка затронет 24 страны, включая Австрию, Польшу, Нидерланды и другие члены союза. На прохождение модерации отводится 30 дней — за это время некоторые связки успеют отработать до вступления требований в силу. Для арбитражников это означает необходимость подготовиться к усложнению процесса запуска финансовых кампаний …
➡️ Читайте на сайте: https://aff.top/blog/google-uzhestochaet-moderaciiu-finansovoi-vertikali
🧠 Ещё больше инсайтов → в канале AFF.top
Google ужесточает модерацию финансовых офферов в ЕС и ЕЭЗ, введя двухэтапную верификацию через G2 Risk Solutions и Google Ads. Проверка затронет 24 страны, включая Австрию, Польшу, Нидерланды и другие члены союза. На прохождение модерации отводится 30 дней — за это время некоторые связки успеют отработать до вступления требований в силу. Для арбитражников это означает необходимость подготовиться к усложнению процесса запуска финансовых кампаний …
➡️ Читайте на сайте: https://aff.top/blog/google-uzhestochaet-moderaciiu-finansovoi-vertikali
🧠 Ещё больше инсайтов → в канале AFF.top
IVT — не одна метка, а три слоя мусора в bid stream: как их разбирать без иллюзий
В anti-fraud обычно смотрят на три категории: GIVT, SIVT и technical noise. GIVT ловится правилами: data center IP, known bots, invalid UA, suspicious referrers, аномальные spikes по frequency и географии. Это не «сложный ML», а нормальная гигиена: если не фильтруете очевидное, downstream-метрики уже искажены.
SIVT детектится по совокупности сигналов: поведение сессии, тайминги, pattern reuse, несостыковка device graph, короткие dwell time, повторяемые scroll/click траектории. Здесь важны не отдельные триггеры, а score по нескольким источникам: SSP log, publisher logs, MMP/analytics, ad-server events.
Практический чек-лист для команды:
— сверять bid request с server-side логами по request_id;
— строить baseline по geo, device, placement, hour-of-day;
— искать повторяемые цепочки user-agent + IP + ASN;
— отдельно смотреть IVT по supply path, а не только по placement.
Если у вас нет раздельной классификации, любое расследование превращается в спор с вендором. Нужны три артефакта: raw log, правила отсева GIVT и очередь на ручной review SIVT. Тогда можно быстро понять, где фрод, где кривой трафик, а где просто шум.
Без сегментации IVT вы оптимизируете не spend, а собственную слепую зону.
В anti-fraud обычно смотрят на три категории: GIVT, SIVT и technical noise. GIVT ловится правилами: data center IP, known bots, invalid UA, suspicious referrers, аномальные spikes по frequency и географии. Это не «сложный ML», а нормальная гигиена: если не фильтруете очевидное, downstream-метрики уже искажены.
SIVT детектится по совокупности сигналов: поведение сессии, тайминги, pattern reuse, несостыковка device graph, короткие dwell time, повторяемые scroll/click траектории. Здесь важны не отдельные триггеры, а score по нескольким источникам: SSP log, publisher logs, MMP/analytics, ad-server events.
Практический чек-лист для команды:
— сверять bid request с server-side логами по request_id;
— строить baseline по geo, device, placement, hour-of-day;
— искать повторяемые цепочки user-agent + IP + ASN;
— отдельно смотреть IVT по supply path, а не только по placement.
Если у вас нет раздельной классификации, любое расследование превращается в спор с вендором. Нужны три артефакта: raw log, правила отсева GIVT и очередь на ручной review SIVT. Тогда можно быстро понять, где фрод, где кривой трафик, а где просто шум.
Без сегментации IVT вы оптимизируете не spend, а собственную слепую зону.
This media is not supported in your browser
VIEW IN TELEGRAM
Fable 5 скоро вернётся в публичный доступ
В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…
➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup
🧠 Ещё больше инсайтов → в канале AFF.top
В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…
➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup
🧠 Ещё больше инсайтов → в канале AFF.top
ID5, UID 2.0 и LiveRamp: как не сломать identity stack в programmatic
Если у вас в стекe одновременно сидят ID5, UID 2.0 и RampID, ошибка обычно не в самих провайдерах, а в архитектуре маппинга. Главный вопрос — где лежит source of truth: в CMP, в prebid userId module или в server-side sync.
— Не смешивайте разные scopes одного и того же пользователя в одном key-value без явного приоритета. Иначе bidder видит несколько ID и начинает деградировать match rate.
— Проверьте TTL и refresh policy: stale ID хуже, чем отсутствие ID. Для long-tail трафика это критично.
— Не отправляйте один и тот же ID в несколько id systems без нормализации consent-state; потом это ломает сегментацию и дедупликацию.
Практика: в client-side оставляйте only one primary ID provider на сессию, а остальные — как fallback. На стороне Prebid держите порядок userIds детерминированным, иначе разные страницы начнут отдавать разные значения в bidstream. В SSP/DSP логике отдельно учитывайте MAID, hashed email и publisher IDs — это разные сущности, даже если они совпадают по match rate.
Если нужен стабильный identity stack, проектируйте его как очередность приоритетов и правил истечения, а не как список интеграций.
Если у вас в стекe одновременно сидят ID5, UID 2.0 и RampID, ошибка обычно не в самих провайдерах, а в архитектуре маппинга. Главный вопрос — где лежит source of truth: в CMP, в prebid userId module или в server-side sync.
— Не смешивайте разные scopes одного и того же пользователя в одном key-value без явного приоритета. Иначе bidder видит несколько ID и начинает деградировать match rate.
— Проверьте TTL и refresh policy: stale ID хуже, чем отсутствие ID. Для long-tail трафика это критично.
— Не отправляйте один и тот же ID в несколько id systems без нормализации consent-state; потом это ломает сегментацию и дедупликацию.
Практика: в client-side оставляйте only one primary ID provider на сессию, а остальные — как fallback. На стороне Prebid держите порядок userIds детерминированным, иначе разные страницы начнут отдавать разные значения в bidstream. В SSP/DSP логике отдельно учитывайте MAID, hashed email и publisher IDs — это разные сущности, даже если они совпадают по match rate.
Если нужен стабильный identity stack, проектируйте его как очередность приоритетов и правил истечения, а не как список интеграций.