Meta выпустила ИИ-агент Muse Code

Meta выпустила Muse Code — прямого конкурента Claude Code с упором на управление несколькими ИИ-агентами в параллели для долгих задач. Главный вывод: компания агрессивно демпингует ценой, предлагая базовый тариф и сверхдешёвый вариант в обмен на доступ к личным данным.

➡️ Читайте на сайте: https://aff.top/blog/meta-vypustila-ii-agent-muse-code

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

РОЗЫГРЫШ НОУТБУКА НА ВЫХОДНЫЕ 💻

Подпишись на три канала:
• Иванов - @pacan
• Кустов - @cobaka
• Миша - @CPA_Farm

И один случайный подписчик заберёт великолепный ноутбук. Отличная рабочая лошадка для работы, учёбы и интернет-сёрфинга, остальное не потянет!

Важно: боты сразу мимо, аккаунты не из нашей сферы тоже, все участники будут проверены, в том числе на пересечение с профильными affiliate/iGaming чатами.

Итоги сразу после выходных.

Три подписки. Один ноутбук. Как сказал GPT - иногда интернет всё-таки использует случайный выбор не только для того, чтобы подсунуть очередную рекламу криптокурсов.

Участников: 80
Призовых мест: 1
Дата розыгрыша: 15:14, 09.08.2026 MSK (3 дня)

Google по ошибке удалил тысячи сайтов

Google массово банил сайты на Blogger из-за сбоя в автоматической модерации: система ошибочно нашла malware в контенте и снесла тысячи сайтов, часть — повторно после восстановления. Для вебмастеров вывод простой: даже трастовая платформа не защищает от ложных срабатываний, а автоматический антифрод может положить и вайт, и ферму.

➡️ Читайте на сайте: https://aff.top/blog/google-po-oshibke-udalil-tysiachi-saitov

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

Почему я перестал доверять last-click в отчётах по маркетингу

В 2026 году спор о том, «какой канал принёс продажу», всё чаще выглядит устаревшим. Я вижу это в проектах по B2B и e-commerce: last-click продолжает рисовать красивую картинку, но всё хуже объясняет, почему выручка растёт или падает.

Моя позиция простая: **если вы всё ещё строите управленческие решения только на последнем клике, вы оптимизируете не маркетинг, а удобство отчёта**.

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

В BigQuery это особенно заметно. Когда я собираю цепочки касаний по пользователям, почти всегда вижу один и тот же эффект: канал, который закрывает сделку, редко создаёт спрос. А канал, который создаёт спрос, часто получает ноль в last-click.

Из практики: в одном B2B-проекте после склейки событий из сайта, CRM и рекламных кабинетов оказалось, что у 38% сделок первый осмысленный контакт был не с performance-кампании, а с контентом и бренд-касанием. В last-click это выглядело как «победил поиск». В реальности поиск просто забрал уже подготовленный спрос.

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

**Last-click полезен как операционный индикатор. Но как основа стратегии он слишком узок.** В эпоху privacy-first атрибуции, MMM и incrementality нам нужен не красивый итоговый канал, а модель движения к выручке.

— @BigQuery4MarketingPro

OpenAI сделала ChatGPT-5.6 Luna бесплатной

OpenAI делает ставку на доступность: ChatGPT-5.6 Luna стала бесплатной на сайте, а в Sol добавили ползунок глубины рассуждений для ускорения ответов. Для сложных запросов готовят кнопку Think. Пока это веб-эксклюзив, но вывод очевиден: OpenAI усиливает продукт и давит на конкурентов бесплатным доступом.

➡️ Читайте на сайте: https://aff.top/blog/openai-sdelala-chatgpt-5-6-luna-besplatnoi

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

Metamask представил свою криптокошелёк для ИИ

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

➡️ Читайте на сайте: https://aff.top/blog/metamask-predstavil-svoiu-kriptokoshelek-dlia-ii

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

А/В тест в BigQuery для маркетинга: как считать инкрементальность без «маркетинговой математики»

Если вы уже не уверены, что last-click (последнее касание) отражает реальный эффект, пришло время считать инкрементальность: сравнить не “кто пришёл”, а “что изменилось в поведении” у пользователей, которых действительно экспонировали креативу/кампании.

Ниже — рабочий шаблон A/B расчёта в BigQuery: exposure → outcome, контроль смещений, расчёт метрик и статистики.

Шаг 1. Сведите данные к одному “пользователь-экспозиция”
Вам нужны минимальные таблицы (можно в одной, но удобнее разделить):

— exposures: user_id, experiment_id, variant (A/B), exposed_at
— events: user_id, event_name, event_timestamp, order_id (если применимо)
— optional: users_dim (industry/company_size/geo и т.п.)

Рекомендация: делайте интервальную привязку. Например, outcome считаем в окне 7 дней после exposed_at.

Шаг 2. Назначьте “когортный таймбокс”
В BigQuery соберите CTE, которая для каждого user_id-экспозиции определит, попал ли он в окно исхода.

Пример логики (адаптируйте под ваши event_name):
— first_conversion_in_window: MIN(event_timestamp) WHERE event_name='purchase' AND event_timestamp BETWEEN exposed_at AND exposed_at+INTERVAL 7 DAY

В итоге у вас по каждой строке будет:
user_id, variant, converted (0/1), revenue (сумма заказов в окне), т.д.

Шаг 3. Устраните дубликаты и “повторные экспозиции”
Частая ошибка — один пользователь попал в тест несколько раз, и вы его несколько раз “учитываете”.

Практика:
— оставляйте одну экспозицию на пользователя: earliest exposed_at
— если есть правило частоты (frequency cap) — примените его до агрегаций
— если вариант менялся между экспозициями — фиксируйте вариант по первой экспозиции

В SQL это делается через ROW_NUMBER() по user_id ORDER BY exposed_at.

Шаг 4. Соберите агрегаты по вариантам
Для каждого variant посчитайте:
— users: COUNT(DISTINCT user_id)
— conversions: SUM(converted)
— conversion_rate = conversions / users
— avg_revenue = SUM(revenue) / users (важно делить на всех, а не только на конвертировавших — так вы увидите реальную экономику)

Шаг 5. Посчитайте инкремент через разницу в метрике
— lift_CVR = rate_B - rate_A
— incremental_users = conversions_B - conversions_A
— incremental_revenue = revenue_B - revenue_A

Если вы хотите “как в отчётах RevOps” (общая ответственность маркетинга/продаж/CS за выручку), считайте инкремент по выручке в окне, а не только по конверсии.

Шаг 6. Добавьте контроль смещений через взвешивание
Zero-click эпоха и privacy-first атрибуция часто приводят к тому, что группы не равны по составу (geo, отрасль, размер компании).

Быстрый и безопасный способ:
— посчитать propensity score на уровне users_dim (логистическая регрессия или градиентный бустинг — на практике можно ограничиться простым GLM)
— затем сделать IPTW (инверсные вероятности) или просто reweight по калибровочным признакам
— пересчитать lift на взвешенных данных

Если не хотите усложнять модель: начните с reweight по 2–3 ключевым признакам (geo + device или geo + segment). Это уже часто снижает “шум кампании” по сравнению с сырой разницей.

Шаг 7. Проверьте пер-юзер экспозицию на “микроутечки”
Проверьте: нет ли пересечений user_id между A и B.
— если есть, значит таргетинг/логика распределения нарушены
— тогда A/B будет считать не эффект, а “перетасовку”

Практически: COUNT(DISTINCT user_id) в A и B и пересечение (A∩B) — даже 0.1–0.5% может заметно повлиять на маленьких тестах.

Шаг 8. Оформите результат в одном датасете для автозагрузки в BI
Запишите в таблицу result_metrics:
experiment_id, window_days, metric_name, variant, value, lift_vs_control, sample_size

Так вы сможете строить тренды инкремента по кластерам (канал/аудитория/креатив-концепт), что важно в 2026, когда AI-генерация креативов ускоряет цикл, но побеждает структура смысла и доказуемый эффект.

Если хотите — пришлите названия ваших таблиц и целевое событие (purchase/lead/demo_request) + окно (например 7/14 дней), и я подстрою SQL-шаблон под ваш кейс.

— @BigQuery4MarketingPro

Я короче хз зачем мне это , но напишу!
Короче смотрим за "ноунейом" ( ЕЮ ) и тот вообще крышей поехал) взял себе крутанул канал на 1млн подписчиков и хочет сделать его своим основным?
Армия ботов в перед!

Вот его новый канал если что.. https://t.me/+vKOoe6K4yL0wMzEy

Как BigQuery помогает маркетингу увидеть вклад каналов без last-click

У многих команд в 2026 году одна и та же проблема: платный трафик дорожает, last-click-атрибуция искажает вклад каналов, а отчёты в рекламных кабинетах всё хуже объясняют, что реально двигает выручку. Особенно это заметно в брендинге, B2B и performance-командах, которые уже работают не только на заявки, но и на выручку.

В одном из таких кейсов маркетинговая команда собрала данные в BigQuery и свела в одну модель:
— расходы по каналам;
— события на сайте и в приложении;
— транзакции и выручку;
— CRM-статусы по лидам и сделкам.

**Задача** была простой по формулировке, но сложной по сути: понять, какие каналы действительно создают вклад в выручку, а какие лишь «забирают» финальный клик.

**Решение** сделали через BigQuery:
— объединили данные из рекламных систем, GA4 и CRM;
— привели к единым идентификаторам пользователя и сделки;
— построили отчёт не только по последнему касанию, но и по цепочке взаимодействий;
— отдельно сравнили отчёты кабинетов с собственной витриной данных.

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

Точных публичных цифр в кейсе не раскрывали, и это нормально: ценность здесь не в «магическом росте на 237%», а в том, что BigQuery даёт единый слой правды для маркетинга, sales и аналитики.

**Урок для команды:** если у вас B2B или сложный цикл сделки, не пытайтесь управлять бюджетом только по last-click. В 2026 году выигрывают те, кто строит в BigQuery общую модель данных для маркетинга, CRM и выручки — и смотрит на вклад каналов, а не на красивую конечную точку в кабинете.

— @BigQuery4MarketingPro

BigQuery как ядро RevOps: почему ваша таблица с лидами теперь не нужна

В 2026 году классическая воронка MQL→SQL→Closed Won окончательно потеряла смысл. Рынок B2B перестал прощать разрозненность. Если маркетинг генерит «сырые» лиды, продажи их скливают, а customer success теряет контакт с базой — вы не просто теряете конверсию, вы теряете выручку на уровне +-20% по данным проектов, которые я видел в этом году.

RevOps (управление выручкой) требует единого графа данных: контакт, его действия на сайте, касания в CRM, статус в онбординге, сумма в current billing. BigQuery — единственный инструмент, где можно собрать это без костылей.

Моё наблюдение: большинство внедрений RevOps тонет не в методологии, а в том, что данные маркетинга лежат в GA4 или Amplitude, данные продаж — в amoCRM или HubSpot, а данные лайфсайкла — в стороннем сервисе. Инженеры тратят недели на ETL-скрипты, которые ломаются при первом изменении API.

Мы пошли другим путём: объединили стримы из AppMetrica, Google Ads и CRM напрямую в BigQuery через готовые коннекторы и Dataform для трансформаций. Получили единую таблицу `revenue_events`, где на каждую дату по каждому контакту лежит: источник касания, тип события, ценность. Никаких more funnel stages — только сквозная цепочка.

**Цифра из практики**: на одном из проектов B2B SaaS после такой сборки мы увидели, что 34% лидов, которые маркетинг отдавал как «нецелевые» (малый бизнес), через 60 дней приносили payment с LTV выше среднего. Просто потому, что эти компании быстрее внедряли продукт. Старая воронка этого не показывала — она отсекала их на входе.

Вывод: не стройте ещё одну dash-панель с лидами. Стройте BigQuery как операционную базу для расчёта revenue velocity (скорости выручки) и unit-экономики по каждому сегменту. Именно это убирает барьер между маркетингом, продажами и продуктом.

— @BigQuery4MarketingPro

Как настроить Server-Side атрибуцию (серверный сбор данных) для оценки эффективности в эпоху privacy-first

В 2026 году классические файлы cookie (куки) сторонних сервисов блокируются браузерами почти на 90%. Атрибуция по последнему клику стала бесполезной, поэтому мы переходим на сбор данных на стороне сервера и передачу их напрямую в BigQuery. Это позволяет сохранять историю пользователя, даже если он запретил отслеживание в браузере.

Для реализации этого процесса выполните следующие шаги:

— Настройте серверный контейнер Google Tag Manager. Разместите его на собственном поддомене вашего сайта (например, s.site.ru), чтобы браузеры воспринимали запросы как «первичные», а не сторонние.

— Настройте передачу событий из GTM напрямую в Google Cloud Platform. Внутри серверного GTM добавьте тег Google Cloud Pub/Sub. Данные будут падать в очередь, что гарантирует их сохранность при пиковых нагрузках на сайт.

— Создайте таблицу в BigQuery. Используйте схему данных, соответствующую Google Analytics 4, чтобы иметь возможность сравнивать серверные данные с клиентскими в едином интерфейсе.

— Настройте Cloud Function (облачную функцию), которая будет считывать сообщения из Pub/Sub и записывать их в нужную таблицу BigQuery. Важно: обязательно настройте парсинг входящего JSON-объекта, чтобы вытаскивать client_id или уникальный идентификатор пользователя из базы данных.

— Соедините данные с CRM. В BigQuery добавьте таблицу с продажами (выгрузка из CRM). Используя SQL-запрос, объедините идентификатор пользователя из веб-аналитики с идентификатором сделки.

**Почему это важно для RevOps (единой системы управления выручкой):**
Без этого этапа вы не увидите, как конкретный поисковый запрос или контентная статья влияют на итоговый LTV (пожизненную ценность клиента). Сбор данных через сервер дает вам базу для построения MMM (моделирования маркетингового микса), которая в текущих условиях является единственным надежным способом оценки вклада маркетинга в выручку компании.

На этой неделе проверьте, какой процент ваших событий теряется из-за блокировщиков рекламы. Если показатель выше 15%, приступайте к настройке серверного контейнера. В следующем посте разберем, как написать SQL-запрос для объединения этих данных с показателями Retention (удержания клиентов).

— @BigQuery4MarketingPro

Снижаем стоимость лида без “последнего клика”: как я строю privacy-first атрибуцию в BigQuery

В 2026 я всё чаще вижу одну и ту же боль: команды продолжают оптимизировать рекламу так, будто на другом конце стоит честный last-click (последний клик), а данных для него всё меньше. Cookies сыпятся, согласия меняются, и атрибуция превращается в спор “кто молодец”, а не в решение “что масштабировать”. Я решил эту проблему не очередной моделью “на словах”, а стабильной схемой в BigQuery, которая выдерживает privacy-first ограничения.

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

Как я делаю это в BigQuery:
— Загружаю события в единую витрину: клики/показы/сеансы, лид-статусы (MQL/SQL/оплата), события согласий и технические идентификаторы (без персональных данных).
— Строю “окна экспозиции” (например, 1/7/14 дней) и агрегирую экспозиции по пользователям/организациям в уровне кампаний (или групп креативов).
— Считаю базовую конверсию “как если бы рекламы не было”: берём сегменты с низкой вероятностью воздействия (например, органические/прямые источники или зоны, где частота экпозиции минимальна).
— Дальше сравнение делаю на уровне когорт: инкремент = разница конверсии/выручки между тестовой и контрольной когортой, но с контролем за миксом каналов и временем.

Одно наблюдение из практики (и оно меня удивило): когда мы заменили last-click оптимизацию на инкрементальный proxy, стоимость лида в B2B снизилась не потому, что “кампании стали лучше”, а потому что реклама перестала добивать тех, кто и так дошёл бы до статуса MQL без неё. В среднем в наших проектах это давало 10–25% экономии по CPL при сохранении качества SQL (оценивали по доле перехода в продажи в течение фиксированного SLA).

Почему BigQuery здесь удобен:
— можно хранить сырые события и пересчитывать метрики по новым правилам атрибуции без перепостроения ETL “с нуля”;
— удобно поддерживать наборы признаков для MMM (маркетингового микса) и MMM-поддерживающих регрессий позже, не ломая текущую оптимизацию;
— запросы на когортные сравнения и сглаживание (например, по времени) выполняются предсказуемо.

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

— @BigQuery4MarketingPro

BigQuery как фундамент RevOps: почему MQL и SQL перестали быть значимыми

Уже год я вижу одну и ту же картину в B2B-компаниях, которые приходят ко мне с запросом «настроить сквозную аналитику». Они по-прежнему хотят считать конверсию из лида в сделку, строить воронку по MQL (Marketing Qualified Lead — маркетинговый квалифицированный лид) и SQL (Sales Qualified Lead — квалифицированный лид отдела продаж), а потом удивляются, что прогнозы не сходятся, а ROI рекламы падает. Проблема не в инструменте, а в модели мышления.

Классическая воронка MQL→SQL→Opportunity→Revenue умирает не потому, что она плоха, а потому, что цикл сделки стал нелинейным. В 2026 году покупатель в B2B приходит из четырёх касаний, два из которых — organic search после AI-overview, одно — вебинар с контентом от CS (Customer Success — работа с удержанием клиентов), и только последнее — платное объявление. Кто «забрал лида»? Маркетинг? Продажи? Или команда успеха, которая проконсультировала на конференции за полгода до заявки?

Ответ — никто. Выручку зарабатывает вся компания, и именно для этого существует RevOps (операционная модель общей ответственности за выручку). Маркетинг, отдел продаж и Customer Success перестают быть изолированными silos (башнями). Их данные должны сходиться в одной точке — и этой точкой становится BigQuery.

BigQuery здесь незаменим: он принимает сырые события из CRM (сделки, этапы, длительность воронки), из рекламных кабинетов (cost-per-click, показы — уже без кросс-доменных кук, только server-side данные), из продукта (логи use-case внутри SaaS) и из службы поддержки (тикеты, CSAT). Всё это ложится в одну плоскую таблицу, где каждая строка — событие по одному контрагенту с временной меткой.

На моём опыте, клиенты, которые перешли на RevOps-аналитику в BigQuery, повысили точность прогнозов выручки на 20–25% (данные по трём проектам за 2025 год). Главное изменение: они перестали мерить «количество лидов» и начали мерить time-to-value — сколько времени проходит от первого контакта до момента, когда клиент начал активно использовать продукт. Если этот интервал растёт — проблема не в лидах, а в онбординге или поддержке. BigQuery подсвечивает это за счёт объединения data source (источников данных) без ETL-танцев.

Резюмирую: если вы всё ещё строите вложенные SQL-запросы для отчёта по конверсии MQL→Closed Won, вы тратите время на метрику, которая не управляет выручкой. Переключитесь на единую модель клиентских событий в BigQuery, привяжите к ней ответственность всех команд — и вы увидите реальную картину.

— @BigQuery4MarketingPro

1. Выкатить ни какую он-лайн конфу я естесвенно не выкатил, потерпите

2. После прошлого видео (тык) мой канал теперь имеет юзер @PO_YICA_BRAL

3. Держите вечернее видео, я нажрусь и спать

Чото надо ещё сказать? Ну, можно лишь добавить Настя #MelBet верни деньги, не играй с огнём, со мной лучше не ссориться. Спасибо.

P.S. Бабка-то, похоже, не своей..... см. видео!

С уважением, Иванов Е.Ю!