Pre-bid filtering: где именно в цепочке решается, пустить ли трафик в аукцион

Fraud-решение не живёт в одном месте. В нормальном стеке фильтрация расползается по трём уровням: до отправки bid request, на уровне SSP/Exchange и уже в post-bid верификации. Если смотреть только на один слой, легко перепутать GIVT с техническим шумом или пропустить SIVT, который проходит через слишком мягкий pre-bid rule set.

На практике pre-bid фильтруют по сигналам: ads.txt / sellers.json, domain/app consistency, geo/device mismatch, подозрительный user-agent, аномальный supply chain, пустые referrer’ы, кривой bundleId / app-ads.txt. Это не “антифрод-модуль”, а gatekeeper: он решает, попадёт ли impression в bid stream вообще. Чем раньше отсечёте мусор, тем меньше платите за лишние bid responses и меньше раздуваете отчётность.

Важно не смешивать роли: publisher-side wrapper может резать трафик по качеству инвентаря, SSP — по своим риск-скорингам, DSP — по bid shading, частоте и IVT-сигналам, а vendor вроде IAS/MOAT — подтверждать уже после факта. Если все решения свалены в один отчёт, вы не увидите, где именно теряется win rate и кто реально заблокировал supply.

Рабочая схема простая: логируйте причину отклонения на каждом хопе, держите отдельные правила для домена, app, device и seller chain, а спорные сегменты выносите в отдельный allowlist/denylist review. Тогда можно быстро понять, это плохой supply, слишком агрессивный фильтр или ошибка в атрибуции инвентаря.

Итог: pre-bid filtering нужен не для “максимального банна”, а для точного разделения шума, риска и нормального inventory.

Chat GPT-5.6 будут выдавать лишь избранным

США ограничивают публичный доступ к новым ИИ-моделям: теперь его выдают только проверенным пользователям после обязательной 30-дневной процедуры верификации. Сэм Альтман называет это самым быстрым путём к публичному релизу. Эффективность меры вызывает сомнения — китайские разработчики традиционно копируют модели в течение суток после выхода.

➡️ Читайте на сайте: https://aff.top/blog/chat-gpt-5-6-budut-vydavat-lish-izbrannym

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

Vk удалили из App store: что дальше?

Удаление VK из App Store заблокировало доступ для владельцев iPhone в России, но проблема решаема. Арбитражники теряют один канал, но не аудиторию — 20–30 млн пользователей iOS остались на месте. Вместо VK стоит переориентироваться на альтернативные источники: Telegram Ads с таргетингом на iOS, push-сети типа AdProfex, MTS Ads и Beeline Ads. VK может последовать примеру Max и запустить PWA-приложение для восстановления уведомлений. Главный вывод…

➡️ Читайте на сайте: https://aff.top/blog/vk-udalili-iz-app-store-chto-dalshe

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

First-price auction в RTB: почему “ставка = цена” меняет экономику цепочки

В second-price bidder может ставить чуть выше своей true value и платить не максимум ставки. В first-price выигрываешь и платишь ровно свой bid. Для DSP это ломает старую логику “bid high, pay second”, а для паблишера делает цену прозрачнее, но сильнее завязана на quality signals и latency.

Что меняется на практике:
— bid shading становится обязательным элементом, иначе CPM быстро уходит в переплату;
— timeout и порядок ответа bidder'ов влияют на win rate сильнее, чем в second-price;
— SPO/quality filtering начинают давать прямой эффект: плохой supply дороже на уровне аукциона;
— floor price работает жестче: если bid близко к floor, space для манёвра почти нет.

Для Prebid это означает: следите не только за CPM, но и за dispersion между gross bid и clearing price. Если bidder стабильно выигрывает, но eCPM проседает, ищите слишком агрессивный shading, слабый viewability score или длинный путь до exchange. В GAM и на SSP-стороне first-price особенно заметен в PMPs: там любые перекосы в таймингах сразу отражаются в win rate.

Чек-лист перед разбором bid stream: 1) сравните win rate по bidder'ам; 2) посмотрите, где bid = pay почти всегда; 3) проверьте floor rules по geo/device; 4) отделите low-quality inventory, который тянет среднюю цену вниз.

Вывод простой: в first-price нельзя оптимизировать только ставку. Нужно одновременно крутить shading, timeout, SPO и floors — иначе вы просто платите больше за тот же объём.

Pre-bid filtering: где именно в цепочке рождается решение о fraud

Проблема не в одном «антифроде», а в нескольких точках отсечения. До аукциона обычно смотрят на sellers.json, ads.txt/app-ads.txt, domain/app bundle, device/geo mismatch, invalid traffic сигналы, а также на качество supply path. Если флаг ставится поздно, вы уже платите за мусорный bid stream.

Разделяйте уровни:
— Supply-level: режем заведомо плохие площадки, резолвы домена, невалидные bundle ID, подозрительные resellers.
— Request-level: фильтруем по IP/UA/device, spoofing, аномальным частотам запросов, consent/IFA пустым там, где это не бьёт по логике инвентаря.
— Auction-level: понижаем участие там, где bid request выглядит чисто, но path слишком длинный или source не бьётся с inventory owner.

Ключевая ошибка — смешивать блокировку и скоринг. Блокировка нужна для жёстких нарушений, скоринг — для серых зон, где полезнее урезать bid rate, чем убивать fill. Иначе антифрод начинает ломать нормальный трафик, особенно в long-tail инвентаре.

Практика для Prebid/GAM простая: держите отдельные правила на уровне SSP, publisher-side filtering и post-bid verification. Тогда можно понять, где именно падает quality: в source, в request или уже в ответе bidder.

Ищите fraud не «в целом по стеку», а по точке принятия решения: чем раньше отсечение, тем меньше waste и меньше ложных банов.

Store listing experiments в Google Play Console: как не слить трафик на плохой тест

Эксперименты по карточке — это не «покрутим кнопку и посмотрим». Это инструмент для проверки гипотез по иконке, скриншотам, заголовку и описанию. Если тестить всё сразу, вы не поймёте, что именно сдвинуло конверсию.

Что важно перед запуском:
— меняйте один главный элемент за раз;
— берите страницу с нормальным трафиком, иначе данных не хватит;
— заранее фиксируйте метрику успеха: install rate, CTR или conversion to install;
— не делайте выводы по ранним колебаниям, ждите достаточный объём.

На практике чаще всего ошибаются в двух местах: подменяют тест креативом, который слишком сильно отличается от базовой версии, и запускают эксперимент без понятной сегментации по странам. В итоге победитель может хорошо смотреться только в одном языке или на одном типе аудитории.

Ещё одна рабочая привычка — хранить гипотезы в отдельном списке: что именно проверяли, почему ожидали рост, какой был результат. Тогда store listing experiments превращаются не в разовые игры, а в систему улучшения карточки.

Prebid 9 ломает не интеграцию, а привычку держать конфиг «как было»

Главный риск при переходе — не bidder’ы, а скрытые зависимости: кастомные event hooks, нестандартные adapter params, старые timeout-логики и ручные overrides в analytics. Если wrapper живёт дольше одной команды, сначала инвентаризируйте всё, что трогает auction, sync и consent.

Переходный план лучше строить так:
— снять diff текущего prebid.js config и списка adapters;
— проверить, где используются deprecated поля в bidder settings и userSync;
— прогнать отдельный аудит timeout’ов: отдельный для top bidders, отдельный для long-tail;
— сверить, не завязан ли GAM line item setup на старые ключи keyValue targeting.

Отдельный блок — privacy и identity. Любые изменения в consent flow, eids и shared IDs сначала проверяйте на уровне bid request/response, а не в UI wrapper’а. Если supply path собирается через несколько SSP, важно убедиться, что новые значения не ломают deal matching и frequency capping. ⚙️

После миграции держите два спринта под shadow-test: сравнивайте bid rate, win rate, timeout share и долю no-bid по каждому ключевому bidder’у. Если метрики просели, ищите не «плохой биддер», а рассинхрон между config, adapter contract и downstream mapping.

Лучший апгрейд — тот, после которого вы можете удалить старые костыли, а не добавить ещё один compatibility layer.

Brand safety и suitability путают в отчётах, а сигналы у них разные

Brand safety отвечает на вопрос: можно ли вообще рядом с этим инвентарём показывать рекламу. Suitability — подходит ли конкретному бренду, даже если площадка формально безопасна. Первое режет явный риск, второе работает поверх него и зависит от контекста, категории и tolerance бренда.

На уровне сигналов brand safety обычно смотрит в:
— URL, app bundle, page title, keywords
— semantic classification content
— ads.txt / sellers.json / app-ads.txt как часть trust chain
— IVT, viewability, domain/app spoofing

Suitability добавляет слой business rules:
— category adjacency: рядом с каким контентом допустим показ
— sentiment and tone: нейтральный, спорный, острый
— audience context: для B2B и FMCG один и тот же page context может оцениваться по-разному
— exclusions по темам, которые бренд считает репутационно токсичными, даже если они не нарушают policy

Главная ошибка — строить один universal blocklist. Он убивает reach и не решает задачу. Нужны два контура: жёсткий blacklist для brand safety и отдельная матрица suitability по advertiser / line item / deal. Иначе вы либо переплачиваете за слишком чистый инвентарь, либо ловите показы в формально безопасном, но неподходящем окружении.

Практика простая: сначала нормализуйте сигналы контента, потом заведите taxonomy для категорий, а уже поверх неё — policy mapping по брендам. Тогда отчёт перестаёт быть просто списком blocked domains и начинает объяснять, почему инвентарь не прошёл отбор.