Как поставить цель атрибуции: что именно оптимизируем и почему

На практике многие провалы, связанные с атрибуцией, начинаются ещё до выбора модели — на этапе, когда цель сформулирована размыто или подменяется удобной метрикой.

Давайте поговорим о самом первом шаге: как корректно поставить цель атрибуции, чтобы модель считала то, что действительно нужно бизнесу.

Что такое цель атрибуции и зачем она нужна

Атрибуция в маркетинге — это метод распределения ценности конверсии между каналами и точками контакта пользователя.

Простыми словами: если человек видел рекламу в нескольких каналах и в итоге купил, атрибуция отвечает на вопрос — какой вклад внёс каждый канал. Некоторые модели приписывают вклад одному-единственному каналу, но это частности.

Чтобы результаты атрибуции были интерпретируемыми и пригодными для решений, заранее фиксируют:

• какое событие мы считаем результатом
• какую метрику оптимизируем
• для какого управленческого решения нам это нужно

Если цель сформулирована неверно, модель может быть сколь угодно математически корректной, но выводы окажутся неверными.

Почему оптимизация CPA — это не цель атрибуции

CPA (Cost Per Action) — это стоимость целевого действия. Например, лида или продажи.

Фраза «мы оптимизируем CPA» звучит логично, но это не цель атрибуции. Это производная метрика.

CPA = расходы / количество целевых действий.

Например, потратили 100 000 ₽ и получили 200 заявок — CPA = 500 ₽.

Но атрибуция работает не с самим CPA. Она распределяет кредит за выбранный результат между каналами. И главный вопрос — что именно считается результатом: заявка или продажа?

Пример:

• Канал A дал 150 заявок
• Канал B дал 50 заявок

Если целевое событие — заявка, вклад A будет выше. Но если из A купили 3 клиента, а из B — 20, то при выборе продажи как цели распределение изменится.

Расходы те же. Модель та же. Меняется только выбранное событие — и вместе с ним меняется итоговый CPA.

Выбор целевого события: что именно считать результатом

Перед запуском атрибуционной модели необходимо определить, какое событие будет целевым.

1. Лид

Уровень

Базовый. Настраивается в любой системе аналитики без CRM и BI.

Что считается результатом

Результатом считается любая заявка или регистрация. В атрибуции каждая заявка — это одна единица ценности.

Как это используется на практике

В системах аналитики настраивается событие отправки формы или регистрации. Это событие связывается с источником трафика и идентификатором пользователя, поэтому попадает в атрибуционные отчёты.

Дальше в модели выбирается цель «лид», и заявки распределяются между каналами по выбранной логике атрибуции.

В отчётах вы видите:

• Сколько заявок засчитано каждому каналу.
• Сколько стоил каждый канал.
• Какой у него итоговый CPA.

Фактически вы оптимизируете стоимость обращения, а не продажи.

Где это оправдано

• Продажи происходят офлайн и не связаны с онлайн-пользователем.
• Нет интеграции CRM и аналитики.
• Задача — увеличить поток обращений, а не оценивать экономику сделки.

Плюсы

• Событие появляется сразу, поэтому можно быстро корректировать кампании.
• Настройка не требует сложной архитектуры данных.

Риски

• Лид не равен деньгам, поэтому отчёт может усиливать каналы с большим объёмом заявок, даже если они почти не приводят к продажам.
• Оптимизация по лидам может создавать иллюзию эффективности при слабой конверсии в сделки.

Пример

Канал A — 300 заявок, CPA 700 ₽.
Канал B — 120 заявок, CPA 1 100 ₽.

Если цель — лид, бюджет уходит в A. Но если из A в продажу доходит 2%, а из B — 20%, оптимизация по лидам будет вводить в заблуждение и усиливать менее прибыльный канал.

2. Квалифицированный лид MQL / SQL

Уровень

Средний. Нужна CRM и передача статусов обратно в аналитику. Если статус квалификации не возвращается из CRM как отдельное событие, атрибуция будет видеть только заявки, но не их качество.

Что считается результатом

Результатом считается не любая заявка, а только прошедшая фильтр качества.

• MQL (marketing qualified lead) — заявка соответствует формальным критериям целевого клиента.
• SQL (sales qualified lead) — заявка подтверждена продажами как реальная возможность сделки.

Как это используется на практике

В аналитике фиксируется заявка. В CRM ей присваивается статус MQL или SQL по заранее заданным правилам.

Чтобы использовать этот статус в атрибуции, его нужно вернуть обратно в аналитику как отдельное целевое событие через интеграцию или загрузку офлайн-данных. Только после этого модель сможет распределять не все заявки, а только квалифицированные.

В отчётах вы видите:

• Сколько MQL или SQL дал каждый канал.
• Стоимость одного квалифицированного лида.
• Какие каналы приводят потенциальные сделки.

Теперь вы оптимизируете не поток обращений, а поток клиентов, реально способных дойти до продажи.

Где это оправдано

• Между заявкой и продажей большой разрыв по качеству.
• Есть формализованные критерии клиента.
• Продажа требует участия менеджера.
• Важно оценивать не обращения, а сделки.

Плюсы

• Сравнение каналов становится ближе к реальной выручке.
• Каналы с большим объёмом нерелевантных заявок перестают казаться эффективными.

Риски

• Нужна корректная интеграция CRM и аналитики.
• Критерии квалификации должны быть стабильными.
• Решения принимаются с задержкой, потому что квалификация происходит позже заявки.

Пример

Канал A — 200 заявок → 15 SQL.
Канал B — 180 заявок → 40 SQL.

Если цель — SQL, атрибуция перераспределит вклад в пользу B, потому что именно он приводит больше потенциальных сделок.

3. Продажа

Уровень

Базовый для онлайн-продаж, если покупка фиксируется на сайте. Если продажи живут в CRM или происходят офлайн, их нужно загружать обратно в аналитику с привязкой к пользователю.

Что считается результатом

Факт сделки: оплата, подтверждённый заказ или подписанный договор. В атрибуции каждая продажа — одна единица результата.

Как это используется на практике

Если продажа происходит онлайн, событие покупки фиксируется в аналитике автоматически.

Если продажа живёт в CRM или происходит офлайн, её нужно загрузить обратно в аналитику как офлайн-конверсию с привязкой к пользователю. Без этого продажа не попадёт в атрибуционные отчёты.

В отчётах вы видите:

• Сколько продаж дал каждый канал.
• Стоимость одной продажи.
• Какие каналы реально доводят пользователя до сделки.

В этом случае вы оптимизируете не заявки, а реальные продажи.

Где это оправдано

• Есть техническая связка между рекламой и фактом продажи.
• CRM и аналитика объединены по идентификатору пользователя.
• Важна именно сделка, а не обращение.

Плюсы

• Цель максимально близка к деньгам.
• Качество лидов учитывается автоматически, потому что слабые заявки не доходят до сделки.

Риски

• Если часть продаж не возвращается в аналитику, отчёт будет показывать неполную картину.
• Длинный цикл сделки замедляет обратную связь и усложняет оперативную оптимизацию.

Пример

Канал A даёт много заявок, но мало продаж.
Канал B даёт меньше заявок, но больше сделок.

Если цель — продажа, вклад смещается к каналу B, потому что именно он приносит реальный результат.

4. Выручка

Уровень

Базовый для e-commerce, если сумма заказа передаётся вместе с покупкой. Если деньги фиксируются только в CRM, потребуется интеграция для передачи стоимости сделки в аналитику.

Что считается результатом

Денежная сумма сделки. Каждой покупке присваивается value — её стоимость.

Как это используется на практике

В аналитику передаётся не только факт покупки, но и сумма заказа. Атрибуция распределяет между каналами рубли выручки, а не просто количество продаж.

В отчётах вы видите:

• Сколько выручки принёс каждый канал.
• Доход на 1 рубль рекламных инвестиций.

Важно понимать: выручка обычно используется как аналитический слой для сравнения каналов. Автоматическая оптимизация по деньгам зависит от возможностей конкретной рекламной платформы.

Где это оправдано

• Средний чек различается по каналам.
• Есть крупные и мелкие клиенты.
• Управленческая задача — управлять оборотом.

Плюсы

• Позволяет сравнивать каналы по деньгам, а не по количеству сделок.
• Устраняет искажение при разном среднем чеке.

Риски

• Выручка не равна прибыли.
• Требуется корректная передача суммы заказа.

Пример

Канал A — 100 заказов по 5 000 ₽.
Канал B — 20 заказов по 100 000 ₽.

По количеству продаж выигрывает A. По выручке выигрывает B.

5. Маржа

Уровень

Продвинутый. Маржа рассчитывается вне системы веб-аналитики — в CRM, учётной системе или BI — и затем передаётся обратно в систему аналитики как ценность конверсии, чтобы использоваться в атрибуционных отчётах.

Что считается результатом

Прибыльная часть сделки.

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

Как это используется на практике

Системы веб-аналитики не знают себестоимость автоматически. Маржа рассчитывается в учётной системе или BI, после чего передаётся в аналитику как value.

Атрибуция распределяет уже рубли прибыли между каналами.

Где это оправдано

• Маржинальность продуктов сильно различается.
• Есть скидки и акции.
• Важно управлять прибыльностью, а не оборотом.

Плюсы

• Позволяет оценивать вклад каналов в прибыль, а не в выручку.

Риски

• Требуется интеграция с учётной системой.
• Методика расчёта маржи должна быть стабильной.

Пример

Канал A — 1 млн ₽ выручки → 50 тыс ₽ маржи.
Канал B — 400 тыс ₽ выручки → 120 тыс ₽ маржи.

По выручке выигрывает A. По марже выигрывает B.

6. LTV

Уровень

Самый продвинутый. Требуется история повторных покупок и стабильная идентификация клиента, чтобы связать долгосрочную ценность с источником привлечения.

Что считается результатом

Совокупная ценность клиента за период жизни.

Как это используется на практике

LTV рассчитывается в CRM или BI на основе истории покупок. Затем эта ценность связывается с источником привлечения и при необходимости передаётся в аналитику как value.

Атрибуция распределяет долгосрочную ценность между каналами.

Где это оправдано

• Подписочная модель.
• Повторные покупки.
• Удержание важнее первой сделки.

Плюсы

• Позволяет оценивать долгосрочный вклад каналов.

Риски

• Требуется время для накопления данных.
• Нужна стабильная идентификация клиента.

Пример

Канал A приводит клиентов, которые покупают один раз.
Канал B приводит клиентов, которые остаются 12 месяцев.

По первой покупке A может выглядеть сильнее. По LTV выигрывает B.

Почему цель бизнеса и цель атрибуции часто не совпадают

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

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

Если бизнесу нужен рост прибыли, а в атрибуции в качестве результата выбраны лиды, между этими уровнями возникает разрыв. Бизнес измеряет деньги, а модель распределяет заявки. Это разные уровни управления.

Типичный сценарий

1. Бизнес хочет увеличить прибыль.
2. Маркетинг оптимизирует лиды, потому что они быстрее фиксируются и проще считаются.
3. Атрибуция усиливает канал, который генерирует больше заявок.
4. Качество заявок постепенно падает.
5. Отдел продаж перегружен нерелевантными обращениями.
6. Фактическая прибыль не растёт.

При этом модель работает корректно. Она честно распределяет лиды по каналам. Ошибка возникает не в алгоритме, а в выбранной цели.

Как правильно сформулировать цель атрибуции

Перед выбором модели нужно ответить на четыре практических вопроса.

• Какое событие действительно отражает экономическую ценность для бизнеса
  Какой результат вы хотите распределять между каналами: лид, SQL, продажа, выручка, маржа, LTV. То есть за что бизнес реально готов платить маркетингу.
  
  
• Доступны ли данные по этому событию
  Можете ли вы вообще зафиксировать это событие в данных: есть ли оно в аналитике / CRM, записывается ли факт и дата, хранится ли сумма заказа, статус лида, маржа, повторные покупки.
  
  
• Связано ли это событие с рекламными источниками технически
  Есть ли способ привязать событие к конкретному пользователю и его источнику трафика: сохраняются ли идентификаторы (например, client ID, user ID, рекламные клики). Можно ли передать событие из CRM обратно в аналитику вместе с тем же идентификатором пользователя или клика, чтобы система смогла понять, из какого канала и кампании пришёл этот клиент.
  
  
• На каком уровне принимается управленческое решение
  Под какую реальную задачу вы используете атрибуцию: перераспределить бюджет между каналами, оценить эффективность кампаний, отсеять источники нецелевых лидов, выбрать стратегию роста. Целевое событие должно соответствовать этому уровню, иначе между бизнесом и маркетингом возникнет диссонанс.
  

Если атрибуция используется для перераспределения бюджета между каналами, цель должна соответствовать тому уровню, на котором принимается решение.

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

Типовые ошибки при постановке цели

Ошибка 1. Выбрали удобное событие, а не экономически значимое

Клики, регистрации и заявки проще фиксировать, чем продажи или прибыль. Но простота учёта не делает метрику корректной.

Если цель выбрана по принципу “это легче настроить”, атрибуция начнёт усиливать именно это событие — даже если оно слабо связано с реальными деньгами.

Ошибка 2. Игнорирование качества

Атрибуция распределяет то, что ей задано. Если в качестве результата выбран объём обращений, модель будет усиливать объём.

Проблема возникает, когда внутри выбранного события сильно различается качество. В этом случае каналы с большим количеством слабых заявок могут выглядеть эффективнее каналов, которые дают меньше обращений, но больше продаж.

Ошибка 3. Разрыв данных

Если CRM не связана с рекламной аналитикой, модель считает неполную картину.

Продажи могут происходить, но не возвращаться в аналитику. Тогда даже продвинутая data-driven attribution — алгоритмическая модель, рассчитывающая вклад каналов на основе вероятностных методов — будет распределять только ту часть событий, которую “видит”.

Алгоритм может быть математически корректным, но данные будут неполными. А значит, управленческие выводы окажутся искажёнными.

Ошибка 4. Несоответствие горизонта

Если LTV считается за год, а маркетинг оптимизируется по неделе, возникает конфликт горизонтов.

В коротком периоде данные ещё не отражают долгосрочную ценность клиента. Атрибуция физически не может распределить то, что ещё не произошло.

В результате принимаются решения по промежуточным метрикам, которые не совпадают с долгосрочной целью бизнеса.

Как работать с атрибуцией: алгоритм и постановка цели

Практичный порядок работы выглядит так:

• Формулировка управленческой задачи
• Определение целевого события
• Проверка качества и связности данных
• Выбор модели атрибуции
• Интерпретация результатов

На практике команды часто начинают с выбора модели, потому что модель — самый заметный элемент. Но без чёткой цели и проверки данных результаты сложно интерпретировать и легко использовать неправильно.

Сначала нужно ответить на вопрос, что распределяем, и только потом — как мы это делаем.

Частые вопросы

Что такое цель атрибуции в маркетинге?

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

Можно ли оптимизировать CPA через атрибуцию?

Да, но только если CPA считается по корректно выбранному событию. Если в знаменателе стоят необработанные лиды, система будет снижать стоимость лидов, а не стоимость продаж.

Что лучше использовать — лид или продажу?

Если технически возможно связать рекламу с фактической продажей, корректнее использовать продажу или выручку. Лид допустим, если цикл сделки короткий и качество заявок относительно однородно.

Зависит ли выбор цели от модели атрибуции?

В идеале цель определяется управленческой задачей, а модель подбирается под неё. На практике ограничения данных и инструмента могут влиять на выбор события. Тогда выбирают ближайший корректный прокси — например, SQL вместо продажи.

Резюме: основные выводы

• Атрибуция распределяет ценность выбранного события
• Оптимизация CPA — это работа с производной метрикой
• Выбор события определяет управленческие выводы
• Бизнес-цель и цель атрибуции должны быть согласованы
• Ошибка в постановке задачи опаснее ошибки в модели

Если цель выбрана неверно, даже математически корректная модель даст правильные ответы на неправильный вопрос. Это приводит к более серьёзным управленческим ошибкам, чем выбор неидеальной модели при корректно заданной цели.

Правильно сформулированная цель — фундамент всей атрибуционной логики.