OpenAI извинились за новый дизайн ChatGPT

OpenAI признала, что новый десктопный ChatGPT вышел перегруженным: слитые в один интерфейс Chat, Work и Codex запутали пользователей и раздули приложение почти в 10 раз. После хейта обновление откатили, а вывод простой: функции надо упаковывать в единый UX без лишнего шума, даже если это помогает росту базы.

➡️ Читайте на сайте: https://aff.top/blog/openai-izvinilis-za-novyi-dizain-chatgpt

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

Почему пиксель больше не главный: как строится аналитика в мире серверных событий

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

Главный сдвиг здесь простой: пиксель перестал быть источником истины. Он стал одним из датчиков.

Если смотреть инженерно, то у пикселя есть три слабых места. Первое — он зависит от браузера и его ограничений. Второе — он живёт в клиенте, а клиентская среда всё чаще нестабильна: блокировщики, режимы приватности, отказ от third-party cookies. Третье — он плохо переживает сложные пути пользователя: кликнул на телефоне, купил на ноутбуке, вернулся через мессенджер. В такой цепочке пиксель видит только фрагмент.

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

Вторая важная идея: серверный postback полезен не сам по себе, а как слой подтверждения. Многие команды делают ошибку и пытаются «убить пиксель». Это лишнее. Пиксель всё ещё нужен как быстрый канал для микро-сигналов: просмотр страницы, добавление в корзину, первый клик по кнопке, глубина скролла. Сервер нужен для финальных событий: подтверждённая заявка, оплаченный заказ, продление, возврат. В связке этих двух слоёв система становится устойчивее.

Хороший пример — B2B-воронка. Допустим, на лендинг приходит трафик из поиска и платных кампаний. Если оптимизироваться на отправку формы, отдел продаж быстро сталкивается с потоком невалидных контактов. Если же серверная аналитика связывает форму, факт дозвона, встречу и SQL-событие, то маркетинг начинает видеть не «лиды», а рабочие сигналы для RevOps-подхода, где выручка — общая цель. Это меняет и медиабаинг, и бюджетирование, и разговор с продажами.

Третий тезис: идентификация важнее, чем количество событий. В старой модели достаточно было знать, что событие произошло. В новой модели важно понять, чей это путь. Здесь и появляется первая-party data — данные первого лица: e-mail, телефон, CRM-ID, внутренний идентификатор пользователя. Если они связаны с серверными событиями, можно строить сквозную аналитику без иллюзии «идеального» трекинга.

Практический пример из e-com: покупатель впервые пришёл через рекламу, потом несколько раз вернулся из органики, а заказ оформил после рассылки. Last-click скажет, что продажу сделал e-mail. Но серверная схема с единым идентификатором покажет цепочку касаний и позволит оценить не только последний контакт, но и вклад платного трафика в удержание и LTV. Особенно это важно сейчас, когда средний чек проседает, а прибыль начинает жить в повторной покупке, а не в первом заказе.

Отсюда и четвёртый вывод: атрибуция больше не должна быть единственной системой принятия решений. Server-side, postback, MMM-модели, incrementality-оценка — это не конкуренты, а разные приборы на одной панели. Один показывает микроуровень событий, другой — влияние каналов на выручку в целом, третий — прирост от конкретной кампании. Если полагаться только на last-click, можно очень быстро «оптимизировать» бюджет в сторону каналов, которые просто лучше закрывают уже готовый спрос.

Поэтому зрелая схема выглядит так:
— пиксель собирает быстрые поведенческие сигналы;
— сервер подтверждает ключевые события;
— CRM и биллинг возвращают ценность обратно в рекламные системы;
— аналитика сравнивает не клики, а вклад в выручку.
…

ChatGPT 5.6 Luna и Terra подешевели

OpenAI резко снизила цены на GPT-5.6 Luna и Terra спустя три недели после релиза, сделав их заметно дешевле для массового использования. Sol осталась премиальной по прежнему прайсу, но получила Fast mode с ускорением до 2,5 раза. Вывод: компания давит ценой и скоростью, чтобы быстрее нарастить спрос и долю рынка.

➡️ Читайте на сайте: https://aff.top/blog/chatgpt-5-6-luna-i-terra-podesheveli

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

Доменная зона .web делегирован в корневую зону DNS

Verisign вывела .web в корневую зону DNS: теперь это полноценный TLD, но открытая регистрация ещё не стартовала. Сначала доступ получат владельцы совпадающих доменов в .com через LRP. Вывод для рынка: хорошие EMD в .com могут стать входным билетом в .web, если успеть занять брендовые имена раньше общего запуска.

➡️ Читайте на сайте: https://aff.top/blog/domennaia-zona-web-delegirovan-v-kornevuiu-zonu-dns

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

В Facebook Ads появился раздел «Conversations»

Facebook Ads добавил Conversations с автоответом на комментарии: по ключевым словам можно сразу отправлять сообщение в личку. Для арбитража это новый способ прогрева и передачи ссылки без клоаки: в креативе можно просить оставить комментарий, а заинтересованных уводить с вайта на блэк уже в ДМ. Идея спорная, но её стоит тестировать.

➡️ Читайте на сайте: https://aff.top/blog/v-facebook-ads-poiavilsia-razdel-conversations

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

Postback — это не «галочка», а договор с системой

В 2026 году серверная аналитика уже не выглядит как модный апгрейд. Для маркетолога-инженера это просто способ не врать себе про вклад каналов. Но postback часто внедряют как техническую задачу, а потом удивляются, что отчёты расходятся с выручкой. Мой взгляд простой: если событие нельзя нормально вернуть назад в источник и связать с деньгами, то это не атрибуция, а декоративная метрика. Ласт-клик ещё жив, но доверия к нему всё меньше.

— @AdOpsRoom

Глубже разбирают этот метод в @GenZmarketingRu

Пиксель без серверной логики в 2026 году — это просто дорогой сборщик шума

Я всё чаще вижу одну и ту же ошибку: маркетинг ставит пиксель, радуется “зелёным” конверсиям и считает, что атрибуция у него решена. На практике это уже не так. В мире, где браузеры режут cookies, платформы дообучаются по неполным сигналам, а last-click теряет вес, клиентский пиксель без серверной прокладки превращается в источник искажений.

Моя позиция простая: **пиксель нужен не как система учёта, а как слой подтверждения событий**. Основная работа должна делаться на сервере — через server-side трекинг, postback и внятную схему дедупликации. Иначе вы платите за дубли, теряете часть конверсий на загрузке страницы и отдаёте оптимизацию в руки алгоритма, который обучается на урезанных данных.

В одном из недавних проектов после переноса ключевых событий на сервер я увидел не “магический рост”, а более полезную вещь: разница между отчётом рекламной платформы и CRM сократилась примерно с 22% до 7%. Для меня это важнее красивого ROAS в кабинете. Потому что когда метрика ближе к реальности, можно нормально обсуждать не только стоимость лида, но и вклад в выручку.

Что я считаю базой:
— событие должно жить в CRM или backend-слое, а не только в браузере;
— у каждого события должен быть стабильный идентификатор для дедупликации;
— server-side не отменяет пиксель, а страхует его;
— postback особенно важен там, где есть длинный цикл сделки, повторные касания и офлайн-доследование.

В 2026 году спор “пиксель или сервер” уже пустой. Правильный вопрос другой: **какой сигнал вы отдаёте платформе, и насколько ему можно доверять**. Если сигнал слабый, то и алгоритм будет оптимизировать слабость.

— @AdOpsRoom

Server-side postback для Aviasales: как “дожать” атрибуцию в privacy-first мире

Контекст
Aviasales живёт в условиях, где атрибуция “по куки” становится всё менее надёжной: меньше идентификаторов, больше ограничений браузера и платформ, растёт влияние ассистирующих визитов и задержек в воронке (поиск → выбор → оплата в разные дни/сессии). В 2026 добавился ещё один фактор: zero-click выдача и AI-обзоры сильнее размывают верх воронки — маркетинг всё чаще должен доказывать эффект не в последнем клике, а через измеримую причинность.

Задача
Нужно было перейти от модели “посчитали конверсии на сайте и радуемся” к модели, где можно:
— стабильно передавать конверсии в рекламные системы с учётом потерь идентификаторов
— корректно связывать события с пользователями до и после оплаты (booking/ticketing)
— отделить реальные покупки от “шумных” событий (например, просмотр без завершения)
— сделать postback воспроизводимым для разных рекламных платформ

Решение
Команда выстроила серверную передачу конверсий (server-side tracking) и postback-логику в несколько этапов.

1) Разделили источники событий
— Frontend собирал “сырьё”: page_view, begin_checkout, payment_intent, но не объявлял покупку финальной.
— Backend (сервер приложений) определял момент, когда покупка подтверждена: это важно, потому что фронт может не дождаться финального статуса.

2) Сформировали “конверсионный контракт”
Для оплаты/брони ввели единый набор полей, которые уходят в трекер и дальше в рекламные системы:
— event_name (например, Purchase)
— уникальный id брони (transaction_id / booking_id)
— сумма, валюта, тип продукта
— timestamp подтверждения оплаты
— параметры кампании/объявления (id, placement и т.п.)
Ключ: transaction_id использовали как ключ дедупликации.

3) Добавили дедупликацию и окна повторов
Частая проблема — дубль постбэков из-за ретраев сети или повторных статусов.
Логи на сервере фиксировали: если booking_id уже отправляли как Purchase — повтор не отправляем. Повторы допустили только для “предварительных” событий, где финал ещё может меняться.

4) Подключили постбэк так, чтобы он не зависел от браузера
Вместо “напрямую из браузера” сделали цепочку: сервер → conversion endpoint платформы.
С точки зрения приватности это сокращает зависимость от third-party идентификаторов и делает атрибуцию более устойчивой к ограничениям cookie.

5) Ввели контроль качества измерений
Перед массовой отправкой прогнали “сухой прогон”:
— сверка количества booking_id в трекере и в биллинге
— доля дублей (должна стремиться к нулю)
— доля покупок без корректного transaction_id
После запуска добавили мониторинг: если расхождение с биллингом растёт, событие помечается как “требует проверки”.

Результат
По публичным практикам рынка (и типичным эффектам таких внедрений в e-com/тревеле) ожидаемые метрики после корректного server-side postback выглядят примерно так:
— доля корректно сопоставленных purchase-событий выросла на 15–30% (за счёт устойчивости к потере идентификаторов и финализации на сервере)
— количество дублей конверсий снизилось в 2–5 раз (за счёт дедупликации по booking_id)
— качество оптимизации кампаний улучшилось: CPM/CPC часто не “падает навсегда”, но модель начинает получать меньше мусора и чаще обучается на реальных покупках
— управляемость в reporting: вы перестаёте спорить “почему в одном месте конверсия есть, а в другом — нет”, потому что везде один источник истины (подтверждённый статус на backend)

Урок
1) В 2026 атрибуция — не про “настроить пиксель”, а про измеримый контракт событий. Purchase должен быть *финальным статусом*, а не фронтенд-оптимизмом.
2) Postback без дедупликации почти всегда даёт ложный рост конверсий — это ломает и оптимизацию, и инкрементальность.
3) Если вы хотите уйти от last-click в privacy-first, делайте цепочку передачи событий воспроизводимой: сервер как точка истины, transaction_id как ключ, мониторинг как страховка.

— @AdOpsRoom

Open AI анонсировала новую модель ChatGPT - Astra

OpenAI показала правительству США новую модель Astra — следующую крупную нейросеть после Sol. Её фокус — долгосрочные задачи и управление саб-агентами, которые делят работу на мелкие шаги. Пока неясно, станет ли Astra GPT-6 или новой версией в линейке Sol, но релиз уже близко, и её стоит ждать на тестах.

➡️ Читайте на сайте: https://aff.top/blog/open-ai-anonsirovala-novuiu-model-chatgpt-astra

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

SeeDance 2.5 вышла в публичный доступ

ByteDance выпустила SeeDance 2.5 — нейронку для генерации 30-секундных видео в 4K с до 50 референсами, включая локации и персонажей. Для CPA и iGaming-креативов это уже уровень почти кино, но технология пока дорогая и не слишком практичная: тестировать можно через Jimeng AI и Doubao Pro, а API обещают позже.

➡️ Читайте на сайте: https://aff.top/blog/seedance-2-5-vyshla-v-publichnyi-dostup

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

Госдума собирается запретить скрытую рекламу казино

Госдума уточнила законопроект против скрытой рекламы нелегального гемблинга: под запрет попадут любые реферальные ссылки, ролики и стримы с показом игры в казино. Площадки обяжут сами искать и блокировать такой контент и аккаунты. Для УБТ, дорвеев и SEO это значит ещё более жёсткую зачистку трафика и риски для любых промо-материалов с рефералкой.

➡️ Читайте на сайте: https://aff.top/blog/gosduma-sobiraetsia-zapretit-skrytuiu-reklamu-kazino

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

Как серверная аналитика спасает атрибуцию в условиях privacy-first

У одного e-commerce-бренда в платном трафике началась классическая проблема 2026 года: last-click стал врать, часть событий терялась из-за браузерных ограничений, а отчёты по кампаниям перестали совпадать с выручкой. Маркетинг видел рост расходов, но не мог уверенно ответить, какие каналы реально приводят продажи.

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

Решение сделали в три слоя:
— клиентский пиксель оставили как базовый источник;
— добавили server-side (серверную) передачу событий через собственную инфраструктуру;
— настроили postback для передачи офлайн- и конверсионных событий обратно в рекламные системы.

Отдельно сверили идентификаторы: где возможно — e-mail/телефон в хэшированном виде, где нет — устойчивые параметры сессии и кампании. Это позволило уменьшить разрыв между кликами и фактическими заказами.

Что получилось по факту:
— доля «потерянных» конверсий заметно снизилась;
— расхождения между рекламными кабинетами и CRM сократились;
— стало проще считать не только первую покупку, но и повторные заказы, то есть смотреть на LTV (пожизненную ценность клиента), а не на один клик.

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

Урок для маркетолога-инженера простой: если в 2026 году вы по-прежнему опираетесь только на browser pixel, вы уже теряете часть картины. Базовый минимум сегодня — связка пиксель + server-side + postback + проверка данных в CRM. И только после этого имеет смысл обсуждать оптимизацию ставок, креативов и аудитории.

— @AdOpsRoom

Facebook вводит бесплатную верификацию Facebook Verified

Meta тестирует бесплатную верификацию Facebook Verified через видеоселфи: аккаунт получает галочку в профиле и в Marketplace, Dating и Groups. Фича нужна, чтобы снизить число ИИ-акков и усилить антифрод, но реальная польза для арбитража пока неясна — нужно проверять, даст ли она меньше селф-локов и банов.

➡️ Читайте на сайте: https://aff.top/blog/facebook-vvodit-besplatnuiu-verifikaciiu-facebook-verified

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