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, значит модель слишком грубая и ее надо резать по сегментам.
Если ставить один 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, значит модель слишком грубая и ее надо резать по сегментам.
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Youtube тестирует поиск с AI
YouTube начал тестировать Ask YouTube — поиск с ИИ, где можно задавать вопросы обычным языком и получать не список ссылок, а готовую подборку видео и фрагментов.
Фича уже доступна в США и работает на сложные запросы: если нужно, ИИ уточняет вопрос и подсказывает следующий шаг.
Что это значит для поиска на YouTube и когда новинка дойдёт до других…
➡️ Читайте на сайте: https://aff.top/blog/youtube-testiruet-poisk-s-ai
🧠 Ещё больше инсайтов → в канале AFF.top
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 — это не оптимизация, а упаковка того же инвентаря в другой ярлык.
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 — это не оптимизация, а упаковка того же инвентаря в другой ярлык.
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
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
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
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Telegram запустил собственный сервер для ботов
Telegram запустил собственный сервер для ботов и мани-приложений: теперь backend можно размещать прямо внутри инфраструктуры мессенджера.
Сервер работает на JavaScript/TypeScript, через вебхуки, и позволяет подключать SQL-базу для сбора контактов без посредников.
Пока неясны цена и ограничения — что именно уже можно тестировать, а где скрыт подв…
➡️ Читайте на сайте: https://aff.top/blog/telegram-zapustil-sobstvennyi-server-dlia-botov
🧠 Ещё больше инсайтов → в канале AFF.top
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 вида
Отдельная ловушка — race condition при параллельных запросах. Если cap=3 и два запроса приходят почти одновременно, без atomic increment вы легко покажете 4-й раз. Решение: lock, compare-and-set или Redis INCR с корректным TTL и идемпотентным event_id.
Хороший cross-platform cap — это не настройка в UI, а маленькая система с ID graph, атомарным счётчиком и понятным окном. Если один из трёх слоёв плавает, frequency cap превращается в статистику, а не в правило.
Если 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 превращается в статистику, а не в правило.
Forwarded from AFF.TOP
This media is not supported in your browser
VIEW IN TELEGRAM
Google картинки станут конкурентом Pinterest
Google Картинки начали превращать в полноценную платформу с персональной лентой по прошлым запросам — по сути, в аналог Pinterest.
Во вкладке For you уже тестируют подборки, а ещё обещают коллекции и генерацию изображений во встроенной Nano Banana.
Как это будет работать и когда новинка дойдёт до других стран — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/google-kartinki-stanut-konkurentom-pinterest
🧠 Ещё больше инсайтов → в канале AFF.top
Google Картинки начали превращать в полноценную платформу с персональной лентой по прошлым запросам — по сути, в аналог Pinterest.
Во вкладке For you уже тестируют подборки, а ещё обещают коллекции и генерацию изображений во встроенной Nano Banana.
Как это будет работать и когда новинка дойдёт до других стран — в блоге.
➡️ Читайте на сайте: https://aff.top/blog/google-kartinki-stanut-konkurentom-pinterest
🧠 Ещё больше инсайтов → в канале AFF.top