Ретроспективная оценка марк. эффективности с учетом сквозных ограничений (incrementality) в BigQuery

Ретроспективная оценка марк. эффективности с учетом сквозных ограничений (incrementality) в BigQuery

Маркетинг в 2026 все чаще упирается в privacy-first атрибуцию: last-click дает неполную картину, а “выгода” кампании зависит от того, сколько конверсий она принесла сверх того, что случилось бы само. На этой неделе можно собрать простую ретроспективную incrementality-модель прямо в BigQuery: сравнить фактические результаты с прогнозом “без кампании” на уровне аудитории и периодов.

1) Зафиксируйте “момент воздействия”
— Выберите одну воронку (например, регистрация → MQL).
— Для каждой кампании определите окно воздействия: start_date кампании и horizon (например, 14 дней).
— На уровне событий задайте флаг treated: event_date ∈ [start_date, start_date + horizon] и пользователя/организацию можно связать с экспонированием (через server-side логи, CRM-выгрузку или внутренний идентификатор).

2) Соберите витрину событий и фичи “до кампании”
Схема минимальной витрины в BigQuery:
— entity_id: идентификатор клиента/пользователя (в B2B удобнее аккаунт/org_id)
— event_date
— metric_flag: 1 если событие — целевое (например, became_mql)
— treated_date (дата экспозиции/зачисления в кампанию)
— covariates: показатели “фонового спроса” на дату (канал в целом, доля бренд/небренд в поиске, цена лида не нужна — только сигналы спроса)
Как сделать:
— Вытяните целевые события за период минимум “до + во время” (например, 8–12 недель).
— Для каждого entity_id сгруппируйте события по неделям (или дням), чтобы уменьшить шум.

3) Постройте прогноз “counterfactual” на обучении без treated
Логика:
— Берем только entity_id и периоды, где treated=0 (или до treated_date).
— Обучаем модель, предсказывающую вероятность/интенсивность целевого события по covariates и истории.
Практичный вариант без сложной ML-инфраструктуры:
— Используйте биграмм/агрегации и логистическую регрессию через BigQuery ML (если у вас она включена).
Что именно предсказывать:
— Либо binary target: случилось ли событие в day/week
— Либо rate: количество MQL на entity-week (с учетом частоты)

4) Сведите фактическое и прогнозное в инкрементальную метрику
После обучения:
— Для treated-периодов подставьте covariates и посчитайте predicted_p (ожидаемое без кампании).
— Инкремент:
incremental = actual_count - expected_count
Как посчитать в запросе:
— expected_count = predicted_p * 1 (или предсказанная интенсивность)
— actual_count = sum(metric_flag) по entity и периоду
Чтобы избежать “ложной уверенности”, агрегируйте минимум по неделям и по сегментам (SMB/Enterprise, отрасль, источник).

5) Проверьте качество на backtest (это обязательный шаг)
— Проведите “ложную кампанию” в прошлые периоды: сдвиньте treated_date на 4–6 недель назад и повторите pipeline.
— Если инкремент в backtest стабильно близок к нулю, а в реальном периоде — заметно выше, значит подход работает.
— Если в backtest тоже много инкремента, у вас, скорее всего, проблемы с фоном/сезонностью или treated связан с сильными базовыми отличиями сегментов.

6) Автоматизируйте выгрузку для RevOps и отчетов
Сделайте итоговую таблицу:
— campaign_id
— segment (опционально)
— period_start
— actual, expected, incremental
— lift = incremental / expected (осторожно с малым expected)
— confidence_proxy: ширина доверительного интервала (если есть) или хотя бы размер выборки entity

Почему это полезно именно сейчас
— В “zero-click” и Topical Authority ценность кампаний часто проявляется позже и частично через спрос, который нельзя атрибутировать по последнему клику.
— Incrementality позволяет говорить о влиянии на выручко-связанные метрики (MQL/SQL, activation), не притворяясь, что трекинг идеален.

Если хотите, пришлите: какая у вас сущность “entity_id” (пользователь или аккаунт), тип целевой метрики (MQL/SQL/первое событие/оплата) и чем подтверждается экспозиция. Я подскажу структуру таблиц и минимальный набор covariates под ваш кейс.

— @BigQuery4MarketingPro