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, а не как спор между вендорами.

Россияне не смогут покупать стейблкоины

Россиянам могут закрыть доступ к покупке стейблкоинов: в новой версии закона их приравняли к иностранным активам.

Купить такие токены смогут только квалифицированные инвесторы — например, с активами от 24 млн рублей или доходом от 12 млн в год.

Что это значит для обычных пользователей и когда правило заработает — в блоге.

➡️ Читайте на сайте: https://aff.top/blog/rossiiane-ne-smogut-pokupat-steiblkoiny

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

IVT ломают не креатив, а цепочку сигналов — вот как их раскладывать по категориям

В антифроде важно не смешивать общий «подозрительный трафик» с конкретной причиной. Базовая ось: GIVT и SIVT. Первый слой — техничка и явный мусор, второй — поведенческие и скрытые паттерны, которые уже надо собирать по сигналам из bid stream, SDK и post-bid логов.

Для GIVT обычно смотрят на:
— datacenter / known proxy / ASN-аномалии
— non-human user agents и пустые referrer chain
— слишком частые запросы с одного IP, одинаковые session_id, обрывочные auction_id
— mismatched geo / device / OS combinations

SIVT детектится сложнее: аномальная частота кликов и impressions, слишком ровный dwell time, повторяемые path patterns, несоответствие viewability и CTR, а также синхронные всплески по множеству placement_id. Тут полезны графы связей: IP ↔ device_id ↔ placement ↔ campaign.

На практике антифрод-сигнал надо строить слоями: pre-bid фильтрует очевидный мусор, post-bid подтверждает паттерн, а reconciliation между SSP, MMP и ad server ловит расхождения. Если у вас нет единого ключа для склейки, часть IVT всегда будет выглядеть как «плохой трафик», а не как конкретный источник.

Чем раньше вы разделите GIVT, SIVT и аномалии атрибуции, тем меньше денег уйдёт в ложный performance.