Новую Google reCapcha прошли статичной картинкой

Google выпустил обновленную reCAPTCHA, требующую движений рук для прохождения, но система оказалась уязвима к обходу. Достаточно транслировать статичное изображение с нужным жестом через виртуальную камеру с помощью простого Python-скрипта, чтобы нейросеть пропустила пользователя. Это создает серьёзный риск для сайтов: защита от ботов, позиционировавшаяся как прорыв, на деле не работает. Баг остается актуальным и позволяет спамерам легко автомат…

➡️ Читайте на сайте: https://aff.top/blog/novuiu-google-recapcha-proshli-statichnoi-kartinkoi

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

DeepSeek представит последнюю версию v4

DeepSeek выпустит v4 в середине июля с новой моделью ценообразования API: токены подорожают в 2 раза в часы пиковой нагрузки (09:00–12:00 и 14:00–18:00 по пекинскому времени). Компания планирует уведомлять пользователей по почте за 24 часа до изменения тарифов. Проблема с ошибками «server busy» останется, но обойдётся дороже — это может существенно повлиять на экономику проектов, которые активно используют API DeepSeek для автоматизации и масшта…

➡️ Читайте на сайте: https://aff.top/blog/deepseek-predstavit-posledniuiu-versiiu-v4

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

Anthropic выпустили Sonnet 5

30 июня вышла Claude Sonnet 5 — новая версия позиционируется как самая агентная в линейке и приближается к флагманской Opus 4.8. Модель лучше справляется со сложными многоуровневыми задачами, устойчива к вредоносным запросам и не генерирует эксплойты. Sonnet 5 доступна на Free-тарифе, но тестирование показало скромные улучшения: хотя работает лучше Sonnet 4.6, её обгоняют конкуренты, включая китайские модели, которые дешевле через API при лучшей…

➡️ Читайте на сайте: https://aff.top/blog/anthropic-vypustili-sonnet-5

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

Почему пиксель больше не источник истины

Я всё чаще вижу одну и ту же ошибку: маркетинг продолжает считать пиксель «главным» источником данных, хотя в 2026 году он уже работает скорее как датчик с шумом, чем как измерительный прибор.

Мой практический вывод простой: если у вас есть только пиксель, вы не управляемо покупаете трафик — вы угадываете. Особенно в B2B и в длинных воронках, где между кликом и выручкой стоят CRM, прогрев, повторные касания и отдел продаж.

Что ломается на практике:

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

Поэтому я смотрю на связку, а не на один сигнал: пиксель + серверная аналитика + postback + CRM-статусы. Только в таком наборе можно понять, что реально создало выручку, а что просто оказалось последним касанием перед формой.

Один наблюдаемый эффект из практики: после перевода событий в server-side у одного B2B-проекта доля «потерянных» заявок в отчётах снизилась примерно на 18–22%. Не потому, что трафик внезапно стал лучше, а потому что система перестала недосчитывать часть пути пользователя.

Мой тезис жёсткий: в privacy-first реальности пиксель нужен не для веры, а для калибровки. Главный вопрос уже не «сколько конверсий показал рекламный кабинет», а «какой набор сигналов позволяет принимать решение о бюджете без самообмана».

— @AdOpsRoom

Параллельный взгляд на тему — @SMMreportingRu

Clickstar прекращает работу

Clickstar закрывается. Легендарная пуш-сеть прекращает закуп трафика с 1 августа, полная остановка — 20 августа.

Сетка работала почти 8 лет и была одним из лучших источников качественного трафика на Россию и СНГ. Сейчас пуш-трафик стал слишком ботовым из-за гугловских банов на скрипты сбора.

Что это означает для арбитражников — разбираемся в ста…

➡️ Читайте на сайте: https://aff.top/blog/clickstar-prekraschaet-rabotu

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

Переход на серверную аналитику в условиях деградации cookie-файлов: кейс ритейлера

В 2026 году полагаться на браузерные пиксели при оценке эффективности рекламных кампаний — стратегия с отрицательным математическим ожиданием. Эпоха, когда сторонние файлы cookie (third-party cookies) обеспечивали прозрачную атрибуцию, окончательно завершилась. Разберем кейс крупного e-com ритейлера, который столкнулся с 35% расхождением данных между рекламными кабинетами и внутренней системой управления выручкой.

Контекст: Ритейлер использовал классическую модель отслеживания событий через GTM (Google Tag Manager) на стороне клиента. Из-за внедрения блокировщиков рекламы и жестких правил безопасности в мобильных ОС, значительная часть событий (до 40% транзакций) терялась на этапе отправки данных в рекламные системы. Это приводило к тому, что алгоритмы оптимизации получали «грязные» данные и не могли эффективно обучиться на целевых действиях.

Задача: Обеспечить передачу данных о покупках с достоверностью не менее 95% и перейти от модели учета последнего клика (last-click) к серверной передаче событий (server-side tracking) для качественного обучения алгоритмов.

Решение: Инженерная команда развернула собственный контур обработки событий на базе API. Основные этапы:
— Настройка сервера-посредника (Cloud-based tagging server), который принимает данные напрямую с фронтенда.
— Обогащение событий внутренними идентификаторами пользователя (First-party ID), которые не подвержены блокировкам.
— Прямая интеграция с рекламными API (Conversion API) для отправки postback-сигналов о факте оплаты.
— Внедрение системы проверки качества данных, которая сверяет серверный лог с базой данных заказов в реальном времени.

Результат: За три месяца внедрения серверной аналитики удалось сократить разрыв в атрибуции с 35% до 7%. Стоимость привлечения целевого клиента (CAC) снизилась на 12% за счет того, что алгоритмы площадок начали получать полные данные для обучения. Коэффициент удержания (retention) вырос на 4%, так как система начала корректно учитывать повторные покупки в рамках LTV (пожизненной ценности клиента).

Урок: В условиях privacy-first (приоритета приватности) маркетинга, владение данными становится вопросом инфраструктурной устойчивости. Переход на серверную передачу событий — это не просто техническая оптимизация, а фундаментальный сдвиг в методологии учета.

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

— @AdOpsRoom

Facebook запретил рекламу онлайн-казино Mr Vegas

Британский ASA запретил рекламу казино Mr Vegas из-за «слишком милых» мультяшных животных в креативах — регулятор счёл, что такой стиль привлекает детей, в том числе через Facebook. Рекламодатель запустил кампанию в феврале, бан вышел в июле. Логика регулятора вызывает вопросы: дети неплатёжеспособны, а таргетировать их на гемблинг бессмысленно.

➡️ Читайте на сайте: https://aff.top/blog/facebook-zapretil-reklamu-onlain-kazino-mr-vegas

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

В Whatsapp скамят пользователей с помощью поддельных никнеймов

WhatsApp запустил никнеймы — и почти сразу начался скам. Мошенники регистрируют имена, похожие на бренды, звёзд и политиков, с минимальными опечатками.

Индия, где 500 млн пользователей WhatsApp, потребовала от Meta объяснений за 3 дня. Meta говорит, что точные совпадения заблокированы — но одна буква в другом месте защиту не триггерит.

Похоже, п…

➡️ Читайте на сайте: https://aff.top/blog/v-whatsapp-skamiat-polzovatelei-s-pomoschiu-poddelnykh-nikneimov

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

Вышел ZCode - аналог Claude code

Вышел ZCode — десктопный аналог Claude Code от разработчиков GLM-5.2. Работает с API от Anthropic, поддерживает SSH-деплой на сервер, в том числе Linux.

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

Но главная фича — мультиагентность…

➡️ Читайте на сайте: https://aff.top/blog/vyshel-zcode-analog-claude-code

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

Серверный postback стал первым, что чинят при падении качества трафика

За последний месяц в нескольких проектах повторяется один и тот же порядок диагностики. Когда расход и лиды расходятся, реже начинают с креативов или посадочной. Сначала смотрят серверный postback: доходят ли события до трекера, нет ли дублей, совпадает ли идентификатор клика между рекламной системой, CRM и аналитикой, не режется ли цепочка на редиректе, не ломается ли окно атрибуции.

Параллельно почти всегда всплывают одни и те же места:
— часть событий приходит с задержкой и попадает уже в другой день;
— офлайн-статусы из CRM не синхронизируются с серверной аналитикой;
— в одной воронке живут сразу два источника истины;
— last-click остается в отчёте, но решения уже принимают по серверным данным.

Отдельно заметно, что разговор про пиксель всё чаще начинается не с установки, а с проверки, что именно он ещё может увидеть в privacy-first (с приватностью по умолчанию) среде.

У вас сейчас так же: сначала постback, потом всё остальное?

— @AdOpsRoom

Соседняя редакция @InfluencerResearchRu недавно писала об этом под другим углом

Cloudeflare грозит Google блокировкой трафика

Cloudflare объявил: с 15 сентября 2026 года ИИ-краулеры будут заблокированы по умолчанию на всех сайтах с рекламой — включая Googlebot, Applebot и Bingbot.

Главная претензия — к Google: один и тот же бот индексирует страницы и собирает данные для обучения нейросетей, что даёт поисковику нечестное преимущество.

Но есть нюанс, который меняет всю к…

➡️ Читайте на сайте: https://aff.top/blog/cloudeflare-grozit-google-blokirovkoi-trafika

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

Гайд: как заработать первые деньги на Pornhub

Pornhub — самый посещаемый адалт-сайт в мире, и на нём действительно можно зарабатывать. Но схема устроена иначе, чем кажется.

Автор залил ролики, набрал 16 000 просмотров — и получил 47 центов встроенной монетизации. Реальные деньги были в другом.

Есть нюансы с верификацией, голосом в роликах и законодательством РФ, которые ломают большинство с…

➡️ Читайте на сайте: https://aff.top/blog/gaid-kak-zarabotat-pervye-dengi-na-pornhub

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

Postback, который не врёт: как настроить серверную валидацию и задержку для надежной атрибуции

Если у вас уже есть пиксель и постбек, проблема обычно не в “нет трафика”, а в “есть неконсистентность”: дубликаты, потери из‑за таймаутов, несовпадение параметров между браузером и сервером. На этой неделе сделайте серверную схему, где постбек отправляется только после валидации и с контролируемой задержкой.

1) Определите минимальный набор полей постбека
— user_key (ваш ключ, а не “random”)
— event_id (одноразовый идентификатор события)
— ts_event (время события в UTC)
— event_type (например, Lead/Payment/Signup)
— value + currency (если есть)
— campaign_id / ad_id / creative_id (только те, что реально используете в аналитике)
— ip / ua / consent_flag (только для проверки, не для “атрибуции по вкусу”)

2) Сделайте “шлюз” постбека на сервере
Ваша логика: входящие события → запись в таблицу событий → валидация → отправка во внешний трекер/рекламную систему.
Технически: endpoint, который принимает событие от пикселя/приложения, но **не отправляет наружу сразу**.

3) Реализуйте дедупликацию по event_id
— Завести уникальный индекс по (user_key, event_id).
— Если запись с таким event_id уже есть — прекращайте обработку.
Это убирает типичные дубликаты при ретраях, повторных загрузках страниц и сбоях сети.

4) Проверьте консистентность таймстампов и окна атрибуции
— Если ts_event отсутствует или сильно “в будущем”/“в прошлом” (например, больше 7 дней) — помечайте как suspect и не отправляйте в production-поток.
— Привяжите правила к вашему окну атрибуции (обычно 1–30 дней для B2B, но зависит от цикла MQL/SQL и RevOps-модели).

5) Подставьте недостающие параметры из server-side сессии
— Если campaign_id/ad_id пришли пустыми (часто при переходах из защищённых контекстов), подтяните их из server-side хранилища по user_key.
— Не “изобретайте” параметры: лучше отправить событие без campaign_id, чем подменить чужой контекст.

6) Добавьте управляемую задержку (delay) перед отправкой постбека
Практика: 2–10 минут буферизации.
Зачем: вы уменьшаете потери на race conditions (когда часть параметров доходит позже), и вы стабилизируете последовательность событий (например, Lead → Qualification).
Реализация: очередь задач (job queue) + повторная попытка отправки с backoff.

7) Сделайте retry с идемпотентностью
— При сетевых ошибках повторяйте запрос к рекламной платформе.
— Но отправку наружу блокируйте ключом event_id (на вашей стороне) и храните “status=sent” с ответом провайдера.

8) Включите мониторинг “коэффициента здоровья”
Сведите в один дашборд:
— received_count (сколько событий дошло на шлюз)
— dedup_count (сколько отсеяли дубликатов)
— sent_count (сколько отправили наружу)
— failure_count + причины (timeout/4xx/5xx/invalid payload)
Если sent_count падает относительно received_count — проблему видно сразу, а не через недельную “дыру” в отчетах.

9) Тест на стенде до продакшена
— Сгенерируйте 10–20 событий с разными event_id и одинаковым user_key.
— Убедитесь: дубликаты не уходят, порядок событий сохраняется, задержка работает, а retry не делает повторных постбеков.

Итог: вы получите postback, который становится частью pipeline серверной аналитики, а не “ещё одним скриптом на странице”. В 2026-м это особенно важно: privacy-first схема и incrementality требуют предсказуемости, иначе вы измеряете ошибки инфраструктуры, а не эффект кампаний.

— @AdOpsRoom

@ExperimentationRoom разбирают это с практической стороны

Пиксель больше не живёт один: как собирать серверную аналитику, когда браузерная часть деградирует

В 2026 году у маркетолога-инженера есть одна неудобная правда: привычный пиксель перестал быть надёжной единицей измерения. Он всё ещё нужен, но уже не как «главный источник истины», а как один из слоёв системы. Браузеры режут cookies, пользователи чаще блокируют трекинг, а модели атрибуции всё сильнее смещаются в сторону privacy-first-подхода — серверной передачи событий, MMM и оценки инкрементальности.

Отсюда важный вывод: вопрос больше не в том, «как поставить пиксель», а в том, **как построить контур данных, который переживёт потери на клиенте**.

Первый слой — браузерный пиксель как быстрый, но шумный сенсор

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

Пример: интернет-магазин видит 1000 добавлений в корзину по фронту, но в рекламном кабинете и CRM сходится только 780. Причина не всегда в «плохом трафике». Часть событий потерялась из-за блокировщиков, часть — из-за отказа от cookies, часть — из-за сбоев в тег-менеджере на отдельном шаблоне. Если смотреть только на браузерный пиксель, команда начнёт оптимизировать не реальность, а её фрагмент.

Поэтому пиксель надо держать как сенсор диагностики, а не как финальный бухгалтерский регистр.

Второй слой — серверная аналитика как источник устойчивых событий

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

Пример: B2B-сервис получает заявку через лендинг. Браузерный трекинг фиксирует форму, но не всегда дожидается страницы «спасибо»: пользователь закрывает вкладку, связь рвётся, скрипт не успевает отправить событие. Если же форма сначала попадает в backend, а потом уже сервер отправляет конверсию в рекламные системы и аналитику, событие становится надёжным. Вы перестаёте терять бизнес-уровень факта из-за UX-деталей.

Но серверная аналитика тоже не магия. Если на входе мусорные идентификаторы, дубли или кривые статусы заказов, то сервер просто быстрее размножит ошибку. Стабильность канала не заменяет качество схемы данных.

Третий слой — postback как договор между платформами

Postback — это не просто «отправить конверсию обратно». Это способ договориться, какое именно событие считается ценным, в каком статусе и с каким идентификатором оно вернётся в источник трафика. В performance-модели это критично: без postback вы оптимизируете кампании по приблизительным сигналам, а не по факту.

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

Здесь особенно важна дисциплина статусов. Одно дело — «заявка принята», другое — «лид в работе», третье — «выручка признана». Для RevOps-модели это уже не техническая деталь, а управленческая: маркетинг, продажи и customer success должны одинаково понимать, какое событие считается полезным.

Четвёртый слой — атрибуция как модель, а не как священный объект

В эпоху, когда last-click теряет доверие, соблазн прост: собрать серверную аналитику и считать, что проблема решена. Но это только улучшает качество данных, а не саму логику распределения вклада. Для сложных воронок нужны несколько контуров оценки: прямые конверсии, серверные события, MMM-модель, инкрементальные тесты.
…