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

OpenRTB 3.0 полезен не “новизной”, а тем, что жёстче описывает контекст запроса и уменьшает серые зоны между DSP, SSP и exchanges. Для арбитражной команды это значит одно: меньше магии в маппинге и больше полей, которые надо валидировать на входе.

Смотрите в первую очередь на:
— source/request: не теряете ли chain of custody и seller identity;
— site/app/device: не дублируются ли ключи при прокидке из wrapper;
— regs/user: не режется ли consent при трансформации в backend;
— imp: один инвентарь — один корректный impression object, без “склейки” разных placement.

Типовая ошибка в арбитраже — пытаться маппить 2.5-структуру в 3.0 “как есть”. В итоге bidder видит пустой publisher, ломается категоризация, а downstream-модели начинают покупать мусорный трафик как premium. Второй класс проблем — кастомные расширения, которые живут только в одном adapter’е и исчезают при SSP-роутинге.

Что проверить перед миграцией:
1) сверить JSON-схему входящего bid request и ответов bidder’ов;
2) логировать потери полей на каждом hop;
3) отдельно тестировать consent, device, ext и seller metadata;
4) не смешивать transport-слой и business-логіку в одном mapper.

Если хотите использовать OpenRTB 3.0 без деградации ROI, сначала стройте поле-поле аудит bidstream, а уже потом включайте новый формат в прод.

Российские букмекеры увеличили закуп трафика с мобильных приложений

Российские букмекеры в 1 квартале 2026 года заметно нарастили закупку трафика из мобильных приложений. На фоне ужесточения регулирования они смещают бюджеты в новые каналы, где ещё есть живой трафик.

По данным UMG, доля in-app-рекламы выросла с 3-4% до 5-6% при объёме рынка около 10 млрд рублей. Но это может быть только начало — в блоге разбираем…

➡️ Читайте на сайте: https://aff.top/blog/rossiiskie-bukmekery-uvelichili-zakup-trafika-s-mobilnykh-prilozhenii

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

Mia Khalifa стала амбпссадором 1win

Mia Khalifa снова засветилась рядом с 1win: в Instagram она показала цепочку с логотипом бренда и статус «VIP 1win».

Параллельно всплыла история с ее ставкой на Испанию на ЧМ — по данным поста, выигрыш мог составить 200к$.

Официального подтверждения амбассадорства пока нет, но для арбитражников это уже повод для новых креативов. Что именно здесь…

➡️ Читайте на сайте: https://aff.top/blog/mia-khalifa-stala-ambpssadorom-1win

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

Короткий домен Telegram перестал работать

Telegram лишился домена t.me: он разделегирован и больше не работает на уровне регистратора. Платформа срочно переезжает на telegram.me, а владельцам крупных каналов стоит обновить публичные ссылки. Сроки восстановления неизвестны, и есть риск, что t.me не вернётся вовсе на фоне давления на Telegram.

➡️ Читайте на сайте: https://aff.top/blog/korotkii-domen-telegram-perestal-rabotat

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

Floor pricing в SSP ломают не цифры, а неверная сегментация инвентаря

Если ставить один floor на весь supply, вы почти всегда режете либо fill, либо revenue. Рабочая модель начинается с разбиения инвентаря по трем осям: geo, device и placement quality. Один и тот же placement может жить в разных коридорах floor — desktop homepage, in-article mobile, sticky slot.

Дальше смотрите не на средний CPM, а на распределение bid density. Если в сегменте много ответов ниже floor, поднимайте floor только там, где конкуренция стабильна. Если же bid landscape тонкий, жесткий floor просто срежет аукцион и утащит трафик в no-bid. Для SSP важнее не максимальный floor, а максимальная доля аукционов, где floor реально участвует в торге.

Практика настройки простая:
— начинайте с floor grid по placement tier;
— держите отдельные правила для app, web и AMP;
— исключайте low-quality demand и long-tail bidders из расчета общего floor;
— пересматривайте floor после смены mix: новый geo, новый формат, новый supply route.

Хороший floor — это не «дороже», а «точнее»: он отсекает шум, но не убивает конкуренцию. Если после подъема floor растет eCPM, но падает win rate и общий revenue, значит модель слишком грубая и ее надо резать по сегментам.

Youtube тестирует поиск с AI

YouTube начал тестировать Ask YouTube — поиск с ИИ, где можно задавать вопросы обычным языком и получать не список ссылок, а готовую подборку видео и фрагментов.

Фича уже доступна в США и работает на сложные запросы: если нужно, ИИ уточняет вопрос и подсказывает следующий шаг.

Что это значит для поиска на YouTube и когда новинка дойдёт до других…

➡️ Читайте на сайте: https://aff.top/blog/youtube-testiruet-poisk-s-ai

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

Curated marketplaces: где они режут мусор и почему buyer платит за отбор

Curated marketplace — это не «ещё один PMP», а слой селекции поверх supply. Вместо широкого инвентаря buyer получает заранее отобранные площадки, форматы или сегменты, собранные по правилам curator’а: по audience, контенту, viewability, ads.txt-сигналам, IVT-фильтрам, доменным спискам.

Рабочая схема обычно такая: seller отдаёт inventory в curated deal, curator ставит правила допуска, SSP/marketplace собирает package, а buyer покупает уже не весь exchange, а ограниченный набор supply paths. Это полезно, когда у вас есть: 1) жёсткие brand safety требования, 2) дорогой DSP-traffic, 3) задача снизить bid stream без потери доступного объёма.

Проверять надо не название deal, а механику: кто владеет селекцией, есть ли прозрачный inventory package, как считаются fees, не ломается ли freq cap на пути к DSP, не исчезают ли seller.json / schain сигналы, и можно ли сравнить curated path с open auction по win rate, CPM, viewability и post-bid IVT.

Для паблишера curated marketplace работает, если он не прячет supply, а поднимает его качество и цену через понятный фильтр. Для buyer’а — если curated слой сокращает количество бесполезных запросов и оставляет только те пути, где bid реально проходит аукцион.

Если curated deal нельзя объяснить на уровне supply path, schain и fee stack — это не оптимизация, а упаковка того же инвентаря в другой ярлык.

Z.ai анонсировала новую GLM-5.5

Z.ai готовит релиз флагманской GLM-5.5: модель обещают показать в августе 2026 года.

Главная интрига — рост до 1 трлн параметров при том же контекстном окне в 1 млн токенов. Новинка снова будет заточена под код и агентные задачи.

Почему версия сразу 5.5, без 5.3 и 5.4, и что это может означать для рынка — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/z-ai-anonsirovala-novuiu-glm-5-5

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

Telegram запустил собственный сервер для ботов

Telegram запустил собственный сервер для ботов и мани-приложений: теперь backend можно размещать прямо внутри инфраструктуры мессенджера.

Сервер работает на JavaScript/TypeScript, через вебхуки, и позволяет подключать SQL-базу для сбора контактов без посредников.

Пока неясны цена и ограничения — что именно уже можно тестировать, а где скрыт подв…

➡️ Читайте на сайте: https://aff.top/blog/telegram-zapustil-sobstvennyi-server-dlia-botov

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

Frequency capping cross-platform ломается не в DSP, а в идентификации и окне синхронизации

Если cap должен работать между web, in-app и CTV, одного user_id мало. Нужен слой маппинга: device graph, household graph или server-side профиль с нормализацией ключей. Иначе один и тот же человек получает лимит отдельно на каждом плейсменте.

Технически схема держится на трёх вещах:
— единый namespace для IDs: uid2 / RampID / internal_id;
— счётчик показов с TTL и time zone policy;
— правило агрегации: per-user, per-device, per-household или гибрид.
Если TTL не совпадает с окном cap, вы получите либо перерасход частоты, либо скрытый underdelivery.

На практике cap считают не в ad server, а в event-store или профиле на стороне first-party data layer. При каждом impression event пишется key вида id:campaign:window, а before-bid или before-serve проверяет лимит. Для кросс-девайсной логики важно, чтобы write path и read path использовали один и тот же identity resolver; иначе часть событий не попадёт в общий счётчик.

Отдельная ловушка — race condition при параллельных запросах. Если cap=3 и два запроса приходят почти одновременно, без atomic increment вы легко покажете 4-й раз. Решение: lock, compare-and-set или Redis INCR с корректным TTL и идемпотентным event_id.

Хороший cross-platform cap — это не настройка в UI, а маленькая система с ID graph, атомарным счётчиком и понятным окном. Если один из трёх слоёв плавает, frequency cap превращается в статистику, а не в правило.

Google картинки станут конкурентом Pinterest

Google Картинки начали превращать в полноценную платформу с персональной лентой по прошлым запросам — по сути, в аналог Pinterest.

Во вкладке For you уже тестируют подборки, а ещё обещают коллекции и генерацию изображений во встроенной Nano Banana.

Как это будет работать и когда новинка дойдёт до других стран — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/google-kartinki-stanut-konkurentom-pinterest

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

MOAT integration считает видимость, но не видит всю экономику показа

MOAT обычно закрывает три слоя: viewability, attention proxy и базовую фильтрацию IVT. Для паблишера это полезно как внешний контроль качества инвентаря, для DSP — как сигнал в post-bid аналитике. Но сам факт интеграции не означает, что данные можно напрямую сравнивать с ad server или bid stream.

Слепые зоны начинаются на границах. MOAT не знает, был ли креатив отрисован в скрытом iframe, как именно отработал wrapper timeout, и что произошло между bid response и render. Если у вас есть lazy load, sticky units, prerender или SPA-страницы, расхождения по viewable impressions почти неизбежны.

Отдельно проверяйте:
— сопоставление placement_id и size mapping;
— домены издателя в ads.txt / sellers.json;
— совпадение событий render, impression и measurable impression;
— долю blocked / not-measurable трафика по устройствам и браузерам. ⚙️

Если MOAT стоит в цепочке как единственный источник истины, вы будете недооценивать потери на уровне page latency и overcount в мульти-слотах. Правильная схема — сверять MOAT с логами ad server, wrapper events и сырым bid stream, а не лечить расхождения одной настройкой.

Итог простой: MOAT хорош как контроль качества, но не как замена трассировке показа. Сначала выравниваете события в цепочке, потом уже используете viewability как KPI, а не как спор между вендорами.