Матричная атрибуция в BigQuery без боли: как связать маркетинг, продажи и customer success в единую модель

Матричная атрибуция в BigQuery без боли: как связать маркетинг, продажи и customer success в единую модель

Если в 2026-м вы всё ещё считаете результат по «последнему клику», то вы, скорее всего, меряете не продажи, а привычку пользователей к платформам аналитики. Дальше хуже: privacy-first ограничения и рост доли zero-click сценариев ломают точность микро-атрибуции, а бизнес ждёт не отчёт “сколько лидов”, а понимание вклада в выручку и удержание.

Хорошая новость: матричная атрибуция (модель распределения ценности по цепочке касаний) отлично ложится на BigQuery. Плюс она помогает встроить RevOps-подход: маркетинг, продажи и customer success (работа с клиентом) получают общую картину, а не спорят о том, кто “прав” в CRM-таблицах.

Ниже — как построить такую модель в BigQuery так, чтобы она была воспроизводимой, объяснимой и не превращалась в бесконечный проект.

Раздел 1. Сначала договоритесь о «событийной философии»: что считаем касанием, а что — конверсией

Тезис: матричная атрибуция держится не на алгоритме, а на согласованной схеме событий и времени.

Пример: в B2B часто встречаются разные определения:
— “лид создан” (маркетинг событие)
— “MQL подтверждён” (маркетинг-валидация)
— “SQL создан” (продажи)
— “первая сделка” и “подписанный договор” (выручка)
— “активация” и “здоровье аккаунта” (customer success)

Если вы в модели используете касания только на стороне рекламных платформ, но конверсию — в CRM, то неизбежны дырки по времени и каналам. В BigQuery лучше заранее зафиксировать таблицу касаний и таблицу ключевых исходов с единым ключом времени и пользователем/компанией.

Практика:
— Касания: на уровне пользователя или компании (что у вас “склеивается” лучше), с полями session_id или touch_id, timestamp, каналом, типом (реклама/контент/сайт/событие), источником идентификации.
— Исходы: на уровне lead/company/deal, с timestamp (момент ключевого этапа), revenue (если доступно) и стадией воронки.

В BigQuery это может выглядеть как два набора: `touch_events` и `conversion_events`. Важно: один и тот же стандарт времени (обычно UTC) и один и тот же “идентификатор цепочки” (например, `entity_id` = company_id для B2B). Тогда матрица не развалится на сверках.

Раздел 2. Соберите цепочки касаний: от “входного касания” до “момента ценности”

Тезис: матрица должна работать с цепочками, а не с разрозненными событиями — иначе вы получите красивые, но бессмысленные доли.

Пример: допустим, у вас есть вебинар (контент), после него человек читает кейс (SEO), затем дважды видит ретаргетинг (performance), а сделка подписывается через 45 дней. Если вы не построите цепочку, то алгоритм не поймёт, что эти касания относятся к одной “истории” и что маркетинг мог повлиять по нарастающему эффекту.

Как собрать цепочки в BigQuery:
— Выбираете “окно атрибуции” (например, 90 дней до конверсии — как правило, это разумная стартовая гипотеза, дальше уточняете данными).
— Для каждого исхода (`conversion_events`) находите касания того же entity_id в пределах окна.
— Упорядочиваете касания по времени и фиксируете “позицию касания” в цепочке (1-е, 2-е, …) или бинируете по сегментам (ранние/средние/поздние).

Технически полезная идея: делать не один гигантский join “touches к conversions”, а заранее строить “кандидатов касаний” и только потом — финальную матрицу. Это экономит деньги на запросах и повышает управляемость.

В результате вы получите датасет вида:
— `conversion_id`
— список touch_id и их атрибуты (канал/тип/позиция)
— флаг “канал-участник” (чтобы потом агрегировать по структурам)

Раздел 3. Постройте матрицу: простая объяснимая модель лучше сложной, которую никто не защитит

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

Пример: “классическая” матрица часто распределяет ценность по касаниям в зависимости от позиции:
— часть ценности — первому касанию (знакомство/привлечение)
— часть — последнему касанию перед сделкой (перевод в действие)
— оставшееся — всем промежуточным (доверие, прогрев)
…