↩️ Пост из @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 собраны в одну цепочку. Если один слой выпадает, частота расползается по каналам, а вы оплачиваете лишние показы.