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, но и с рынком капитала.
13 млрд impressions и +165% CTR: Stellantis встроил attention в DSP-байинг
Stellantis и IAS завершили одно из крупнейших исследований attention в digital ads: больше 13 млрд показов в 19 странах через IAS Quality Attention.
Метрики Quality Attention были встроены в programmatic-закупки через DSP. В тестах ad recall вырос на 33%, CTR — на 165% к традиционным кампаниям.
Для тех, кто живёт в bid stream, это важнее обычного viewability-отчёта: attention начинает влиять не только на post-bid аналитику, но и на сам медиабаинг в DSP.
Если у вас в сплите всё ещё решает только viewability, пора смотреть, как attention-сигналы ложатся в bidding rules, inventory quality и SPO-отбор.
Stellantis и IAS завершили одно из крупнейших исследований attention в digital ads: больше 13 млрд показов в 19 странах через IAS Quality Attention.
Метрики Quality Attention были встроены в programmatic-закупки через DSP. В тестах ad recall вырос на 33%, CTR — на 165% к традиционным кампаниям.
Для тех, кто живёт в bid stream, это важнее обычного viewability-отчёта: attention начинает влиять не только на post-bid аналитику, но и на сам медиабаинг в DSP.
Если у вас в сплите всё ещё решает только viewability, пора смотреть, как attention-сигналы ложатся в bidding rules, inventory quality и SPO-отбор.
Media is too big
VIEW IN TELEGRAM
Санкции на крипте: что делать с меченой криптовалютой
В конце мая 2026 года Великобритания санкционировала криптовалютные сервисы за работу с Россией, включая биржи Huobi Global и Exmo. Пользователи, получившие крипту от этих платформ, поймали метку «опасные источники» при AML-проверке, что затрудняет обмен и может привести к блокировке средств. При возникновении проблем нужно немедленно писать в поддержку с доказательствами легальности транзакций: скриншотами P2P-сделок, квитанциями от партнёрок …
🧠 Ещё больше инсайтов → в канале AFF.top
В конце мая 2026 года Великобритания санкционировала криптовалютные сервисы за работу с Россией, включая биржи Huobi Global и Exmo. Пользователи, получившие крипту от этих платформ, поймали метку «опасные источники» при AML-проверке, что затрудняет обмен и может привести к блокировке средств. При возникновении проблем нужно немедленно писать в поддержку с доказательствами легальности транзакций: скриншотами P2P-сделок, квитанциями от партнёрок …
🧠 Ещё больше инсайтов → в канале AFF.top
👉 По @server_attribution стоит подписаться на server side gtm — годный канал.
This media is not supported in your browser
VIEW IN TELEGRAM
В России введут комиссию за обмен USDT
Российский законопроект впервые чтения вводит регулирование криптовалют через пять категорий организаций и требует налогообложения прибыли криптообменников. Закон затронет популярные активы типа USDT и BNB, контролируемые недружественными странами. Основная цель — обязать обменники делиться доходами с бюджетом через комиссии и экономические стимулы, что в итоге увеличит затраты для рядовых пользователей и может стимулировать переход на альтернат…
➡️ Читайте на сайте: https://aff.top/blog/v-rossii-vvedut-komissiiu-za-obmen-usdt
🧠 Ещё больше инсайтов → в канале AFF.top
Российский законопроект впервые чтения вводит регулирование криптовалют через пять категорий организаций и требует налогообложения прибыли криптообменников. Закон затронет популярные активы типа USDT и BNB, контролируемые недружественными странами. Основная цель — обязать обменники делиться доходами с бюджетом через комиссии и экономические стимулы, что в итоге увеличит затраты для рядовых пользователей и может стимулировать переход на альтернат…
➡️ Читайте на сайте: https://aff.top/blog/v-rossii-vvedut-komissiiu-za-obmen-usdt
🧠 Ещё больше инсайтов → в канале AFF.top