Claude скоро станет по паспорту

С 8 июля 2026 года все модели Claude потребуют верификации личности через паспорт и селфи. Это произошло после закрытия доступа к Fable 5, выпущенной в открытый доступ буквально на неделю. Ограничение касается веб-версии на сайте Anthropic, но остаётся неясным, будут ли верификацию требовать API и AI-агенты вроде Codex. Решение выглядит излишне строгим в свете качества моделей, однако компания явно ужесточает контроль над доступом к своим продук…

➡️ Читайте на сайте: https://aff.top/blog/claude-skoro-stanet-po-pasportu

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

7 мест в programmatic-цепочке, где чаще всего теряются показы и деньги

Если воронка «инвентарь → bid request → bid response → win → render» ломается, проблема обычно не в одном месте, а в стыке слоёв.

— На стороне паблишера проверь, что в запрос уходит полный набор сигналов: placement, sizes, floor, seller.json, schain, privacy flags. Пустые или кривые поля режут матчинг и спрос.

— На стороне SSP смотри, не фильтруется ли трафик раньше времени: избыточные allowlist, слишком жёсткие floors, отключённые форматы, несовместимые deal-правила.

— В bidstream ищи несоответствия между тем, что отправил паблишер, и тем, что видит DSP: domain, bundle, device, geo, pagecat, contentcat. Любой mismatch снижает шанс на bid.

— В рендере проверяй, не теряется ли креатив из-за таймаута, VAST-ошибки, blocked scripts или неверного ad size. Иногда аукцион выигран, а показ не случился.

— В логах отдельно сравнивай no bid, timeout, loss и render fail. Это разные проблемы и чинятся по-разному.

Если разбирать цепочку по шагам, баг быстро превращается в конкретный слой интеграции. Не ищи «плохой спрос» первым делом — сначала найди, где именно ломается протокол.

Privacy Sandbox ломается не в API, а в интеграции: 5 мест, где чаще всего ошибаются

Privacy Sandbox — это не «одна кнопка вместо cookies», а набор отдельных механик: Topics, Protected Audience, Attribution Reporting, CHIPS. У каждой свой контракт, свои ограничения и свой путь данных.

— Сначала проверь, где у тебя живёт идентификация: в браузере, на стороне сервера, в first-party cookie или в одном из sandbox-API. Смешивать логику без схемы = получать разные результаты на разных страницах и доменах.

— Разделяй use case’ы. Аудитория, ретаргетинг, атрибуция и frequency capping решаются разными инструментами. Если пытаться закрыть всё одним API, интеграция быстро превращается в набор костылей.

— Закладывай деградацию. Браузерные ограничения, отсутствие поддержки и privacy-настройки пользователя должны вести к понятному fallback, а не к падению цепочки аукциона.

— Не отправляй лишние данные в запросах. В post-cookie архитектуре полезная привычка — минимизировать payload и держать маппинг событий на своей стороне, а не «для удобства» прокидывать всё подряд.

— Тестируй на уровне цепочки, а не одного эндпоинта: impression → click → conversion → отчёт. Частая ошибка — API отвечает, но атрибуция не сходится из-за несовпадения окон, ключей или источника события.

Если внедряешь Sandbox-механику, рисуй схему потока данных до первой строки кода. Это экономит больше времени, чем любой дебаг по логам.

Google выпустил Android 17

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

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

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

5 проверок перед тем, как отключать third-party cookies в DSP или SSP

Если в цепочке есть ретаргетинг, frequency capping, attribution или audience sync, third-party cookies нельзя убирать «одним флагом». Сначала проверьте, где именно они используются: в браузере пользователя, в пикселе, в sync-логике или в отчётности.

— Карта зависимостей. Для каждого модуля ответьте: cookie нужен для идентификации, дедупликации, атрибуции или антифрода? Если роль не названа, модуль обычно ломается первым.

— Поведение без cookie. Прогоните тестовый трафик в режиме, где cookie недоступны. Смотрите не только на reach, но и на расхождение в частоте, post-click/post-view и совпадение сегментов.

— Замены по назначению. Для частоты — server-side caps и first-party storage; для аудиторий — contextual, UID-решения или собственные ID; для атрибуции — модельные окна и логика на стороне сервера.

— Совместимость интеграций. Проверяйте SSP, DSP, adserver, measurement и clean room как одну цепочку. Ошибка часто сидит не в bidding, а в sync между системами.

— План деградации. Если cookie недоступны, система должна не падать, а переключаться в упрощённый режим: без персонализации, но с рабочим аукционом и отчётностью.

Главное правило: сначала описать, где cookie нужны, потом заменить их по функции. Иначе вы ломаете не трекинг, а всю механику показа.

5 проверок, которые спасают SSP/DSP-интеграцию от тихих потерь в bidstream

В programmatic самые дорогие ошибки — не падения, а «почти рабочие» интеграции. Запросы уходят, но часть сигналов теряется, а это бьёт по match rate, eCPM и fill.

— Сверяйте обязательные поля между SSP и DSP: imp, site/app, device, user, at, cur. Если поле опционально у вас, но критично у партнёра, вы теряете сделки без явной ошибки.
— Проверяйте ограничения креативов и форматов: размер, MIME, VAST-цепочки, secure-only, skippable/non-skippable. Часто bid приходит, но отваливается на этапе рендера.
— Не смешивайте логику де-дупа и frequency capping на разных уровнях без явного правила приоритета. Иначе DSP видит один набор показов, SSP — другой.
— Следите за dealid, seat и ext-полями: именно в расширениях обычно живут флаги, без которых приватный аукцион деградирует до open auction.
— Тестируйте пустые и граничные значения: пустой app.bundle, редкий content, нестандартный ua, несколько валют в цепочке. Протокол ломается не на «норме», а на краях.

Лучший чек — сравнить один и тот же bidstream глазами SSP и DSP: где поле исчезло, там и потеря денег.

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

Армения ввела жёсткие ограничения на онлайн-гемблинг: запретила депозиты для получателей соцпособий и пенсий, ограничила остальным суммы до 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

OpenRTB ломается не на bid request, а на несовпадении полей между SSP и DSP

OpenRTB сам по себе не «сложный» — сложными становятся ваши маппинги. Чаще всего интеграция падает не на auction logic, а на том, что одна сторона ждёт одно поле, а другая заполняет другое, или вообще считает его optional.

Проверьте базовый набор:
— imp, site/app, device, user, regs, source
— валидность id на уровне request, impression и seat
— корректность cur, at, tmax, test
— не дублируются ли идентификаторы в ext и стандартных полях

Отдельная зона риска — ext. Его часто используют как «свалку» для кастомных данных, но DSP может просто игнорировать нестандартные ключи. Если критичная логика живёт только в ext, вы сами делаете интеграцию хрупкой.

Ещё одна типовая ошибка — смешивать обязательные и условные поля. Например, для app-трафика нельзя полагаться на web-поля, а consent/regs нельзя передавать «по привычке» в любом формате без проверки типа трафика.

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

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

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

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

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

5 проверок programmatic-запуска, которые экономят больше бюджета, чем любой “оптимизатор”

Перед стартом кампании проверь цепочку целиком: SSP → exchange → DSP → ad server → трекер. Если где-то есть лишний редирект, кривой macro или несовпадение форматов, вы увидите не «плохой трафик», а потерю аукционов и искажение метрик.

— Сверь imp, bid, win, click: если в одном звене событие есть, а в другом нет, ломается атрибуция и оптимизация.
— Проверь обязательные поля OpenRTB: размер, placement, adomain, cat, secure. Пустые или конфликтующие значения часто режут bid response на стороне DSP.
— Отдельно тестируй все macros: {auction_price}, click URL, cache-buster, timestamp. Один неверный плейсхолдер превращает отчёт в шум.
— Сверь поддержку форматов: banner, native, video, audio. SSP может принять запрос, но отдать его только в части инвентаря.
— Убедись, что frequency capping и deduplication считаются в одном месте, а не одновременно на DSP и в трекере. Иначе частота «плавает» между системами.

Главное правило: сначала валидируй интеграцию, потом уже креатив и таргетинги. В programmatic ошибка в спецификации почти всегда дороже ошибки в ставке.

Как заработать 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

5 ошибок в programmatic, которые ломают инвентарь, таргетинг и атрибуцию

Programmatic редко “не работает” целиком — обычно ломается один слой цепочки: запрос, матчинг, биддинг или постбэк.

— Смешивают цели в одном seat/account: performance-кампании и upper-funnel начинают конкурировать за один и тот же трафик. В итоге DSP оптимизируется не под бизнес-метрику, а под локальный сигнал.

— Не проверяют, как передаются ID: device_id, ifa, ppid, user.id, cookie sync. Если идентификатор теряется на одном хопе, ретаргетинг и frequency capping становятся шумом.

— Игнорируют floor price и deal priority. Когда open auction и PMP живут без правил приоритета, часть спроса просто не видит нужный инвентарь или видит его слишком поздно.

— Кормят оптимизацию сырыми конверсиями без нормализации. Разные окна атрибуции, postback delay, дедупликация и разметка событий должны быть согласованы до запуска.

— Не логируют bid request / bid response / win notice. Без этого невозможно понять, где теряется спрос: на фильтрах SSP, в timeout, на bidder-side или в креативной валидации.

Если в цепочке есть хотя бы один “чёрный ящик”, сначала чинят наблюдаемость, потом — медиастратегию.

Как читать новости SSP/DSP, чтобы не перепутать PR с реальным апдейтом

Новости в programmatic почти всегда звучат одинаково: “улучшили matching”, “повысили качество трафика”, “усилили performance”. Для инженера это не сигнал, а повод раскопать, что именно изменилось в цепочке.

Смотри на 4 слоя:
— протокол: меняется ли OpenRTB, macros, bid request/response, support для новых атрибутов;
— интеграция: нужен ли новый endpoint, auth, schema mapping, deals, floor logic;
— логика аукциона: first-price/second-price, deal priority, timeout, filtering;
— измерение: как считаются impressions, clicks, viewability, IVT, attribution.

Если в тексте есть только “AI-powered optimization” и “better outcomes”, но нет объекта изменения — это обычно не продуктовая новость, а упаковка старой механики. И наоборот: одна строка про новый параметр в bid request может быть важнее длинного пресс-релиза.

Удобный фильтр для любой SSP/DSP новости:
— можно ли понять, ломает ли это текущую интеграцию;
— затрагивает ли это биддинг, таргетинг или биллинг;
— появляется ли новый обязательный field;
— меняется ли поведение по умолчанию.

Если ответов нет, новость пока не для команды интеграции. Если ответы есть — это уже задача для QA, логов и changelog'а.

Third-party cookies ломаются не в браузере, а в вашей схеме идентификации


Если у вас цепочка завязана на 3P cookie, проверьте не только трекинг, но и весь путь: user sync, frequency capping, retargeting, attribution.

• Идентификатор в браузере — это только один слой. Когда он исчезает, ломается не «показ», а связка между impression, click и conversion.
• Если у вас нет first-party ID или хотя бы устойчивого fallback-слоя, аудиторные сегменты начинают распадаться на разных SSP/DSP по-разному.
• На практике чаще всего проседают не bidding-алгоритмы, а инфраструктурные вещи: дедупликация, suppression-листы, postback-матчинг, аудитория в window-based логике.
• Отдельно проверьте, где именно живёт логика frequency capping: в браузере, на стороне DSP, в ad server или в вашем CDP.

Минимальный чек-лист:
— есть ли first-party идентификатор;
— умеет ли стек работать без cookie sync;
— есть ли server-side события;
— совпадает ли логика атрибуции в SSP, DSP и analytics;
— не завязан ли ретаргетинг на один источник идентификатора.

Если коротко: сначала картируйте, где у вас используется third-party cookie, потом заменяйте каждый слой по отдельности. Иначе вместо миграции получится набор нестыкующихся костылей.

7 мест в programmatic, где чаще всего ломается интеграция — и как их проверить

В programmatic ошибки почти всегда сидят не в bid logic, а в стыках: DSP ↔ SSP, ad server ↔ wrapper, SDK ↔ app, postback ↔ analytics. Если цепочка короткая, баг найти проще; если в ней 5 систем — ищите расхождение в идентификаторах, таймингах и фильтрах.

Первое, что проверяют: совпадает ли impression/click/callback path. Один лишний редирект, неверный macro или потерянный request id — и метрики расходятся между платформами.

Дальше смотрят на приоритеты таргетинга: частая ошибка — когда одно и то же поле интерпретируется по-разному на стороне buyer и seller. Например, placement type, device, geo или consent string проходят, но читаются не так, как ожидалось.

Третий слой — timeouts и throttling. Если bidder не успевает ответить в окно auction timeout, запрос формально живой, но в сделку не попадает. В логах это выглядит как «трафик есть, бидов нет».

Ещё один источник проблем — кэш и deduplication. Один и тот же user journey может считаться дважды, если не зафиксированы правила по refresh, retries и повторным postback.

Если интеграция «не сходится», идите по цепочке сверху вниз:
— запрос
— аукцион
— креатив
— показ
— постбек
— атрибуция

И на каждом шаге сравнивайте не только количество событий, но и одинаковые ли у них ключи. Это быстрее любого «покопаться в логах на глаз».

Как не сломать programmatic-кампанию: 7 проверок до запуска

Перед стартом проверь не креативы, а цепочку передачи данных: SSP → exchange → DSP → bidder → postback. Если где-то не совпадает формат поля, кампания может «крутиться», но часть событий будет теряться или уходить в fallback.

— В imp должны быть согласованы размер, формат и placement. Если DSP ждёт banner, а приходит video, часть инвентаря просто не сматчится.
— В site/app проверь домен, bundle/package и page/app-уровень. Ошибка здесь ломает валидацию и портит качество сигналов.
— В user не смешивай разные идентификаторы без логики приоритета. Иначе дедупликация и frequency capping начинают работать непредсказуемо.
— В device держи в порядке IP, UA, OS, geo и connection type. Для bidder это не «метаданные», а основа таргетинга и антифрода.
— В regs и gpp не отправляй пустые или противоречивые consent-сигналы. Это частая причина потери спроса на стороне DSP.
— В ext не складывай всё подряд: только то, что реально документировано и ожидается на другой стороне.
— После интеграции проверь логи на уровне request/response: timeout, no-bid, seat mismatch, corrupted macros.

Если кампания плохо стартует, сначала ищи не в аукционе, а в контракте между сущностями. В programmatic чаще ломается не bidding, а data flow.

OpenRTB-оффер: 5 полей, которые ломают аукцион чаще всего

OpenRTB-сабмит часто падает не из-за «плохого трафика», а из-за кривого запроса или ответа.

• Проверь обязательные поля в bid request: impression, site/app, device, user. Если один из блоков пустой — DSP может молча отбрасывать запрос.

• Не путай идентификаторы. id у request, imp.id и seatbid.bid.impid должны совпадать логически, иначе ставка не привяжется к показу.

• Валюта и price должны быть согласованы с ожиданиями стороны-получателя. Ошибка в округлении или единицах цены даёт неверный eCPM и отклонение.

• Для видео и rich media сверяй media type, mime types, placement и размеры креатива. Несовпадение часто выглядит как «нет бидов», хотя проблема в спецификации.

• Если передаёшь privacy-сигналы, не обнуляй их на одном из уровней. consent, regs, gpp и domain-level ограничения должны быть консистентны по всему пайплайну.

Перед интеграцией всегда прогоняй тестовый request/response через валидатор и смотри не только HTTP-код, но и причину отказа на уровне объекта. Это экономит часы дебага в SSP и DSP.

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

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

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

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

Google вернул full IP в AdSense bid request. Для B2B-таргетинга это меняет точность на уровне хоста

В AdSense появился новый control: publisher может разрешить передачу полного IP address в bid requests.
По умолчанию он выключен.

Это возвращает host-level precision для firmographic B2B targeting, а заодно для fraud detection и frequency capping.
Для SSP/DSP-цепочки это уже не «мелкая настройка»: если ваш OpenRTB-стек завязан на IP как сигнал, надо проверить, где он обрезается, кто его хранит и как это отражается в bidstream.

Если у вас есть AdSense-инвентарь или downstream-модели, завтра стоит перепроверить правила обработки IP в парсере и в логике матчей.
И отдельно — не сломает ли это ваши privacy-фильтры.

Ссылка: ppc.land — Google restores the IP octet that powers B2B account targeting in AdSense