Как уходят из арбитража трафика: интервью с бывшим медиабайером

Интервью с арбитражником, который отработал в сфере с 2019 года и ушёл в другую профессию. Герой рассказывает о работе в Adcombo с тизерками, переходе в криптовертикаль и прямом выкупе трафика, а затем о причинах ухода: выгорание, сложности с поиском новой позиции и переоценка приоритетов. Статья развенчивает миф о лёгких деньгах в арбитраже — это обычная работа с высокими рисками, дефицитом информации и эмоциональным истощением. Выво…

➡️ Читайте на сайте: https://aff.top/blog/kak-ukhodiat-iz-arbitrazha-trafika-interviu-s-byvshim-mediabaierom

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

OpenRTB 3.0 для арбитража: где ломается маппинг и теряются деньги

OpenRTB 3.0 полезен не “новыми словами”, а тем, что жёстче раскладывает запрос по сущностям: source, site/app, device, regs, user, content, auction. Для арбитражной команды это означает одно: если вы парсите bid stream как плоский JSON, часть сигналов уедет в null или в неверный namespace.

— Проверьте маппинг source: supply chain, schain, publisher, inventory source. Ошибка здесь ломает SPO-аналитику и сравнение путей.
— Отдельно разведите site/app: гибридные трафик-пулы часто теряют контекст и получают неверный bidfloor или таргетинг.
— Не тащите legacy-поля “как есть”: в 3.0 часть атрибутов живёт в вложенных объектах, а bidder response должен отражать ту же структуру, иначе win notice и billing расходятся.

Для арбитража критичны три проверки: совпадает ли source chain с sellers.json, не теряется ли consent/IFA в user/device, и совпадает ли auction type с тем, что ждёт downstream DSP. Если у вас mixed-stack с header bidding, любая нестыковка между Prebid adapter и OpenRTB-3 endpoint даёт скрытую потерю fill или CPM, которую в отчёте видно только как “просадку качества”.

Практика простая: заведите JSON-schema валидацию на входе, логируйте diffs между 2.x и 3.0, и тестируйте не только bid request, но и bid response/win notice как единый контракт. Тогда миграция перестаёт быть “переклейкой полей” и становится контролем экономии аукциона.

DV360 API с 10 июня откроет Demand Gen ресурсы: rollout растянут на 2 недели

Google объявил: support для Demand Gen resources в Display & Video 360 API стартует 10 июня 2026.
Функцию раскатывают на партнёров в течение двух недель; к 24 июня она должна быть доступна всем.
После выката API получит get, create, delete и patch для этих ресурсов.

Для тех, кто держит DV360 automation, это прямой апдейт в работе с Demand Gen inventory и targeting через API.
Если у вас есть интеграции под campaign ops, стоит заранее проверить, где у вас зашиты ограничения на CRUD по этим сущностям и как это ляжет в пайплайн синхронизации.
Закрытая beta шла с 14 апреля — теперь это уже не тестовый контур, а нормальный production rollout.

Google наконец довёл API до ручек, которые нужны не только для read-only обвязки.

ByteDance анонсировала новую версию SeeDance версии 2.5

ByteDance готовит релиз Seedance 2.5 — видеогенератора нового уровня. Главное улучшение: модель сможет создавать 30-секундные видео за один прогон без склеек, вместо нынешних 15 секунд. Добавили локальный монтаж отдельных кадров, поддержку 3D-болванок для управления камерой, возможность использовать до 50 референсов и генерацию в 4К сразу. Закрытый бета-тест идёт сейчас, открытый релиз ожидается в начале июля. Технологически это шаг вперёд, но д…

➡️ Читайте на сайте: https://aff.top/blog/bytedance-anonsirovala-novuiu-versiiu-seedance-versii-2-5

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

Codex уничтожит твой SSD за год

Разработчик обнаружил критический баг в Codex CLI от OpenAI: агент непрерывно записывает логи в локальную SQLite-базу, перезаписывая за 21 день 37 ТБ данных. При таком темпе типичный SSD объёмом 1 ТБ (рассчитанный на 600 ТБ перезаписей) выходит из строя менее чем за год. OpenAI осведомлена о проблеме, но пока не исправляет её. Пользователям остаётся либо ждать обновления, либо переключиться на альтернативные CLI-инструменты без подобных недостат…

➡️ Читайте на сайте: https://aff.top/blog/codex-unichtozhit-tvoi-ssd-za-god

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

Bid request enrichment у SSP: какие поля реально добавляют ценность, а какие шумят

SSP часто расширяет bid request не только ради удобства, а чтобы поднять match rate, фильтровать supply и дать bidder'у больше сигналов для price discovery. Но не каждый enrichment полезен: чем больше полей, тем выше риск мусора, дублирования и расхождений между источниками.

Что обычно добавляют:
— site/app metadata: bundle, domain, pagecat, content, keywords
— device signals: UA, language, IP-производные, connection type, ifa/ifa_type
— seller context: seller_id, schain, ads.txt/app-ads.txt relations
— audience hints: segment IDs, cohort labels, GDPR/TCF consent flags
— transaction layer: deals, floors, auction type, ext-объекты

Главная проверка — не наличие поля, а его стабильность. Если enrichment плавает между SSP, bidder начинает переоценивать inventory или, наоборот, выкидывать его из-за low-confidence сигналов. Особенно это заметно на pagecat/content и audience segments: один и тот же supply может выглядеть как разные объекты в разных upstream.

Практика для валидации простая: логируйте raw request, сравнивайте заполненность по SSP, отмечайте поля, которые реально коррелируют с win rate и CPM, и отдельно режьте то, что только увеличивает payload. В SPO-отчётах enrichment полезен, когда он объясняет, почему один path продаётся лучше другого, а не когда просто раздувает JSON.

Чем чище enrichment, тем проще bidder'у принимать решение: оставляйте только те сигналы, которые меняют bid, а не те, которые красиво выглядят в схеме.

Открытая DSP без big tech: где реально собирать стек и не зависеть от одного кабинета

Открытые DSP живут не как «волшебная кнопка», а как набор модулей: bidder, decisioning, pacing, reporting, anti-fraud, identity. Если собирать стек вне big tech, смотрите не на бренд, а на три вещи: есть ли доступ к raw bid stream, можно ли контролировать auction logic, и вытаскиваются ли события в свой warehouse без ручного экспорта.

Базовый чек-лист для оценки:
— OpenRTB поддержка без урезания полей source, schain, regs, user, imp.ext
— нормальная работа с first-party IDs и consent string
— прозрачный path к logs, win notices, bid responses
— возможность подключать собственный pre-bid filtering и SPO rules
— нормальный seat / deal / domain governance без «черного ящика»

Для publisher-side это особенно важно: если DSP не отдает нормальные логи и не объясняет, почему бид отклонен, вы не увидите ни leakage, ни перекосы по geo/device, ни проблемы в floor strategy. Для in-house performance-команд главный риск другой: закрытый decisioning ломает эксперименты с pacing, frequency capping и inventory split.

Собирайте стек так, чтобы заменять один слой без миграции всего контура. Иначе любой рост CPM превращается в зависимость от одного вендора, а SPO остается только в презентации.

Google ужесточает модерацию финансовой вертикали

Google ужесточает модерацию финансовых офферов в ЕС и ЕЭЗ, введя двухэтапную верификацию через G2 Risk Solutions и Google Ads. Проверка затронет 24 страны, включая Австрию, Польшу, Нидерланды и другие члены союза. На прохождение модерации отводится 30 дней — за это время некоторые связки успеют отработать до вступления требований в силу. Для арбитражников это означает необходимость подготовиться к усложнению процесса запуска финансовых кампаний …

➡️ Читайте на сайте: https://aff.top/blog/google-uzhestochaet-moderaciiu-finansovoi-vertikali

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

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