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

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