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

OpenAI выпустила ChatGPT Images 2.5 — обновление стало вдвое быстрее, повысило детализацию, качество текстур и естественность освещения. Модель умеет точечно редактировать фрагменты изображения, работать с прозрачным фоном, превращать наброски в готовые картинки и учитывать комментарии к правкам. Это упрощает создание креативов для рекламы и контента без дополнительной обработки.

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

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

Один стикер в Telegram может выбить аккаунт

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

➡️ Читайте на сайте: https://aff.top/blog/odin-stiker-v-telegram-mozhet-vybit-akkaunt

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

Google ads запустил открытый бета-тест AI Dashbord

Google начал открывать AI Dashboards в Google Ads — отчётность на базе Gemini, где графики и диаграммы можно собирать промптами. Фича пока доступна не всем, но скоро должна прийти активным пользователям. Практической пользы для CPA и iGaming она почти не даёт, зато упрощает визуализацию данных и делает отчёты красивее.

➡️ Читайте на сайте: https://aff.top/blog/google-ads-zapustil-otkrytyi-beta-test-ai-dashbord

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

RevOps в BigQuery: как Aviasales связал маркетинг и выручку без last-click

В 2026 год “чистого” direct/last-click уже не хватает: атрибуция становится privacy-first (server-side, инкрементальность, MMM), а классическая связка лид → MQL → SQL заметно проседает в B2B-логике и частично в e-commerce. На этом фоне Aviasales, будучи продуктом с сильной долей performance-каналов и долгим циклом решения, столкнулся с типовой проблемой: маркетинг видел заявки/переходы, но бизнес хотел понимать вклад кампаний в выручку и удержание (повторные бронирования, допродажи, “второй шаг”).

Задача
— Перестать оптимизировать кампании “по клику” и начать оптимизацию по влиянию на выручку.
— Собрать единый слой данных в BigQuery, который свяжет: маркетинговые параметры (кампания/канал/креатив) → действия пользователя → бронь/платёж → последующие события.
— Дать RevOps-цепочке (маркетинг + продажи + customer success) общий язык цифр: какие гипотезы реально меняют выручку, а какие лишь перемещают конверсии между сегментами.

Решение
1) Единая модель событий в BigQuery
Aviasales построил таблицы событий в BigQuery с нормализацией полей: идентификатор пользователя/сессии, timestamp, источник (UTM/внутренний трекинг), параметры кампаний, действие на сайте/в приложении, и ключевые транзакционные события. Важный момент — разделили “сырые” логи и витрины:
— raw_* для неизменяемого источника
— mart_* для аналитики и расчётов

2) Server-side сбор и дедупликация
Чтобы не зависеть от потерь в браузерах и мобильных SDK, маркетинговые параметры стали приходить на сервер вместе с событиями. Дедупликация по event_id и контролями на временные окна уменьшила “размножение” конверсий. По внутренним проверкам это дало снижение расхождений между потоками трекинга на **до 30%** на уровне атрибутированных событий (в сравнении с прежней схемой на клиентских куках).

3) “Мост” к выручке: от клика к брони и повторным действиям
Бронь/платёж — отдельная сущность: Aviasales связал её с пользовательским путём через ключи и временные допуски (например, связывание по ближайшему релевантному действию в окне). Затем добавили модель жизненного цикла: первое бронирование → повтор → доп. сервисы, чтобы оценивать не только первичную конверсию, но и retention-эффект.

4) Инкрементальность и чистка канальных искажений
Вместо предположения “если конверсия выросла — канал принёс вклад” они стали мерить приращение (incrementality): A/B-кампании/holdout на уровне сегментов и контрольные группы, где возможно; остальное — оценка влияния через согласование с MMM (marketing mix modeling) для проверки здравого смысла по миксу. Это помогло уйти от переоценки last-click.

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

Урок
1) BigQuery — это не “место для отчётов”, а слой, где вы фиксируете определения: событие, конверсия, выручка, связка с пользователем.
2) Переход от last-click к оценке влияния требует дисциплины: server-side сбор, дедупликация, окна атрибуции и валидация.
3) RevOps в 2026 выигрывает у изолированных воронок: когда маркетинг видит путь к выручке и retention, решения по миксу становятся быстрее и доказуемее.

Если хотите, в следующем посте разберу конкретно: какую схему таблиц (raw/mart) удобно собирать под связку “кампания → бронь → LTV” и как проверять целостность данных в BigQuery на примерах SQL-проверок.

— @BigQuery4MarketingPro

Компания Meta представила Muse

Meta запустила Muse — ИИ-агента для рутинных действий вроде писем, брони, форм и покупок через Stripe. Для арбитража и CPA это скорее демонстрация тренда, чем рабочий инструмент: модель Muse Spark слабая, запуск только в США, а безопасность завязана на изолированную VM и контроль доступа к сервисам.

➡️ Читайте на сайте: https://aff.top/blog/kompaniia-meta-predstavila-muse

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

Вышел в публичный доступ DeepSeek-V4.1-Flash

➡️ Читайте на сайте: https://aff.top/blog/vyshel-v-publichnyi-dostup-deepseek-v4-1-flash

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

Facebook ads добавляет детальный таргетинг in-market categories

Facebook Ads тестирует In-market categories — новый детальный таргетинг на пользователей, которые прямо сейчас выбирают товар или услугу и ближе всего к покупке. Для арбитража это может дать более «горячую» аудиторию и потенциально лучший CR, особенно в e-commerce, нутре и других вертикалях. Пока функция доступна не всем, но её стоит тестировать сразу после масштабного релиза.

➡️ Читайте на сайте: https://aff.top/blog/facebook-ads-dobavliaet-detalnyi-targeting-in-market-categories

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

BigQuery для маркетинга: как посчитать инкрементальность прироста выручки без «последнего клика»

В 2026 маркетинг всё чаще отвечает за выручку вместе с RevOps (общая ответственность маркетинга, продаж и customer success за результат). Но в отчетах по прежнему живёт last-click: он объясняет прошлое, а не доказывает влияние. Поэтому многие команды переходят к privacy-first подходам: server-side события, воспроизводимые витрины и измерение прироста через incrementality (оценка дополнительного эффекта).

Бренд/компания
Диджитал-маркетинг-отдел B2B-сервиса с циклом сделки 30–90 дней (контент + performance на лиды). До изменения измеряли конверсии по последнему касанию и часто переоценивали платный трафик.

Задача
1) Понять, какие кампании реально дают прирост выручки, а какие лишь «забирают» клиентов, которые и так бы дошли до сделки.
2) Собрать данные так, чтобы атрибуцию и вычисления можно было воспроизвести в BigQuery, без ручных выгрузок и «разных версий истины».
3) Синхронизировать маркетинговые события с CRM (лиды → MQL → SQL → win) и закрывающими данными.

Решение
— В BigQuery построили витрины уровня “путь клиента”: пользователь/lead идентификатор → набор касаний (кампания, формат, канал, время) → статусы в CRM с датами.
— Для privacy-first интеграций использовали server-side события: UTM/идентификатор кампании передавали так, чтобы минимизировать потери данных в браузере.
— Вместо last-click применили дизайн измерения “test/control” на уровне групп:
— для части трафика ограничивали показ (или уменьшали бюджет) по заданным правилам на сопоставимых сегментах;
— затем сравнивали итоговую метрику по группам с поправкой на разницу в составе лидов (минимум — стратификация по источнику и отрасли/размеру компании, максимум — регрессии или пропенсити-скоринг, если достаточно данных).
— Итоговую инкрементальность считали на уровне pipeline metric:
— инкрементальные SQL и win (суммарные и по сегментам),
— затем переводили в выручку через средний revenue по сегментам (без обещаний “точной” формулы, только на данных исторической базы).

Конкретный результат
Чтобы не привязываться к «абсолютным» цифрам, которые зависят от модели выручки, команда закрепила эффект в терминах прироста: **после корректного сравнения test/control платные кампании перестали выглядеть “всемогущими” по last-click** и стало видно, что часть бюджета распределяли на сегменты с близким к нулю инкрементом. По практическому KPI это позволило:
— перераспределить бюджет на кампании с устойчивым приростом MQL→SQL;
— сократить долю spend, который чаще “тащит” уже готовые лиды, а не добавляет новых;
— унифицировать отчётность: один расчет в BigQuery для команды маркетинга и RevOps.

Урок для читателя
1) Если вы всё ещё строите решение на last-click, вы меряете атрибуцию, а не влияние. В 2026 лучше считать **инкрементальность** и/или эффект на pipeline-этапах.
2) BigQuery нужен не только для графиков, а для воспроизводимых вычислений: витрины касаний + CRM-статусы + единый календарь событий.
3) Начинайте с простой схемы test/control и стратификации: даже базовая проверка даст сигнал, какие кампании реально “добавляют”, а какие — “перекрашивают” путь.

Если хотите, опишу шаблон схемы витрин (таблицы касаний, CRM-статусов, справочник кампаний) и пример SQL-структуры под инкрементальность для вашего типа бизнеса (B2B с MQL/SQL или e-com с retention/LTV).

— @BigQuery4MarketingPro

Как BigQuery собрал разрозненные данные в одну картину и помог команде быстрее принимать решения

Один из типичных кейсов для маркетинга в 2026 году — когда данные есть, а ясности нет. Так было и у компании из B2B-сегмента: реклама шла в нескольких каналах, лиды считались в CRM, поведение на сайте жило отдельно, а отчёты в итоге расходились между маркетингом и продажами.

**Задача** была простая на словах и сложная на практике: понять, какие каналы реально двигают выручку, а какие просто дают шум. На уровне MQL/SQL это уже работает хуже, чем раньше: в B2B всё чаще нужна связка маркетинга, продаж и customer success в одну логику — через RevOps.

**Решение** построили на BigQuery как на едином слое данных. В него стали сводить:
— рекламные расходы и кампании;
— веб-аналитику;
— CRM-статусы;
— данные по сделкам и повторным касаниям.

После этого команда настроила регулярные запросы и отчёты, где считались не только заявки, но и путь до сделки. Отдельно смотрели:
— конверсию по этапам;
— стоимость лида и стоимость сделки;
— долю каналов, которые дают первый контакт и которые дожимают до выручки.

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

**Урок для маркетолога:** если у вас несколько источников данных, не пытайтесь собирать правду вручную в Excel. В 2026 году выигрывает не тот, у кого больше отчётов, а тот, у кого есть единая модель данных и понятная связь между расходами, касаниями и выручкой. BigQuery здесь — не просто хранилище, а рабочий слой для управленческого маркетинга.

— @BigQuery4MarketingPro

По этой же теме советуем @MarTechStackRuPro

MoneyGram запустила карту Visa

MoneyGram и Visa запустили виртуальную карту на стейблкоине MGUSD: пока она работает только в Колумбии и привязывается к Apple/Google Wallet, но в планах — новые GEO и физические карты. Для арбитража это сигнал, что стейблкоин-платежи могут стать удобным способом оплаты и, возможно, источником новых платежных решений под CPA и iGaming.

➡️ Читайте на сайте: https://aff.top/blog/moneygram-zapustila-kartu-visa

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

Apple выпустила документацию для приложений на Iphone Duo

Выход складного iPhone Duo потребует от разработчиков адаптации интерфейсов под новые пропорции экрана и версии iOS. Арбитражникам, использующим классические web-приложения под гемблу, придется срочно переделывать софт под три новых режима совместимости Apple, в то время как владельцы PWA-связок смогут продолжить работу без дополнительных технических правок.

➡️ Читайте на сайте: https://aff.top/blog/apple-vypustila-dokumentaciiu-dlia-prilozhenii-na-iphone-duo

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

Топ-5 прокси сервисов для УБТ

Статья разбирает выбор прокси для автоматизации УБТ: от массового фарма соцсетей до парсинга. Универсального провайдера нет: для рутинных скриптов подходят дешевые серверные IPv4, для долгого прогрева аккаунтов — трастовые мобильные IP с безлимитным трафиком, а для редких гео — резидентские пулы. Главный вывод: прокси — критически важный расходник, экономия на котором ломает работу связок и многопоточного софта.

➡️ Читайте на сайте: https://aff.top/blog/top-5-proksi-servisov-dlia-ubt

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

Anthropic обвинила DeepSeek, Moonlight и Alibaba в дистиляции

Статья о том, как китайские компании массово выкачивают ответы западных нейросеток, чтобы дообучать свои модели. Anthropic говорит о 24 000 фейковых аккаунтов и 16 млн запросов к Claude. Вывод простой: рынок ИИ входит в фазу жёсткого копирования, а китайские модели Qwen, Kimi и DeepSeek могут быстро догонять лидеров дешевле.

➡️ Читайте на сайте: https://aff.top/blog/anthropic-obvinila-deepseek-moonlight-i-alibaba-v-distiliacii

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

Как BigQuery помог убрать «слепые зоны» между рекламой и выручкой

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

Один из типичных кейсов для BigQuery — объединить данные из рекламы, CRM и сайта в одной модели и перестать смотреть на каналы отдельно.

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

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

Что это дало:
— маркетинг перестал спорить «по ощущениям» и начал опираться на одну таблицу правды;
— стало видно, какие кампании дают не просто заявки, а деньги;
— удалось быстрее отключать слабые связки и усиливать каналы с высоким вкладом в выручку.

**Главный урок**: BigQuery в маркетинге ценен не как «ещё один склад данных», а как место, где маркетинг, продажи и аналитика начинают говорить на одном языке. В эпоху privacy-first атрибуции и слабого last-click это уже не удобство, а базовая гигиена управления бюджетом.

Если у вас B2B, e-com или performance вне казино, вопрос почти всегда один: не «сколько кликов мы купили», а «какую выручку они принесли и с какой задержкой». Именно на это BigQuery отвечает лучше всего.

— @BigQuery4MarketingPro

Визуализация архитектуры тегов в Google Tag Manager через BigQuery

В эпоху privacy-first (приоритета конфиденциальности) и усложнения серверной аналитики важно держать в порядке структуру сбора данных. Чтобы не утонуть в хаосе тегов и триггеров, используйте BigQuery для аудита и визуализации вашего контейнера Google Tag Manager (GTM). Это позволит видеть связи между объектами системы без ручного перебора настроек.

Вот пошаговый алгоритм действий:

— Экспортируйте конфигурацию контейнера GTM в формате JSON через официальный API или интерфейс управления версиями.
— Загрузите полученный файл в BigQuery, используя встроенный загрузчик или процедуру преобразования JSON-структур в плоские таблицы.
— Разверните SQL-запрос для парсинга вложенных полей, чтобы выделить сущности «Тег», «Триггер» и «Переменная» в отдельные строки.
— Создайте связи между объектами (например, какие переменные используются в каких тегах), выстроив граф зависимостей.
— Визуализируйте полученный граф в BI-системе (Business Intelligence — инструментах бизнес-аналитики) или библиотеках для построения диаграмм, чтобы наглядно увидеть избыточные или «забытые» теги.
— Документируйте итоговую схему потоков данных, чтобы обеспечить прозрачность сбора для отдела разработки и безопасности.

Это пригодится для проведения регулярного технического аудита и подготовки инфраструктуры к переходу на серверный сбор данных (server-side tagging).

— @BigQuery4Marketing

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