Google выпустил Android 17

Android получил встроенную Gemini с функциями автоматизации задач, конспектирования браузера и редактирования медиа. Обновление принесло новый интерфейс Bubble, двухкамерную запись и игровой режим для складных телефонов. Критический момент: Gemini Intelligence требует Gemini Nano v3 и минимум 12 ГБ RAM, что ограничивает аудиторию премиум-девайсов. Это создаёт потенциал для таргетинга криптооффера на узкий сегмент владельцев флагманов, готовых пл…

➡️ Читайте на сайте: https://aff.top/blog/google-vypustil-android-17

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

IAS и MOAT в стеке верификации: где у них пересекается логика, а где нет

IAS и MOAT часто ставят в один ряд, но интеграционно это разные слои. Оба инструмента смотрят на viewability, IVT и brand safety, но отличаются тем, когда и как принимают решение: один чаще работает как независимый verification layer, другой — как часть более плотного measurement-стека у части инвентаря и крупных закупок.

Для паблишера важнее не бренд вендора, а точка внедрения:
— pre-bid или post-bid;
— JS tag, SDK или server-side;
— влияет ли vendor на latency в wrapper;
— как мапятся categories, blocked domains, app bundles и page signals.
Если это не зафиксировать, в отчётах получится «одно и то же» viewability, но с разной методологией.

На практике сравнивают не интерфейсы, а три вещи: покрытие сигналов, детальность алертов и то, как быстро вы можете разложить фрод по source / deal / domain / app. Для SPO это критично: один вендор даст более удобную сегментацию по path, другой — лучше поймает подозрительный бандл или аномалии на креативе.

Правило простое: сначала определите, какой сигнал вам нужен для блокировки, а какой — только для пост-анализа. Тогда IAS и MOAT перестают быть «конкурентами» и становятся двумя разными фильтрами в одной воронке.

Frequency capping cross-platform ломается там, где у вас нет одного стабильного user key

Если web, in-app и CTV живут в разных идентификаторах, cap начинает считаться отдельно в каждом контуре. Итог — один и тот же человек видит 3–5 одинаковых показов, а отчёт по reach выглядит «чистым».

Рабочая схема простая:
— на входе нормализовать identity graph: UID2 / RampID / ID5 / MAID / household ID;
— хранить cap-state не в DSP, а в отдельном сервисе или key-value слое с TTL;
— считать окно по логическому audience key, а не по device.
Если ключа нет — fallback на context+site+device, но с коротким TTL и меньшим cap.

В запросе должно уходить не «сколько уже показали», а token/flag для decisioning: eligible / exhausted / near-cap. Это снимает гонку между DSP, SSP и server-side wrapper, где два bid request могут прилететь параллельно до записи в хранилище.

Для реализации важны три вещи: атомарный write, единая timezone-логика окна и синхронный reset по frequency period. Иначе cap сбрасывается в разное время на web и app, а это уже не баг отчёта, а реальный перерасход инвентаря.

Практика: сначала соберите cap по audience key на стороне ad decisioning, потом только размазывайте его по каналам. Иначе cross-platform capping превращается в набор несвязанных локальных лимитов.

Армения заблокирует онлайн-казино для получающих пособия

Армения ввела жёсткие ограничения на онлайн-гемблинг: запретила депозиты для получателей соцпособий и пенсий, ограничила остальным суммы до 20% дохода, обязала казино добавить кнопку самозапрета. Сайты, не подчинившиеся требованиям, будут заблокированы — технология реализации неясна. Проблемы с платёжками неизбежны. Криптоказино, вероятно, останутся без контроля, что открывает новый канал для залива трафика.

➡️ Читайте на сайте: https://aff.top/blog/armeniia-zablokiruet-onlain-kazino-dlia-poluchaiuschikh-posobiia

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

В DeepSeek добавили распознавание изображений

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

➡️ Читайте на сайте: https://aff.top/blog/v-deepseek-dobavili-raspoznavanie-izobrazhenii

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

📡 Запустили AFF.TOP — медиа про арбитраж, ИИ и вайб-кодинг

Разбираем новости из мира ИИ, тренды вайб-кодинга, инсайды индустрии арбитража — без воды и продаж курсов.

👉 Подписаться на канал AFF.TOP

ROAS attribution в programmatic ломается не в модели, а в отчётном фреймворке

Считать ROAS по last click в programmatic — значит смешать auction signal, post-view и post-click в одну корзину. Для нормальной отчётности сначала фиксируйте границы: окно атрибуции, тип конверсии, уровень агрегации и то, какие события вообще попадают в расчёт.

Базовый фреймворк:
— separate отчёты по post-click и post-view;
— один primary KPI на срез: revenue, orders или LTV;
— раздельно считать incremental lift и ассисты, не склеивая их в ROAS;
— помечать traffic source, exchange, deal id, placement, device и geo.

Дальше нужен контроль качества данных. Если в цепочке нет стабильных click_id / impression_id, а postback приходит с задержкой, ROAS начинает мигрировать между каналами из-за latency, а не из-за эффективности. Для этого полезны cohort-отчёты по дате показа и отдельный view-through sanity check: доля view-through не должна расти без изменения медиасплита.

На уровне анализа держите три слоя: campaign-level для бюджета, supply-path для площадки, creative-level для креатива. Когда один слой показывает рост, а другой падение, смотрите не на средний ROAS, а на распределение по placements и frequency. Именно там обычно прячется переатрибуция.

Если хотите управлять ROAS, а не спорить о нём, сначала сделайте отчётность несмешиваемой: одно событие — один контур, одна логика окна, одна версия truth source.

Google заставляет махать руками перед камерой

Google запустила новую капчу на основе распознавания движений — требует включённую камеру и помах руки перед экраном для подтверждения. Система отслеживает 21 точку-координату положения руки в реальном времени, а данные удаляются сразу после проверки. Для арбитражников это усложнит автоматизацию — обход вероятно будет работать через перехват хэша с положительным ответом. Капча пока на тестировании, но предвещает новый уровень защиты от ботов в и…

➡️ Читайте на сайте: https://aff.top/blog/google-zastavliaet-makhat-rukami-pered-kameroi

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

Логи RTB: какие поля сохранять, чтобы потом не гадать по CPM и fill

Если сохраняете только bid price и win notice — аналитика ломается на первом же спорном кейсе. Для разбора аукциона нужен не «лог события», а связка request → response → render.

В базовый набор кладите: request id, auction id, timestamp, publisher/app/site, placement/ad unit, imp id, floor, currency, device, geo, user agent, consent string, schain, ads.txt path, bidder name, timeout, bid price, net/gross, deal id, creative id, loss reason, win reason. Без request/imp id вы не склеите цепочку, без schain и floor не разберёте SPO и price pressure.

Отдельно храните контекст, который часто теряют: language, referrer, viewability signals, cache status, render fail, timeout bucket, no-bid reason, error code от adapter’а, response latency, seat id, domain/app bundle, consent status, user sync status. Именно эти поля объясняют, почему одинаковый placement даёт разный revenue.

Практика простая: raw-логи храните отдельно от агрегатов, нормализуйте названия полей, и не режьте «лишнее» до того, как построите дашборды по latency, bid density, win rate и loss reason. Тогда разбор деградации займёт минуты, а не ручной ресёрч по трём системам.

Как заработать 2500$ с УБТ трафика из Twitter’а не привлекая внимания санитаров

Арбитражник проkил органическbq трафик с X (Twitter) через связку с dating-офферами, используя маскировку ссылок под видеопревью. После полугода залива с марта по октябрь 2025-го он заработал скромный, но стабильный доход, внедрив динамическую генерацию страниц, обфускацию ссылок и cookie-разделение трафика для увеличения конверсии на треть. Основной вызов — постоянные баны доменом из-за обновлений Google и требований антифрода, из…

➡️ Читайте на сайте: https://aff.top/blog/kak-zarabotat-2500-s-ubt-trafika-iz-twitter-a-ne-privlekaia-vnimaniia-sanitarov

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

Prebid 9: какие изменения ломают конфиги и как пройти миграцию без сюрпризов

Если у вас живёт большой wrapper, проверяйте не только adUnits, но и весь контракт между page code, bidderAdapter и analytics. В Prebid 9 чаще всего больно не там, где “сломался бид”, а там, где тихо меняется форма данных и старые допущения уже не проходят.

Что обычно требует ревизии:
— bidder params: строгая валидация, мусорные поля лучше вычищать до релиза;
— events / hooks: если завязаны на кастомные тайминги, проверьте порядок вызовов;
— user sync и consent: CMP-логика должна быть явной, без неочевидных fallback’ов;
— floors / timeout / schain: убедитесь, что значения доходят до bidder без обрезки.

Переходный план простой: сначала прогоняете текущий конфиг через тестовый стек и смотрите, где валится schema validation. Потом сравниваете bid stream до и после миграции: количество bid responses, no-bid, timeout, cache hit. Отдельно проверяете adapters, которые живут на кастомных параметрах или нестандартных event listeners.

Если в wrapper есть свои плагинные слои, не тащите их “как есть”: лучше оставить минимальный core, а всё нестандартное вынести в отдельный модуль с явными контрактами. Так обновление Prebid перестаёт быть лотереей и становится обычной заменой зависимостей.

Curated marketplaces: где SSP режет long tail и зачем это паблишеру

Curated marketplace — это не «приватка с красивым названием», а отбор инвентаря и данных поверх open auction. SSP собирает supply, сегменты, правила доступа и продаёт пакет не по всему трафику, а по заранее описанному набору: домены, app bundle, geo, device, viewability, audience. Для buyer это меньше мусора в bid stream, для publisher — выше контроль над тем, кто вообще видит inventory.

Рабочая схема обычно такая: — curated пакет живёт как deal ID или отдельный PMPslot; — в deal попадают whitelist/blacklist, floor, format, allowed buyers; — иногда добавляют audience overlay из clean room или DMP. Главное тут не «премиальность», а предсказуемость: меньше SSP hops, меньше случайных bidders, меньше дублей между каналами.

Где curated marketplace полезен:
— на дорогом инвентаре, который нельзя отдавать в общий аукцион без фильтра;
— когда нужен SPO-контроль и прозрачный путь до buyer;
— когда у sales нет сил вручную собирать PMPs под каждого рекламодателя.

Риски тоже типовые: слишком узкий сегмент убивает конкуренцию, слишком широкий превращает curated в обычный open exchange с лишней комиссией. Проверяйте, есть ли у deal нормальный deal ID, не дублируется ли inventory в нескольких пакетах, и не теряется ли при этом bid density.

Если curated marketplace не меняет путь до buyer и не снижает мусор в аукционе — это просто новый ярлык на старом supply.

Открытые DSP вне big tech: где искать контролируемый стек без закрытого black box

Если нужен DSP, который можно интегрировать, ревьюить и не зависеть от одной экосистемы, смотрите на открытые и полу-открытые варианты вокруг RTB-стека, а не только на UI в кабинете.

Критерии отбора простые:
— есть документация по bid request / bid response и логам;
— можно подключить свой ID layer, deal-логики и pacing;
— понятны правила атрибуции win notice, loss reason, auction type;
— есть экспорт событий в свой BI, а не только агрегаты в дашборде.

Для self-hosted или гибридной схемы важны не «красивые фичи», а API вокруг core-функций: campaign management, frequency capping, budget control, seat-level permissions, creative QA. Если DSP не отдаёт сырые event logs, SPO и fraud-ревью будут слепыми.

Отдельно проверьте, можно ли работать с OpenRTB без vendor-specific расширений. Чем больше закрытых полей в request/response, тем дороже миграция и тем меньше шансов собрать единый supply-path pipeline между DSP, SSP и аналитикой. 🙂

Практика простая: сначала валидируйте прозрачность логов и контрактов, потом — медиакласс и инвентарь. В programmatic выигрывает не тот, у кого громче UI, а тот, у кого меньше невидимых слоёв между bid stream и отчётом.

Bid request enrichment ломает экономику аукциона, если не понимать, что именно доклеил SSP

В bid request enrichment SSP часто добавляет не только очевидные поля, но и скрытые допущения: гео по IP, device class, supply chain, доменный контекст, признаки инвентаря, derived floor. В итоге одна и та же impression в двух SSP выглядит как два разных аукциона.

Проверяйте, где поле пришло из publisher payload, а где сгенерировано на стороне SSP:
— geo / region / city: IP-based, not user-based
— schain / seller_id / pub_id: кто реально продаёт трафик
— content / cat / page / domain: нормализован или переписан
— device.ua / os / browser: иногда режется или агрегируется
— floor / deal info / pmp flags: может быть переупакован под свой routing

Главный риск — принимать enriched request как truth source. Тогда SPO-отчёт, фильтр по качеству и правила pacing начинают работать по чужой нормализации. Отсюда ложные выводы: “низкий bid density”, “плохой geo”, “не тот формат”, хотя проблема в том, что SSP дообогатила запрос своим слоем.

Практика простая: храните raw request отдельно от enriched, сравнивайте дельты по ключевым полям и помечайте, что пришло upstream, а что сгенерировано посредником. Это особенно важно для bidder debugging и reconciliation: без такой разметки bid stream превращается в набор красивых, но невалидируемых атрибутов.

Bid shading в DSP: где именно режется ставка и почему эффект не линейный

DSP шейдит не «ставку вообще», а собственную оценку вероятности победы в аукционе. Внутри обычно живут 3 слоя: модель clearing price, поправка на конкуренцию по площадке / supply path и ограничение по pacing. На вход идут bidstream, win notice, post-auction logs и история по конкретному inventory cluster.

Технически shading строится не от CPM в вакууме, а от распределения clearing prices по сегменту. Если DSP видит, что 80-й перцентиль выигрывает чаще, чем медиана, ставка сдвигается вниз до уровня, где marginal win rate ещё держит объём. Важно: одна и та же формула не переносится между geo, device, deal_id и time bucket.

Типичные ошибки:
— шейдить по всему exchange одним коэффициентом;
— не разделять open auction и PMP;
— игнорировать latency и timeout: «дешёвый» bid, пришедший поздно, = ноль;
— обучать модель на win rate без post-bid outcome, тогда она начинает экономить слишком агрессивно. 📉

Проверка простая: смотрите не только CPM, но и изменение win rate, spend, frequency of lost auctions on close price, а ещё долю запросов, где bid ушёл ниже floor. Если после shading растёт fill, но падает conversion-quality proxy, модель режет слишком глубоко.

Правильный shading — это не экономия любой ценой, а поиск точки, где margin растёт быстрее, чем теряется инвентарь.

Логи RTB бесполезны, если не сохранять поля, которые объясняют bid loss и win rate

Сохраняйте не только request/response, а связку идентификаторов: auction id, imp id, request id, seat id, bidder name, source / schain, seller id, site/app id, placement id. Без этого не собрать путь запроса через wrapper, SSP и downstream.

Из полезного в bid request обычно хватает:
— timestamp в UTC;
— device: ua, ip, ifa/uid, geo;
— geo, language, os, browser;
— adunit: format, size, floor, prebid timeout;
— consent/regs, deal id, adomain, currencies.

Из bid response фиксируйте:
— bid price, currency, ad markup type;
— ttl / exp, creative id, advertiser domain;
— dealid, meta: advertiser / network / agency если есть;
— errors, no-bid reason, timeout reason;
— rendered / viewable / win notice, если трекинг доходит до события.

Важно хранить не только сырые JSON, но и нормализованные поля для аналитики. Иначе одна и та же сущность будет называться по-разному в разных логах, а SPO и floor-аналитика развалятся на несовместимые таблицы. Отдельно сохраняйте версию схемы и source of truth для каждого поля.

Минимальный набор для дешборда: auction id, bidder, adunit, geo, floor, timeout, bid, win, deal, consent, reason. Этого хватает, чтобы искать утечки в bid stream, оценивать влияние таймаута и понимать, где режется fill rate.

Если место ограничено, режьте креативные детали, а не идентификаторы и причины отказа: именно они потом объясняют, почему аукцион не сошёлся.

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

Интервью с арбитражником, который отработал в сфере с 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