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

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

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

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

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

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

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

Всё это выглядит забавно, но давайте не забывать, в какой сфере мы работаем и что реально может произойти с жирным троллем за воровство нейминга. Впрочем, толстому не привыкать отхватывать пиздов за проделки в интернете, поэтому ждем очередную фотку разбитого ебала и длинный пост с извинениями. 😏😏😏

В арбитраже денег нет 💵

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Curated marketplaces: где прячется premium inventory и почему не весь PMP одинаковый

Curated marketplace — это не просто PMPs с красивым названием. По сути это отобранный supply-пул с заранее зафиксированными правилами: какие domains / app bundle допускаются, какой floor, какой buyer set и какие deal IDs доступны. Для паблишера это способ упаковать inventory без полного open auction; для покупателя — купить предсказуемый путь, а не размазанный bid stream.

Ключевая разница с обычным open marketplace: меньше шума в request, выше доля релевантных bid responses, проще контролировать brand safety и SPO. Но curated не равно premium автоматически: если в цепочке лишний SSP-hop, слабая seller.json дисциплина или дублирующиеся paths, часть value всё равно утекает.

Проверять надо три вещи:
— логика отбора supply: whitelist по app/site, device, geo, ads.txt/sellers.json;
— экономика сделки: floor vs clearing, есть ли конфликт с open auction;
— операционка: кто обновляет инвентарь, кто чистит dead deal IDs, кто отвечает за timeout и frequency caps.

Для buyer-side curated полезен там, где важны repeatability и post-buy анализ: проще сравнивать CPM, win rate и viewability между одинаковыми пакетами. Для publisher-side это инструмент монетизации без полного разрыва с open market, но только если curated не превращается в “ещё один слой посредников”.

Если curated marketplace нельзя объяснить через supply chain и инкрементальный lift, значит это не оптимизация, а упаковка.

↩️ Пост из @native_ads_bench_arb:

Как масштабировать связку и не убить ROI на втором же сплите

Масштабирование ломает не креатив, а дисциплину. Рабочая связка почти всегда умирает из-за резкого роста бюджета, смены гео, расширения аудитории без проверки и попытки выжать из победителя «еще чуть-чуть» без контроля метрик.

Сначала фиксируй базу: CTR, CPL, CR по ленду, процент отлива по этапам воронки. Если растет объем, а проседает один из этих показателей — это не масштаб, а деградация трафика. Цифры не врут, врет их интерпретация.

Рабочая схема масштабирования:
— увеличивай бюджет ступенчато, а не рывком;
— дублируй связку на соседние сегменты, а не смешивай все в один пул;
— меняй только один параметр за тест: креатив, оффер, аудиторию или плейсмент;
— держи резервный набор креативов: выгорание часто начинается раньше, чем виден провал по ROI.

Если связка держит экономику на 3–5 тестах подряд, можно добавлять объем. Если результат живет только на одном креативе и одной аудитории — это не масштабируемый актив, а удачный спот. Тестируем гипотезу, считаем экономику, масштабируем результат.

Curated marketplaces: где ручной SPO ломает аукцион и как это проверить в bidstream

Curated marketplace — это не «премиум-полка», а слой отбора supply: площадки, seat’ы, domain/app-списки и условия доступа к инвентарю. На входе остаётся тот же RTB, но урезается число путей, по которым bidder видит и покупает один и тот же impression.

Работает это обычно так: SSP или реселлер собирает inventory в curated deal, ограничивает sellers, иногда добавляет floor, контекст, device/geo-фильтры и продаёт это как упакованный path. Для buyer’а плюс в том, что меньше мусора в bid stream; минус — часть «широкого» reach и конкуренции уходит в закрытый контур.

Проверять curated надо не по CPM-легенде, а по трём метрикам: 1) доля совпадающих impression в open auction и curated path, 2) разница в win rate на одинаковых сегментах, 3) post-bid quality: IVT, viewability, domain/app consistency. Если curated-path даёт тот же reach, но режет лишние sellers — это экономия. Если он просто дублирует open auction, вы платите за упаковку.

На практике полезно смотреть ads.txt / sellers.json цепочку, совпадение inventory source и наличие лишних hops. Чем короче путь до паблишера, тем легче объяснить, где теряется маржа и почему один и тот же supply продаётся дороже через «отборную» витрину.

Итог простой: curated marketplace имеет смысл только там, где он уменьшает шум, а не маскирует тот же инвентарь новым названием.

Cookieless targeting держится не на одном ID, а на связке сигналов

Cookieless ломает не таргетинг, а привычку матчить всё через один ключ. Рабочая схема — собирать несколько сигналов и смотреть их в bid stream: user.eids, site.content, device.geo, schain, consent flags.

— First-party ID: логин, email-hash, CRM-сегмент. Нужны TTL, namespace и стабильная передача через Prebid userId modules.
— Contextual: taxonomy контента, URL depth, keywords, language. SSP должен видеть не только domain, но и section/page metadata.
— Cohorts / clean rooms: годятся для reach, но требуют отдельного frequency и overlap-контроля.
— Seller data: сегменты паблишера в PMP, если прозрачен seat и источник данных.

Проверка: сравнить bid rate, win rate и post-bid метрики по каждому сигналу отдельно. Если ID повышает bid rate, но не даёт lift по конверсии или viewability — это шум.

Не ищите «замену cookie». Собирайте signal graph: ID там, где есть consent; контекст там, где ID нет; PMP там, где нужен предсказуемый инвентарь.

First-price auction ломает старые допущения: в RTB выигрывает не «второй», а твой максимум

В second-price bidder мог ставить выше своей реальной готовности платить: списывалась цена второго места плюс шаг. В first-price это не работает — в билле обычно уезжает сам bid. Поэтому одинаковый CPM в логах и в spend больше не означает одинаковую экономику.

Для паблишера first-price упрощает аукцион, но делает торги чувствительнее к bid shading и latency. Если у части demand long-tail bidders отвечают медленно, их реальный win-rate падает не из-за качества, а из-за таймаута. На стороне wrapper это видно как рост «пустых» аукционов при том же traffic.

Что проверять в конфиге и отчётах:
— bid floor не должен быть единственным рычагом; иначе ты просто режешь конкуренцию
— timeout в Prebid и server-side path надо синхронизировать
— аналитика должна сравнивать bid, win price и clearing price отдельно
— у bidder’ов нужен контроль shading-логики, иначе RPM может просесть даже при стабильном bid density

Коротко: first-price — это не «дороже», а «прозрачнее для выигрыша и жёстче к ошибкам в торгах». Если в аукционе не разведены bid, floor и effective price, ты теряешь деньги, не понимая где именно.

В роликах Youtube теперь можно рекламировать товары Amazone

➡️ Читайте на сайте: https://aff.top/blog/v-rolikakh-youtube-teper-mozhno-reklamirovat-tovary-amazone

🧠 Ещё больше инсайтов → в канале AFF.top

Google выпустил Gemini Omni 1.1 Flash

Google обновил Gemini Omni для генерации видео: модель умеет продолжать сцены с учётом до 10 секунд контекста и собирать ролик до 40 секунд, работать по референсу и делать переходы между кадрами. Главный вывод — инструмент стал практичнее для продакшена, а посекундная цена делает его заметно доступнее для тестов и рабочих задач.

➡️ Читайте на сайте: https://aff.top/blog/google-vypustil-gemini-omni-1-1-flash

🧠 Ещё больше инсайтов → в канале AFF.top

Топ 5 PWA-сервисов для залива дейтинга

Статья показывает, что PWA выгодны не только для гемблы: в дейтинге они дают пуш-базу, больше траста и помогают маскировать оффер под бренд. Главный выбор зависит от цены инсталлов и теста GEO: для старта лучше бесплатные или дешёвые решения, а Progressier выделяется как самый практичный вариант для залива дейтинга.

➡️ Читайте на сайте: https://aff.top/blog/top-5-pwa-servisov-dlia-zaliva-deitinga

🧠 Ещё больше инсайтов → в канале AFF.top

Логи RTB бесполезны, если не сохранять поля, по которым потом строится разбор аукциона

Базовый минимум: bidrequest id, auction type, timestamp, exchange, seat, publisher/app/site, ad unit, geo, device, schain, ads.txt / app-ads.txt статус, currency, floor, timeout, winner, clearing price, loss reason.

Для аналитики по SPO и fill rate критичны идентификаторы путей: sourceid, supply chain nodes, seller id, publisher id, domain / bundle, placement id, page / app url, deal id, deal type. Без них вы видите только CPM, но не понимаете, где именно теряется спрос.

Если работаете с bid stream, отдельно сохраняйте: bid status, bid time, latency по каждому bidder, timeout hit, no-bid, malformed response, creative id, deal eligibility, blocked categories, viewability signals, consent flags, user id type. Это позволяет отличать проблему интеграции от проблемы качества трафика. ⚙️

Не храните всё подряд: нормализуйте поля по двум слоям — raw log для расследований и fact table для отчетов. Иначе через месяц упрётесь в дорогой storage и несовместимые схемы между SSP, Prebid и GAM.

Практика простая: если поле помогает ответить на вопрос «почему проиграли аукцион», «почему не дошёл бид» или «почему трафик ушёл в мусор», его нужно логировать. Если не помогает — оставьте в сыром слое и не тащите в витрину.

🔥 Новый участник НеТОПа на AffPapa!
https://affpapa.org/netop

🏆 НеТОП на AffPapa — https://affpapa.org/netop/go/27?src=broadcast
Платный рейтинг индустрии: плати больше — стоишь выше. Займи место в топе за USDT.
💰 Ставка: $100 · сейчас #1 в рейтинге

🔥 justbrand_create — новый участник рейтинга НеТОП на AffPapa!

🏆 Своё место в топе честно купил justbrand_create: https://affpapa.org/netop/go/28?src=broadcast

💰 Ставка: $111 · сейчас #1 в рейтинге

Весь рейтинг → https://affpapa.org/netop

Frequency capping cross-platform ломается там, где identity не склеен на уровне request path

Если cap нужен между web, app и CTV, одного cookie/localStorage мало. Нужен единый ключ: user_id из login graph, UID2/RampID, или хотя бы внутренний stable ID, который маппится на все устройства. Без этого каждый канал считает частоту отдельно, а пользователь видит одно и то же крео в разных поверхностях.

Техническая схема обычно такая: на входе bid request нормализуется в один user bucket; на edge или в backend лежит counter store с TTL; before-bid проверка решает, можно ли вообще отдавать impression. Для низкой латентности используют Redis / KeyDB / Aerospike, а для длинного горизонта — отдельный event log, чтобы не терять счетчики при рестарте.

Критичные детали:
— cap считается по атрибутам campaign + creative + geo + device class;
— окно cap и reset policy должны быть одинаковыми во всех каналах;
— учет показов нужен не только по win notice, но и по render/visible impression, иначе счетчик врёт;
— для offline sync держите idempotency key, иначе ретраи раздуют frequency.

Отдельная ловушка — delay между impression и обновлением counter. Если проверка делается только после показа, вы уже успеете перелить пользователя. Поэтому лучше: pre-bid read, post-impression write, периодическая reconciliation по логам. Иначе frequency capping превращается в постфактум-отчет, а не в control plane.

Итог простой: cross-platform cap работает только там, где identity, storage и event semantics собраны в одну цепочку. Если один слой выпадает, частота расползается по каналам, а вы оплачиваете лишние показы.