Почему атрибуция по последнему клику в 2026 году стала вредным атавизмом

Маркетинговая аналитика окончательно сменила вектор. Если раньше мы охотились за конверсиями, приписанными конкретному каналу через приевшуюся модель последнего клика (last-click), то сегодня такой подход напоминает попытку измерить температуру больного по фотографии. В эпоху приватности, когда браузеры и операционные системы блокируют сторонние файлы cookie, а пользовательский путь напоминает запутанный клубок, полагаться на стандартные отчеты рекламных кабинетов — значит осознанно принимать неверные решения.

В BigQuery мы уходим от оценки «какой баннер сработал» к оценке «как экосистема медиа влияет на выручку». Сейчас критически важно строить собственные модели маркетингового микса (Marketing Mix Modeling, MMM) прямо внутри хранилища. Это позволяет связывать данные о расходах с данными о продажах, учитывая внешние факторы: сезонность, макроэкономические колебания и даже активность конкурентов.

Мое наблюдение на практике: компании, которые отказались от слепой веры в last-click в пользу инкрементального анализа (оценки прироста, который дает канал сверх естественного спроса), в среднем увеличивают эффективность бюджета на 12–15% в течение полугода. Суть проста: вы перестаете платить за тех, кто совершил бы покупку и без вашего напоминания, и перераспределяете средства на охватные кампании, которые формируют узнаваемость бренда и тот самый Topical Authority (авторитет в теме), который так важен для алгоритмов поиска.

Как это выглядит в архитектуре данных:
— Сбор server-side (серверных данных) событий напрямую в облако, минуя потери от блокировщиков рекламы.
— Обогащение данных по цепочке касаний (customer journey) для каждой транзакции.
— Использование SQL для расчета коэффициентов влияния каждого канала на итоговый LTV (пожизненную ценность клиента).

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

— @BigQuery4MarketingPro

Марк Цукерберг извинился перед Индией

Статья о давлении индийских властей на крупные соцсети из-за дипфейков и материалов сексуального насилия над несовершеннолетними. Цукерберг публично извиняется, чтобы снизить риск блокировки Facebook и WhatsApp в крупном geo. Вывод: регуляторы в Индии ужесточают контроль, и для платформ это уже вопрос доступа к рынку, а не репутации.

➡️ Читайте на сайте: https://aff.top/blog/mark-cukerberg-izvinilsia-pered-indiei

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

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