IVT — не одна метка, а три слоя мусора в bid stream: как их разбирать без иллюзий

В anti-fraud обычно смотрят на три категории: GIVT, SIVT и technical noise. GIVT ловится правилами: data center IP, known bots, invalid UA, suspicious referrers, аномальные spikes по frequency и географии. Это не «сложный ML», а нормальная гигиена: если не фильтруете очевидное, downstream-метрики уже искажены.

SIVT детектится по совокупности сигналов: поведение сессии, тайминги, pattern reuse, несостыковка device graph, короткие dwell time, повторяемые scroll/click траектории. Здесь важны не отдельные триггеры, а score по нескольким источникам: SSP log, publisher logs, MMP/analytics, ad-server events.

Практический чек-лист для команды:
— сверять bid request с server-side логами по request_id;
— строить baseline по geo, device, placement, hour-of-day;
— искать повторяемые цепочки user-agent + IP + ASN;
— отдельно смотреть IVT по supply path, а не только по placement.

Если у вас нет раздельной классификации, любое расследование превращается в спор с вендором. Нужны три артефакта: raw log, правила отсева GIVT и очередь на ручной review SIVT. Тогда можно быстро понять, где фрод, где кривой трафик, а где просто шум.

Без сегментации IVT вы оптимизируете не spend, а собственную слепую зону.

Fable 5 скоро вернётся в публичный доступ

В исходном коде Claude Code обнаружены упоминания о возвращении модели Fable 5 в публичный доступ с изменённой моделью распространения — её больше не потребуется покупать отдельно, вместо этого будет применяться недельный лимит как для других моделей. Если информация подтвердится, пользователи платных тарифов смогут использовать Fable 5 в рамках своих подписок. Причины снятия ограничений по национальной безопасности остаются неясными. Хотя это п…

➡️ Читайте на сайте: https://aff.top/blog/fable-5-skoro-vernetsia-v-publichnyi-dostup

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

ID5, UID 2.0 и LiveRamp: как не сломать identity stack в programmatic

Если у вас в стекe одновременно сидят ID5, UID 2.0 и RampID, ошибка обычно не в самих провайдерах, а в архитектуре маппинга. Главный вопрос — где лежит source of truth: в CMP, в prebid userId module или в server-side sync.

— Не смешивайте разные scopes одного и того же пользователя в одном key-value без явного приоритета. Иначе bidder видит несколько ID и начинает деградировать match rate.
— Проверьте TTL и refresh policy: stale ID хуже, чем отсутствие ID. Для long-tail трафика это критично.
— Не отправляйте один и тот же ID в несколько id systems без нормализации consent-state; потом это ломает сегментацию и дедупликацию.

Практика: в client-side оставляйте only one primary ID provider на сессию, а остальные — как fallback. На стороне Prebid держите порядок userIds детерминированным, иначе разные страницы начнут отдавать разные значения в bidstream. В SSP/DSP логике отдельно учитывайте MAID, hashed email и publisher IDs — это разные сущности, даже если они совпадают по match rate.

Если нужен стабильный identity stack, проектируйте его как очередность приоритетов и правил истечения, а не как список интеграций.

ID5, UID 2.0 и LiveRamp: как выбрать identity layer без лишнего шума в bid stream

Если смотреть на stack через bid request, различия не в «бренде», а в том, где живёт граф и как он матчится:
— ID5 обычно удобен там, где нужен быстрый on-site consent-aware match и понятная интеграция в wrapper.
— UID 2.0 сильнее, если у вас есть first-party логика и вы хотите контролировать round-trip через токенизацию.
— LiveRamp чаще выбирают, когда важнее enterprise-матчинг и переносимость между DSP/SSP-слоями.

Проверять нужно не обещания в презентации, а три вещи: match rate по гео и device class, latency на auction path, и долю запросов, где ID вообще доезжает до bidder. Если ID приходит только в части трафика, не надо строить на нём core bidding logic — оставляйте его как enrichment layer, а не как single point of decision.

В интеграции чаще ломается не сам ID-провайдер, а конфигурация: неверный consent string, разный порядок enrichment в Prebid, отсутствие fallback на contextual, дублирование псевдонимов в user.ext. Для SPO полезно отдельно смотреть, где ID используется в request, а где только в post-auction measurement.

Практика простая: храните identity как модульный слой, тестируйте каждого провайдера на одном и том же inventory, и не смешивайте match-логику с логикой выбора bidder. Тогда смена ID-партнёра не превращается в переписывание всего auction stack.

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 превращаются не в разовые игры, а в систему улучшения карточки.