Cookieless targeting без MAID и third-party cookies: где ещё остаётся сигнал для DSP
Контекстный таргетинг снова стал инфраструктурной задачей, а не fallback-механикой. Разница теперь в том, что DSP смотрит не только на URL и keywords, а на полный набор сигналов из bid request:
Что реально работает в cookieless-среде:
— Context + taxonomy mapping.
IAB Content Taxonomy v3 + semantic classification дают стабильнее inventory segmentation, чем legacy keyword match. Особенно в news / UGC inventory, где title-level matching ломается от шумных запросов.
— First-party graph через Prebid RTD-модули.
Если publisher хранит event-level data внутри CDP или data clean room, RTD может пробрасывать cohort / propensity score прямо в auction:
Без user-level ID sync и cookie matching.
— Supply-path filtering.
Cookieless-аукцион хуже переносит длинный reseller chain. Чем больше hops между publisher и DSP, тем слабее signal fidelity. sellers.json + schain становятся не compliance-файлом, а quality-сигналом.
— Attention и viewability как proxy intent.
После деградации user-level targeting DSP чаще используют historical attention metrics: active view, scroll depth, completion rate, session quality. Это уже часть bid optimization, а не post-campaign analytics.
Ошибка, которая ломает cookieless setup чаще всего: teams продолжают оценивать inventory только через CTR/CPA и игнорируют loss rate в bidstream. Без clean supply-path даже хороший contextual graph начинает шуметь.
Cookieless-стек выигрывает не у cookies. Он выигрывает у плохого bid request.
Контекстный таргетинг снова стал инфраструктурной задачей, а не fallback-механикой. Разница теперь в том, что DSP смотрит не только на URL и keywords, а на полный набор сигналов из bid request:
site.content.cat, pagecat, content.language, viewability history, seller path и device hints.Что реально работает в cookieless-среде:
— Context + taxonomy mapping.
IAB Content Taxonomy v3 + semantic classification дают стабильнее inventory segmentation, чем legacy keyword match. Особенно в news / UGC inventory, где title-level matching ломается от шумных запросов.
— First-party graph через Prebid RTD-модули.
Если publisher хранит event-level data внутри CDP или data clean room, RTD может пробрасывать cohort / propensity score прямо в auction:
ortb2.user.data[].segment[]
Без user-level ID sync и cookie matching.
— Supply-path filtering.
Cookieless-аукцион хуже переносит длинный reseller chain. Чем больше hops между publisher и DSP, тем слабее signal fidelity. sellers.json + schain становятся не compliance-файлом, а quality-сигналом.
— Attention и viewability как proxy intent.
После деградации user-level targeting DSP чаще используют historical attention metrics: active view, scroll depth, completion rate, session quality. Это уже часть bid optimization, а не post-campaign analytics.
Ошибка, которая ломает cookieless setup чаще всего: teams продолжают оценивать inventory только через CTR/CPA и игнорируют loss rate в bidstream. Без clean supply-path даже хороший contextual graph начинает шуметь.
Cookieless-стек выигрывает не у cookies. Он выигрывает у плохого bid request.
MOAT показывает viewability и attention, но не объясняет почему инвентарь теряет CPM
MOAT часто подключают как внешний слой валидации качества трафика. Он отвечает на вопрос: был ли показ реально видим пользователю, сколько времени креатив находился в зоне видимости и присутствуют ли признаки невалидной активности. Но MOAT не является инструментом диагностики всего programmatic-стека.
Что измеряет MOAT:
— Viewability по стандартам MRC.
— In-view time и активное внимание к креативу.
— IVT-сигналы и часть fraud-индикаторов.
— Reach, frequency и post-bid quality-метрики для кампаний.
Где начинаются слепые зоны:
— Не видно структуру supply path. MOAT не покажет лишних посредников между SSP и DSP.
— Не анализируется аукционная логика header bidding: timeout, bid landscape, потерянные ставки.
— Нет объяснения причин низкого win rate или падения bid density.
— Не заменяет аудит ads.txt, sellers.json и цепочки reseller/direct отношений.
Типичная ошибка — использовать MOAT как единственный источник правды. Viewability может быть высокой, а доход всё равно проседать из-за дублированного bid stream, неоптимального floor pricing или неэффективного маршрута закупки.
Для ad-ops команды полезнее смотреть MOAT рядом с логами аукциона, SPO-отчётами и метриками SSP. Качество показа и эффективность монетизации — связанные, но разные задачи. MOAT хорошо отвечает на вопрос «что увидел пользователь», а не «как устроена экономика этого показа».
MOAT часто подключают как внешний слой валидации качества трафика. Он отвечает на вопрос: был ли показ реально видим пользователю, сколько времени креатив находился в зоне видимости и присутствуют ли признаки невалидной активности. Но MOAT не является инструментом диагностики всего programmatic-стека.
Что измеряет MOAT:
— Viewability по стандартам MRC.
— In-view time и активное внимание к креативу.
— IVT-сигналы и часть fraud-индикаторов.
— Reach, frequency и post-bid quality-метрики для кампаний.
Где начинаются слепые зоны:
— Не видно структуру supply path. MOAT не покажет лишних посредников между SSP и DSP.
— Не анализируется аукционная логика header bidding: timeout, bid landscape, потерянные ставки.
— Нет объяснения причин низкого win rate или падения bid density.
— Не заменяет аудит ads.txt, sellers.json и цепочки reseller/direct отношений.
Типичная ошибка — использовать MOAT как единственный источник правды. Viewability может быть высокой, а доход всё равно проседать из-за дублированного bid stream, неоптимального floor pricing или неэффективного маршрута закупки.
Для ad-ops команды полезнее смотреть MOAT рядом с логами аукциона, SPO-отчётами и метриками SSP. Качество показа и эффективность монетизации — связанные, но разные задачи. MOAT хорошо отвечает на вопрос «что увидел пользователь», а не «как устроена экономика этого показа».
SPO не делают “по интуиции”: без фреймворка вы режете supply и теряете инвентарь
SPO начинается не с «убрать лишних посредников», а с карты маршрутов. Сначала фиксируете все paths: SSP, resellers, exchange, deal ID, seat, ads.txt/sellers.json связь. Без этого вы оптимизируете не supply, а шум в отчёте.
Дальше — 4 фильтра:
— прозрачность: есть ли валидный seller chain и понятный fee stack;
— качество: совпадают ли IVT, viewability, win rate и post-bid performance;
— эффективность: где растёт bid duplication и где path даёт тот же инвентарь дороже;
— контроль: есть ли direct path, PMP или preferred deal, который уже закрывает спрос без лишних hops.
Ошибка №1 — резать по CPM. Дешёвый path часто просто получает более слабый demand. Ошибка №2 — верить одному отчёту SSP: смотрите корреляцию с bid stream, win notices и log-level data. Ошибка №3 — сравнивать пути без нормализации по geo, device, format и timeout.
Рабочая схема простая:
1) строите baseline по всем path;
2) группируете дублирующиеся маршруты;
3) оставляете path с лучшим balance между revenue, quality и прозрачностью;
4) пересматриваете решение после изменений в ads.txt, reseller chain и demand mix.
SPO — это не «меньше посредников», а меньше лишней неопределённости. Если path нельзя объяснить на уровне логов, его сложно защитить в аукционе и в P&L.
SPO начинается не с «убрать лишних посредников», а с карты маршрутов. Сначала фиксируете все paths: SSP, resellers, exchange, deal ID, seat, ads.txt/sellers.json связь. Без этого вы оптимизируете не supply, а шум в отчёте.
Дальше — 4 фильтра:
— прозрачность: есть ли валидный seller chain и понятный fee stack;
— качество: совпадают ли IVT, viewability, win rate и post-bid performance;
— эффективность: где растёт bid duplication и где path даёт тот же инвентарь дороже;
— контроль: есть ли direct path, PMP или preferred deal, который уже закрывает спрос без лишних hops.
Ошибка №1 — резать по CPM. Дешёвый path часто просто получает более слабый demand. Ошибка №2 — верить одному отчёту SSP: смотрите корреляцию с bid stream, win notices и log-level data. Ошибка №3 — сравнивать пути без нормализации по geo, device, format и timeout.
Рабочая схема простая:
1) строите baseline по всем path;
2) группируете дублирующиеся маршруты;
3) оставляете path с лучшим balance между revenue, quality и прозрачностью;
4) пересматриваете решение после изменений в ads.txt, reseller chain и demand mix.
SPO — это не «меньше посредников», а меньше лишней неопределённости. Если path нельзя объяснить на уровне логов, его сложно защитить в аукционе и в P&L.
Client-side и server-side header bidding: где теряется latency, а где — transparency
Client-side wrapper видит больше сигналов: user agent, page context, consent, local storage, client-side IDs. За это платите временем на странице и риском, что тяжёлые adapters начнут резать viewability и inflate timeout chain.
Server-side снимает часть нагрузки с браузера и лучше масштабируется на сложных страницах. Но вместе с этим теряется часть request-level visibility: не все bidder-side signals доходят до auction, а debugging становится беднее. Если у вас нет нормального logging на auction object, вы быстро упираетесь в «почему win rate просел» без ответа.
Базовый выбор обычно такой:
— client-side: когда важны first-party signals, точная диагностика и максимальная прозрачность bid stream;
— server-side: когда критичны performance, множество demand-партнёров и контроль над browser CPU;
— hybrid: когда нужно оставить sensitive bidders в browser, а тяжёлых вынести на сервер.
Смотрите не только на CPM, а на
Рабочий чек-лист: логируйте auction timestamps, отдельно меряйте browser-side и server-side timeouts, не смешивайте все demand sources в один bucket и проверяйте, где именно падает competition. Иначе архитектура начнёт оптимизировать не доход, а удобство интеграции.
Client-side wrapper видит больше сигналов: user agent, page context, consent, local storage, client-side IDs. За это платите временем на странице и риском, что тяжёлые adapters начнут резать viewability и inflate timeout chain.
Server-side снимает часть нагрузки с браузера и лучше масштабируется на сложных страницах. Но вместе с этим теряется часть request-level visibility: не все bidder-side signals доходят до auction, а debugging становится беднее. Если у вас нет нормального logging на auction object, вы быстро упираетесь в «почему win rate просел» без ответа.
Базовый выбор обычно такой:
— client-side: когда важны first-party signals, точная диагностика и максимальная прозрачность bid stream;
— server-side: когда критичны performance, множество demand-партнёров и контроль над browser CPU;
— hybrid: когда нужно оставить sensitive bidders в browser, а тяжёлых вынести на сервер.
Смотрите не только на CPM, а на
auction latency, timeout hit rate, adapter fill и долю bid requests, которые реально дошли до render path. Если серверный слой прячет потерю участия части bidders, revenue может выглядеть стабильным только до первого разреза по geo/device.Рабочий чек-лист: логируйте auction timestamps, отдельно меряйте browser-side и server-side timeouts, не смешивайте все demand sources в один bucket и проверяйте, где именно падает competition. Иначе архитектура начнёт оптимизировать не доход, а удобство интеграции.
BeFluence на MAC 2026: не RTB, но performance supply вне bid stream
26–27 мая команда BeFluence будет на MAC 2026 в Ереване.
Что известно по фактам:
— vertical: iGaming / Betting
— формат: influencer marketing agency с фокусом на performance-результат
— площадки: Twitch, Kick, YouTube, Telegram, Instagram и другие
— масштаб: кампании в 15+ GEO
— volume: 1 000+ интеграций с блогерами и каналами ежемесячно
Почему это важно для programmatic-команд:
— это не SSP/DSP-инвентарь и не header bidding, но конкурирует за тот же performance budget;
— для SPO-аналитики такие каналы нужно учитывать отдельно от RTB supply path, иначе CPA/ROAS по paid acquisition будет сравниваться некорректно;
— при миксе programmatic + influencer важно разносить атрибуцию по источникам, где нет bid request / win notice / auction log.
Без данных по attribution model, pricing и post-view/post-click окнам оценивать эффективность нельзя. Но сам масштаб интеграций уже достаточен, чтобы не смешивать этот supply с классическим programmatic в одном отчёте.
Источник: https://t.me/igamingceo/937
26–27 мая команда BeFluence будет на MAC 2026 в Ереване.
Что известно по фактам:
— vertical: iGaming / Betting
— формат: influencer marketing agency с фокусом на performance-результат
— площадки: Twitch, Kick, YouTube, Telegram, Instagram и другие
— масштаб: кампании в 15+ GEO
— volume: 1 000+ интеграций с блогерами и каналами ежемесячно
Почему это важно для programmatic-команд:
— это не SSP/DSP-инвентарь и не header bidding, но конкурирует за тот же performance budget;
— для SPO-аналитики такие каналы нужно учитывать отдельно от RTB supply path, иначе CPA/ROAS по paid acquisition будет сравниваться некорректно;
— при миксе programmatic + influencer важно разносить атрибуцию по источникам, где нет bid request / win notice / auction log.
Без данных по attribution model, pricing и post-view/post-click окнам оценивать эффективность нельзя. Но сам масштаб интеграций уже достаточен, чтобы не смешивать этот supply с классическим programmatic в одном отчёте.
Источник: https://t.me/igamingceo/937
Moloco / iOS in-app: сегодня разбор без технического changelog
Сегодня в 17:00 GMT+3 запланирована трансляция по iOS-приложениям и последним обновлениям Moloco.
Что заявлено в повестке:
— подходы и сеттинги для iOS-приложений;
— запуск приложений и работа с iOS-трафиком;
— изменения в Moloco;
— удорожание In-App трафика;
— работа с приложениями после обновлений.
Для ad-ops / UA-команд это стоит смотреть не как спецификацию Moloco, а как практический разбор текущей операционки по iOS inventory: где меняются настройки, что происходит с ценой in-app supply и какие параметры запуска приложений требуют пересмотра.
Важно: в анонсе нет деталей по конкретным изменениям в API, bidding logic или атрибуции Moloco. Поэтому технические выводы лучше делать только после самой трансляции или официальных материалов вендора.
Источник: https://t.me/arbihunter/1367
Сегодня в 17:00 GMT+3 запланирована трансляция по iOS-приложениям и последним обновлениям Moloco.
Что заявлено в повестке:
— подходы и сеттинги для iOS-приложений;
— запуск приложений и работа с iOS-трафиком;
— изменения в Moloco;
— удорожание In-App трафика;
— работа с приложениями после обновлений.
Для ad-ops / UA-команд это стоит смотреть не как спецификацию Moloco, а как практический разбор текущей операционки по iOS inventory: где меняются настройки, что происходит с ценой in-app supply и какие параметры запуска приложений требуют пересмотра.
Важно: в анонсе нет деталей по конкретным изменениям в API, bidding logic или атрибуции Moloco. Поэтому технические выводы лучше делать только после самой трансляции или официальных материалов вендора.
Источник: https://t.me/arbihunter/1367
IAB Tech Lab: signal loss, agentic advertising и supply chain validation
Что зафиксировано в последних материалах Tech Lab:
— Signal Shift NYC прошёл 19 марта: фокус на privacy considerations в эпоху agentic advertising и потери сигналов.
— Signal Shift West Coast прошёл 25 сентября 2025 в Mountain View, California: отдельная площадка по тем же сдвигам в сигнальном слое.
— Supply Chain APIs получили feature Supply Chain Validation for Sellers: продавцы могут проверять, где listed их domain. Для SPO это ближе к операционной гигиене: сверка supply chain, ads.txt / sellers.json связок и лишних путей до инвентаря.
— IAB Tech Lab Summit 2025 был sold out; темы: AI, CTV, curation, privacy regulations.
— В отдельном материале Tech Lab поднимает роль taxonomies в AI world; Mixpeek сделал donation, который может помочь пользователям upgrade taxonomies.
Что смотреть ad-ops / SSP-side:
— где домен паблишера фактически появляется в supply chain;
— не расходятся ли listings с ads.txt / sellers.json;
— какие taxonomy mappings используются в AI/curation flows;
— как privacy-сигналы деградируют в bid stream при agentic сценариях.
Источник: https://iabtechlab.com/category/blog/
—
Ещё больше trackers в @tracker_lab
Что зафиксировано в последних материалах Tech Lab:
— Signal Shift NYC прошёл 19 марта: фокус на privacy considerations в эпоху agentic advertising и потери сигналов.
— Signal Shift West Coast прошёл 25 сентября 2025 в Mountain View, California: отдельная площадка по тем же сдвигам в сигнальном слое.
— Supply Chain APIs получили feature Supply Chain Validation for Sellers: продавцы могут проверять, где listed их domain. Для SPO это ближе к операционной гигиене: сверка supply chain, ads.txt / sellers.json связок и лишних путей до инвентаря.
— IAB Tech Lab Summit 2025 был sold out; темы: AI, CTV, curation, privacy regulations.
— В отдельном материале Tech Lab поднимает роль taxonomies в AI world; Mixpeek сделал donation, который может помочь пользователям upgrade taxonomies.
Что смотреть ad-ops / SSP-side:
— где домен паблишера фактически появляется в supply chain;
— не расходятся ли listings с ads.txt / sellers.json;
— какие taxonomy mappings используются в AI/curation flows;
— как privacy-сигналы деградируют в bid stream при agentic сценариях.
Источник: https://iabtechlab.com/category/blog/
—
Ещё больше trackers в @tracker_lab
OpenRTB 3.0 ломает привычный bidstream: где у арбитражника начнутся интеграционные ошибки
OpenRTB 3.0 — это не «ещё один JSON». В версии меняется сама модель запроса: вместо россыпи плоских полей появляется более строгая структура `source` / `request` / `item` / `data`. Для тех, кто привык парсить `imp[]` и искать всё в одном объекте, это означает перепроверку маппинга на каждом слое.
Главное для арбитражной команды:
— `source` и `ext` больше нельзя воспринимать как свалку для произвольных полей;
— `item` ближе к конкретному инвентарю и условиям сделки, чем старый `imp`;
— идентификаторы и контекст часто переезжают в более вложенные блоки, и старый code path может тихо терять значения;
— если у вас middleware между SSP и bidder, он должен уметь валидировать схему, а не только логировать payload.
Типовая ошибка — пытаться «подружить» 3.0 с 2.x через простую трансформацию ключей. Это работает только для части полей. В реальности ломаются deal-условия, price floors, device/user-метаданные и трекинг атрибуции, если не обновить schema mapping целиком.
Что проверить до миграции:
— поддерживает ли ваш bidder/adapter именно OpenRTB 3.x schema;
— есть ли в логах отдельная валидация `source` и `item`;
— не теряются ли `schain`, consent, supply metadata и deal IDs при конвертации.
Если у вас в стеке есть кастомный parser, OpenRTB 3.0 лучше считать не апдейтом, а отдельным контрактом. Иначе поломка будет не в аукционе, а в вашем маппинге.
OpenRTB 3.0 — это не «ещё один JSON». В версии меняется сама модель запроса: вместо россыпи плоских полей появляется более строгая структура `source` / `request` / `item` / `data`. Для тех, кто привык парсить `imp[]` и искать всё в одном объекте, это означает перепроверку маппинга на каждом слое.
Главное для арбитражной команды:
— `source` и `ext` больше нельзя воспринимать как свалку для произвольных полей;
— `item` ближе к конкретному инвентарю и условиям сделки, чем старый `imp`;
— идентификаторы и контекст часто переезжают в более вложенные блоки, и старый code path может тихо терять значения;
— если у вас middleware между SSP и bidder, он должен уметь валидировать схему, а не только логировать payload.
Типовая ошибка — пытаться «подружить» 3.0 с 2.x через простую трансформацию ключей. Это работает только для части полей. В реальности ломаются deal-условия, price floors, device/user-метаданные и трекинг атрибуции, если не обновить schema mapping целиком.
Что проверить до миграции:
— поддерживает ли ваш bidder/adapter именно OpenRTB 3.x schema;
— есть ли в логах отдельная валидация `source` и `item`;
— не теряются ли `schain`, consent, supply metadata и deal IDs при конвертации.
Если у вас в стеке есть кастомный parser, OpenRTB 3.0 лучше считать не апдейтом, а отдельным контрактом. Иначе поломка будет не в аукционе, а в вашем маппинге.
IVT — это не одна метрика: как разложить ad-fraud detection по категориям
IVT обычно ломают на несколько слоёв, и детектить их надо по-разному. Если свалить всё в один bucket, отчёт будет шумным: часть инвентаря уходит в false positive, часть fraud проходит мимо.
— GIVT: бот-сети, дата-центры, известные crawler’ы, аномальные user-agent / IP / ASN, повторяющиеся паттерны запросов. Тут работают rules-based фильтры, threat intel, allow/deny lists, сигнатуры.
— SIVT: сложнее. Мутации креатива, hidden iframes, ad stacking, spoofing, injected clicks. Нужны поведенческие сигналы, viewability-цепочка, timing-анализ, JS telemetry, correlation между impression и interaction.
— SDK / app fraud: подмена device signals, install hijacking, click flooding, fake sessions. Смотрят консистентность device graph, install-to-click latency, event order, entropy по publisher/app bundle.
— Traffic quality anomalies: всплески с одного path, одинаковые page URL, неестественный fill + низкий time-on-page, mismatch между request rate и human traffic.
Сильный пайплайн не опирается на один vendor score. Он склеивает signals: ads.txt / sellers.json, supply-path, user-agent entropy, JS execution, viewability, click timing, post-bid validation. Чем раньше ловите аномалию — тем меньше мусора доходит до билда отчёта и аллокации бюджета.
Для паблишера полезно держать раздельно:
Если в отчёте есть только “invalid traffic”, вы видите симптом. Если есть разбиение по классам — уже можно чинить источник.
IVT обычно ломают на несколько слоёв, и детектить их надо по-разному. Если свалить всё в один bucket, отчёт будет шумным: часть инвентаря уходит в false positive, часть fraud проходит мимо.
— GIVT: бот-сети, дата-центры, известные crawler’ы, аномальные user-agent / IP / ASN, повторяющиеся паттерны запросов. Тут работают rules-based фильтры, threat intel, allow/deny lists, сигнатуры.
— SIVT: сложнее. Мутации креатива, hidden iframes, ad stacking, spoofing, injected clicks. Нужны поведенческие сигналы, viewability-цепочка, timing-анализ, JS telemetry, correlation между impression и interaction.
— SDK / app fraud: подмена device signals, install hijacking, click flooding, fake sessions. Смотрят консистентность device graph, install-to-click latency, event order, entropy по publisher/app bundle.
— Traffic quality anomalies: всплески с одного path, одинаковые page URL, неестественный fill + низкий time-on-page, mismatch между request rate и human traffic.
Сильный пайплайн не опирается на один vendor score. Он склеивает signals: ads.txt / sellers.json, supply-path, user-agent entropy, JS execution, viewability, click timing, post-bid validation. Чем раньше ловите аномалию — тем меньше мусора доходит до билда отчёта и аллокации бюджета.
Для паблишера полезно держать раздельно:
GIVT, SIVT, suspect, blocked. Тогда можно видеть, где у вас проблема: в источнике трафика, в размещении, в SDK или в цепочке поставки.Если в отчёте есть только “invalid traffic”, вы видите симптом. Если есть разбиение по классам — уже можно чинить источник.
American Home Shield упёрся в fragmentation: как теперь ловят «правильного» пользователя
American Home Shield пересобрал targeting strategy на фоне data fragmentation. Andrea Steele, director of media and marketing, прямо формулирует проблему: при сильно раздробленном attention уже сложно быть уверенным, что вы попадаете в right customer в right time.
Для programmatic это не про «ещё один сегмент». Когда media распадается по множеству точек входа, падает доверие к старым audience assumptions и растёт цена ошибки в DSP/SSP цепочке. Тут обычно всплывают не красивые dashboards, а разъезд между source-of-truth, reach и фактическим bid stream.
Если у вас сейчас SPO, identity graph или Prebid-targeting завязаны на устаревшие сегменты — пора сверить, где именно теряется match.
American Home Shield пересобрал targeting strategy на фоне data fragmentation. Andrea Steele, director of media and marketing, прямо формулирует проблему: при сильно раздробленном attention уже сложно быть уверенным, что вы попадаете в right customer в right time.
Для programmatic это не про «ещё один сегмент». Когда media распадается по множеству точек входа, падает доверие к старым audience assumptions и растёт цена ошибки в DSP/SSP цепочке. Тут обычно всплывают не красивые dashboards, а разъезд между source-of-truth, reach и фактическим bid stream.
Если у вас сейчас SPO, identity graph или Prebid-targeting завязаны на устаревшие сегменты — пора сверить, где именно теряется match.
Bid shading в DSP: как аукционный floor превращается в математику ставки
Bid shading нужен там, где DSP видит шанс выиграть дешевле своей «чистой» ценности. В first-price auction нельзя просто ставить predicted value: если победитель платит свою ставку, лишний маржа-буфер сразу утекает.
Технически shading — это преобразование v -> b, где v — оценка инвентаря, b — ставка после среза. DSP строит win probability и ожидаемую цену победы по историческому bid stream: частоты win/lose, распределение конкурентных ставок, floor-эффекты по placement / geo / device / hour.
Дальше модель ищет точку, где expected value максимален:
— слишком высокий bid: растёт win rate, но падает margin;
— слишком низкий bid: экономия есть, но теряется reach и нужный supply;
— слишком агрессивный shading: ломает delivery на редких сегментах и премиальном инвентаре.
Ключевая ошибка — делать один коэффициент на весь трафик. В реальном DSP shading обычно стратифицируют по кластеру: SSP, app/web, floor band, viewability tier, audience segment. Иначе модель переносит поведение дешёвого long-tail на дорогой supply и системно недобирает выигрыши.
Проверка простая: смотрите не только CPM, но и изменение win rate, spend pacing, ratio между bid и clearing price, а также смещение по supply path. Если после shading растёт доля проигрышей на тех же сегментах — модель режет слишком глубоко.
Нормальный shading — это не «сделать ставки ниже», а аккуратно приблизить bid к реальной цене клиринга.
Bid shading нужен там, где DSP видит шанс выиграть дешевле своей «чистой» ценности. В first-price auction нельзя просто ставить predicted value: если победитель платит свою ставку, лишний маржа-буфер сразу утекает.
Технически shading — это преобразование v -> b, где v — оценка инвентаря, b — ставка после среза. DSP строит win probability и ожидаемую цену победы по историческому bid stream: частоты win/lose, распределение конкурентных ставок, floor-эффекты по placement / geo / device / hour.
Дальше модель ищет точку, где expected value максимален:
— слишком высокий bid: растёт win rate, но падает margin;
— слишком низкий bid: экономия есть, но теряется reach и нужный supply;
— слишком агрессивный shading: ломает delivery на редких сегментах и премиальном инвентаре.
Ключевая ошибка — делать один коэффициент на весь трафик. В реальном DSP shading обычно стратифицируют по кластеру: SSP, app/web, floor band, viewability tier, audience segment. Иначе модель переносит поведение дешёвого long-tail на дорогой supply и системно недобирает выигрыши.
Проверка простая: смотрите не только CPM, но и изменение win rate, spend pacing, ratio между bid и clearing price, а также смещение по supply path. Если после shading растёт доля проигрышей на тех же сегментах — модель режет слишком глубоко.
Нормальный shading — это не «сделать ставки ниже», а аккуратно приблизить bid к реальной цене клиринга.
Direct deals vs open marketplace: где теряется маржа и когда ставить приоритет
Direct deal и open marketplace — это не про «лучше/хуже», а про разную структуру риска. В прямой сделке вы покупаете предсказуемость: фиксированный инвентарь, понятный floor, меньше шума в bid stream. В open marketplace — доступ к объёму и конкуренции, но с более высокой вариативностью по win rate, quality и pricing.
Если смотреть на экономику, сравнивайте не только CPM. Нужны: fill rate, viewability, IVT-фильтрация, latency, доля no-bid и post-bid loss. Direct deal часто выигрывает, когда важны конкретный placement, бренд-сейфти и стабильный delivery. Marketplace полезен там, где нужен масштаб, быстрый тест спроса и возможность выкупать остаток без ручной договорённости.
Ошибка — сравнивать каналы по одному KPI. В direct может быть выше CPM, но ниже потери на мусорный трафик и меньше отклонений по качеству. В open marketplace иногда дешевле вход, но итоговая стоимость качественного impression вырастает из-за конкуренции, селл-сайд фильтров и неэффективного supply path.
Для паблишера рабочая схема обычно такая:
— прямые сделки — для премиального инвентаря и guaranteed delivery
— open marketplace — для остатка и discovery demand
— отдельные floor-правила и когорты по device / geo / viewability
Если у вас в отчёте один line item «выглядит дороже», это ещё не сигнал. Смотрите на итоговую выручку на качественный impression и на то, какой путь даёт меньше утечек в аукционе.
Direct deal и open marketplace — это не про «лучше/хуже», а про разную структуру риска. В прямой сделке вы покупаете предсказуемость: фиксированный инвентарь, понятный floor, меньше шума в bid stream. В open marketplace — доступ к объёму и конкуренции, но с более высокой вариативностью по win rate, quality и pricing.
Если смотреть на экономику, сравнивайте не только CPM. Нужны: fill rate, viewability, IVT-фильтрация, latency, доля no-bid и post-bid loss. Direct deal часто выигрывает, когда важны конкретный placement, бренд-сейфти и стабильный delivery. Marketplace полезен там, где нужен масштаб, быстрый тест спроса и возможность выкупать остаток без ручной договорённости.
Ошибка — сравнивать каналы по одному KPI. В direct может быть выше CPM, но ниже потери на мусорный трафик и меньше отклонений по качеству. В open marketplace иногда дешевле вход, но итоговая стоимость качественного impression вырастает из-за конкуренции, селл-сайд фильтров и неэффективного supply path.
Для паблишера рабочая схема обычно такая:
— прямые сделки — для премиального инвентаря и guaranteed delivery
— open marketplace — для остатка и discovery demand
— отдельные floor-правила и когорты по device / geo / viewability
Если у вас в отчёте один line item «выглядит дороже», это ещё не сигнал. Смотрите на итоговую выручку на качественный impression и на то, какой путь даёт меньше утечек в аукционе.
Реклама ВКонтакте умерла: что происходит с Vk ADS в 2026 году
С апреля 2026 года реклама нутры во ВК стала убыточной из-за ужесточения модерации и изменений в её алгоритме. Креативы либо не проходят проверку по надуманным причинам, либо модерируются частично — одобрены только на площадках вне таргета, что исключает показы. Домены чаще банят, ссылки приходится менять, пиксели пересчитываются. В итоге цена лида выросла настолько, что вместо 10-20% ROI арбитражники получают -20% или -30% даже на объёме. На см…
С апреля 2026 года реклама нутры во ВК стала убыточной из-за ужесточения модерации и изменений в её алгоритме. Креативы либо не проходят проверку по надуманным причинам, либо модерируются частично — одобрены только на площадках вне таргета, что исключает показы. Домены чаще банят, ссылки приходится менять, пиксели пересчитываются. В итоге цена лида выросла настолько, что вместо 10-20% ROI арбитражники получают -20% или -30% даже на объёме. На см…
Brand safety и suitability — это не одно и то же: сигналы и правила фильтрации
Brand safety отвечает на вопрос: «можно ли вообще показывать рекламу рядом с этим инвентарём». Обычно сюда попадают жёсткие стоп-факторы: malware, adult, hate speech, piracy, dangerous content. Это слой блокировки, где решение должно быть максимально бинарным.
Suitability — более тонкий слой. Здесь инвентарь может быть «безопасным», но не подходить под конкретный бренд: новостной контекст, политические темы, трагедии, спорные обсуждения, UGC с высоким шумом. Один и тот же URL может быть acceptable для одного advertiser и excluded для другого.
На уровне сигналов разница такая:
— brand safety чаще опирается на page/app classification, domain, app bundle, URL, content keywords, IAB categories;
— suitability добавляет семантику, sentiment, adjacency, language, geo, publisher section, иногда page-level confidence score.
В интеграции это выглядит как два разных правила в pipeline:
1) сначала coarse blocklist по категориям и доменам;
2) потом contextual scoring и brand-specific exclusions;
3) отдельно — override-логика для whitelists / PMP / trusted supply.
Если смешать эти слои, вы получите либо лишний режект качественного трафика, либо слишком широкий допуск. Для Prebid и DSP полезно держать разные поля конфигурации: жёсткие категории отдельно, suitability-матчинг отдельно. Так проще объяснять отклонения в bid stream и не ломать отчёты по viewability и CTR.
Проверка простая: если правило можно описать как «нельзя никогда» — это brand safety. Если как «можно, но не для этого клиента» — это suitability.
Brand safety отвечает на вопрос: «можно ли вообще показывать рекламу рядом с этим инвентарём». Обычно сюда попадают жёсткие стоп-факторы: malware, adult, hate speech, piracy, dangerous content. Это слой блокировки, где решение должно быть максимально бинарным.
Suitability — более тонкий слой. Здесь инвентарь может быть «безопасным», но не подходить под конкретный бренд: новостной контекст, политические темы, трагедии, спорные обсуждения, UGC с высоким шумом. Один и тот же URL может быть acceptable для одного advertiser и excluded для другого.
На уровне сигналов разница такая:
— brand safety чаще опирается на page/app classification, domain, app bundle, URL, content keywords, IAB categories;
— suitability добавляет семантику, sentiment, adjacency, language, geo, publisher section, иногда page-level confidence score.
В интеграции это выглядит как два разных правила в pipeline:
1) сначала coarse blocklist по категориям и доменам;
2) потом contextual scoring и brand-specific exclusions;
3) отдельно — override-логика для whitelists / PMP / trusted supply.
Если смешать эти слои, вы получите либо лишний режект качественного трафика, либо слишком широкий допуск. Для Prebid и DSP полезно держать разные поля конфигурации: жёсткие категории отдельно, suitability-матчинг отдельно. Так проще объяснять отклонения в bid stream и не ломать отчёты по viewability и CTR.
Проверка простая: если правило можно описать как «нельзя никогда» — это brand safety. Если как «можно, но не для этого клиента» — это suitability.
551 млн daily ad requests и вертикальное видео: AdPlayer.Pro добрала outstream до 2.0
AdPlayer.Pro объявила о 551 млн ежедневных рекламных запросов и пиковом уровне 10 000 RPS.
Параллельно платформа добавила поддержку вертикального видео и обновила Interstitial Video Ads до версии 2.0 для всех типов outstream-рекламы.
Для programmatic это не просто рост инвентаря: outstream-сетка с вертикальным видео меняет креативный пайплайн, размеры плейсментов и поведение bid responses в видео-аукционе.
Если у вас закупка завязана на outstream, проверьте, не режется ли delivery на mismatch по format / aspect ratio и как новый формат проходит через ваш wrapper, DSP-правила и post-bid отчёты.
Вертикальное видео в outstream — это ещё и тест на то, где у вас реально теряется fill на стороне ad server, а где уже на стороне bidder.
AdPlayer.Pro объявила о 551 млн ежедневных рекламных запросов и пиковом уровне 10 000 RPS.
Параллельно платформа добавила поддержку вертикального видео и обновила Interstitial Video Ads до версии 2.0 для всех типов outstream-рекламы.
Для programmatic это не просто рост инвентаря: outstream-сетка с вертикальным видео меняет креативный пайплайн, размеры плейсментов и поведение bid responses в видео-аукционе.
Если у вас закупка завязана на outstream, проверьте, не режется ли delivery на mismatch по format / aspect ratio и как новый формат проходит через ваш wrapper, DSP-правила и post-bid отчёты.
Вертикальное видео в outstream — это ещё и тест на то, где у вас реально теряется fill на стороне ad server, а где уже на стороне bidder.
Cookieless targeting не умер: вот рабочие опоры вместо third-party cookie
Если смотреть на bid stream, то устойчиво работают не «магические ID», а связка из 4 слоёв: first-party data, контекст, publisher signals и согласованный identity layer. Один слой почти всегда даёт шум; связка даёт адресуемость без перекоса в CPM.
— First-party: CRM, события на сайте, сегменты по intent и frequency caps на своей стороне.
— Contextual: page taxonomy, keywords, semantic категории, placement-level rules.
— Publisher signals: geo, device, consent, time-of-day, recency, inventory type.
— Identity: UID2 / RampID / ID5 только там, где есть покрытие и валидный consent.
Главная ошибка — строить targeting только вокруг ID. После матчинга половина объёма всё равно уйдёт в cookieless окружение, и тогда выигрывает не «точность профиля», а качество сигнала на входе. Для performance это особенно заметно на pre-bid: плохой сигнал ломает и bid shading, и reach.
В инфраструктуре проверьте три вещи: 1) не дублируются ли сегменты между DMP и CDP; 2) не режется ли addressability из-за слишком жёстких frequency rules; 3) есть ли fallback-логика на contextual и placement-tier, когда identity не матчится.
Если у вас cookieless targeting держится только на одном ID-провайдере, это не стратегия, а зависимость. Нужен стек, где каждый слой может заменить соседний.
Если смотреть на bid stream, то устойчиво работают не «магические ID», а связка из 4 слоёв: first-party data, контекст, publisher signals и согласованный identity layer. Один слой почти всегда даёт шум; связка даёт адресуемость без перекоса в CPM.
— First-party: CRM, события на сайте, сегменты по intent и frequency caps на своей стороне.
— Contextual: page taxonomy, keywords, semantic категории, placement-level rules.
— Publisher signals: geo, device, consent, time-of-day, recency, inventory type.
— Identity: UID2 / RampID / ID5 только там, где есть покрытие и валидный consent.
Главная ошибка — строить targeting только вокруг ID. После матчинга половина объёма всё равно уйдёт в cookieless окружение, и тогда выигрывает не «точность профиля», а качество сигнала на входе. Для performance это особенно заметно на pre-bid: плохой сигнал ломает и bid shading, и reach.
В инфраструктуре проверьте три вещи: 1) не дублируются ли сегменты между DMP и CDP; 2) не режется ли addressability из-за слишком жёстких frequency rules; 3) есть ли fallback-логика на contextual и placement-tier, когда identity не матчится.
Если у вас cookieless targeting держится только на одном ID-провайдере, это не стратегия, а зависимость. Нужен стек, где каждый слой может заменить соседний.
На Githab выложили Opengram - самостоятельный сервер Telegram
Opengram — open-source аналог Telegram, который позволяет развернуть мессенджер на собственном сервере для внутренних нужд компании. Платформа поддерживает основной функционал официального клиента: группы, каналы, боты, видеозвонки и Bot API. Для работы можно использовать стандартные приложения Telegram (десктоп и мобила), изменив параметры подключения. Архитектура базируется на микросервисах в Docker Compose с инфраструктурой MongoDB, Redis, Ra…
Opengram — open-source аналог Telegram, который позволяет развернуть мессенджер на собственном сервере для внутренних нужд компании. Платформа поддерживает основной функционал официального клиента: группы, каналы, боты, видеозвонки и Bot API. Для работы можно использовать стандартные приложения Telegram (десктоп и мобила), изменив параметры подключения. Архитектура базируется на микросервисах в Docker Compose с инфраструктурой MongoDB, Redis, Ra…
Cookieless targeting работает только там, где есть собственный сигнал, а не надежда на магию DSP
Устойчивые варианты — это first-party data, контекст, publisher-level IDs и clean-room матчинг. Если у вас есть login/email hash, собранный с consent, его можно поднять в UID2, RampID или ID5 и использовать как deterministic-сигнал. Если идентификатора нет, не пытайтесь дотянуться до user-level таргетинга любой ценой: лучше собрать нормальный сегмент по поведению на своей площадке.
Контекст тоже не умер: semantic classification, page-level taxonomy и genre clusters дают предсказуемый reach без зависимости от third-party cookies. Для performance это работает лучше всего в связке с белыми списками инвентаря, частотным лимитом на уровне площадки и post-click/post-view раздельной атрибуцией. Иначе вы смешаете хороший контекст с мусорным supply.
Еще один рабочий слой — cohorting. Не хранить сырой user graph, а передавать в bid request агрегированные признаки: recency, affinity bucket, content intent, device class. Это снижает утечку идентичности и сохраняет управляемость аукциона. Важно: один и тот же сигнал не должен жить в трех местах одновременно — в user.ext, in-page script и DMP, иначе получите разъезд сегментов.
Если строите cookieless stack, начинайте с аудита сигналов: что у вас deterministic, что probabilistic, что просто шум. Потом оставляйте только те связки, которые можно объяснить в bid stream и проверить по uplift. Иначе cookieless targeting превращается в дорогой ретаргетинг по интуиции.
Устойчивые варианты — это first-party data, контекст, publisher-level IDs и clean-room матчинг. Если у вас есть login/email hash, собранный с consent, его можно поднять в UID2, RampID или ID5 и использовать как deterministic-сигнал. Если идентификатора нет, не пытайтесь дотянуться до user-level таргетинга любой ценой: лучше собрать нормальный сегмент по поведению на своей площадке.
Контекст тоже не умер: semantic classification, page-level taxonomy и genre clusters дают предсказуемый reach без зависимости от third-party cookies. Для performance это работает лучше всего в связке с белыми списками инвентаря, частотным лимитом на уровне площадки и post-click/post-view раздельной атрибуцией. Иначе вы смешаете хороший контекст с мусорным supply.
Еще один рабочий слой — cohorting. Не хранить сырой user graph, а передавать в bid request агрегированные признаки: recency, affinity bucket, content intent, device class. Это снижает утечку идентичности и сохраняет управляемость аукциона. Важно: один и тот же сигнал не должен жить в трех местах одновременно — в user.ext, in-page script и DMP, иначе получите разъезд сегментов.
Если строите cookieless stack, начинайте с аудита сигналов: что у вас deterministic, что probabilistic, что просто шум. Потом оставляйте только те связки, которые можно объяснить в bid stream и проверить по uplift. Иначе cookieless targeting превращается в дорогой ретаргетинг по интуиции.
Tap trading - новая игра на основе курса Solana
Duelbits запустила Tap Trading — игру на предсказание движения курса Solana за 10 секунд на основе реального биржевого курса. По сути это переупакованные бинарные опционы с двумя кнопками (вверх/вниз) и графиком цены, без выбора времени и валютной пары. Разработчик позиционирует продукт как прорыв в криптоиграх, но реально это копия давно известной схемы. Обновление на рынке, где бинарные опционы никто не забывал и остаются привлекательными для …
🧠 ещё больше CPA-инсайтов → https://t.me/+iRC9bTowfLw4ZDc8
Duelbits запустила Tap Trading — игру на предсказание движения курса Solana за 10 секунд на основе реального биржевого курса. По сути это переупакованные бинарные опционы с двумя кнопками (вверх/вниз) и графиком цены, без выбора времени и валютной пары. Разработчик позиционирует продукт как прорыв в криптоиграх, но реально это копия давно известной схемы. Обновление на рынке, где бинарные опционы никто не забывал и остаются привлекательными для …
🧠 ещё больше CPA-инсайтов → https://t.me/+iRC9bTowfLw4ZDc8
LFTO вышел на Nasdaq по $23 и в первые часы ушёл выше $30
Liftoff Mobile провела IPO на Nasdaq 3 июня 2026 года.
Размещение прошло по $23 за акцию, компания привлекла $437 млн.
В первые часы торгов котировки поднялись выше $30. Тикер LFTO стал первым крупным выходом AdTech на публичный рынок после MNTN в 2025 году.
Для programmatic-рынка это не просто тикер в ленте: публичная оценка начинает влиять на M&A-мультипликаторы, компы для DSP/SSP и переговоры по supply-side активам. Когда adtech выходит в public market, pricing дисциплина в SPO, identity-слое и inventory-quality становится заметнее в due diligence.
Если вы строите SSP/DSP-стек или продаёте premium supply, теперь LFTO придётся сравнивать не только с private peers, но и с рынком капитала.
Liftoff Mobile провела IPO на Nasdaq 3 июня 2026 года.
Размещение прошло по $23 за акцию, компания привлекла $437 млн.
В первые часы торгов котировки поднялись выше $30. Тикер LFTO стал первым крупным выходом AdTech на публичный рынок после MNTN в 2025 году.
Для programmatic-рынка это не просто тикер в ленте: публичная оценка начинает влиять на M&A-мультипликаторы, компы для DSP/SSP и переговоры по supply-side активам. Когда adtech выходит в public market, pricing дисциплина в SPO, identity-слое и inventory-quality становится заметнее в due diligence.
Если вы строите SSP/DSP-стек или продаёте premium supply, теперь LFTO придётся сравнивать не только с private peers, но и с рынком капитала.