Почему расходится атрибуция продаж
Клиент нашёл сайт в поиске, позже перешёл по объявлению, а перед покупкой открыл сайт напрямую. Продажа одна. Но в одном отчёте её получит поиск, в другом реклама, а в третьем прямой заход. Разница ещё не означает, что один из отчётов сломан.
Модель атрибуции определяет, как связать результат с предыдущими касаниями клиента. Разберём, что именно меняет это правило, как сравнить данные Директа, Метрики и CRM и когда расхождение нужно искать в данных.
Короткий ответ
Сравнивайте модели на одном наборе оплат. Сначала зафиксируйте событие, даты и доступную историю клиента, затем меняйте правило выбора источника. Модель меняет распределение продаж между каналами, но сама по себе не создаёт новых продаж и не доказывает, что именно реклама вызвала покупку.
Одна покупка, три разных источника
Возьмём учебный пример. Один человек сначала пришёл из обычного поиска, затем вернулся по объявлению Директа, а в день покупки ввёл адрес сайта в браузере. Все три визита распознаны как визиты одного посетителя и доступны для расчёта.
Для начала сравним два простых правила. Первое отдаёт продажу первому известному касанию. Второе выбирает последний переход перед покупкой. Две цепочки на схеме показывают один и тот же путь, а не две покупки.
Если исключить прямое возвращение из значимых источников и выбрать предыдущее значимое касание, продажа в этом примере будет связана с Директом. Это третье правило, а не исправление ошибки в первых двух.
У каждого расчёта свой вопрос. Какой источник был первым в известной истории? Откуда человек пришёл в визите с покупкой? Какой значимый источник предшествовал прямому возвращению? Нельзя заменить эти вопросы одним словом «эффективность».
Какие модели есть в Яндексе и почему важны полные названия
В текущей справке Метрики перечислены «Первый переход кросс-девайс», «Последний переход», «Последний значимый переход кросс-девайс» и автоматическая атрибуция. Кросс-девайс означает учёт распознанных визитов с разных устройств. Старые варианты без этого уточнения нельзя автоматически считать действующими настройками. Источник: справка Метрики.
| Правило | Источник в нашем примере | Что проверяем |
|---|---|---|
| Первое известное касание | Поиск | Начало доступной истории клиента |
| Последний переход | Прямой заход | Возвращение непосредственно перед покупкой |
| Последнее значимое касание | Директ | Источник перед прямым возвращением |
Таблица объясняет правила на учебном пути. Результат конкретного отчёта зависит ещё от доступной истории, окна и распознавания посетителя. Для автоматической модели нельзя заранее нарисовать универсальное распределение: она использует алгоритмы, а не фиксированное правило «первый» или «последний». Источник: справка Директа.
Даже похожие названия разных платформ не гарантируют одинаковый расчёт. Например, в GA4 модель последнего клика по платным и обычным каналам обычно пропускает прямые заходы. Поэтому приравнивать её к «Последнему переходу» Яндекса только по слову «последний» нельзя. Источник: справка Google Analytics.
Окно атрибуции определяет, какие касания участвуют
Допустим, в собственном расчёте CRM мы учитываем касания за 30 дней до оплаты. Первый переход из поиска произошёл за 45 дней, рекламный за 7 дней, прямое возвращение в день покупки. При таком ограничении поиск остаётся в истории, но не участвует в выборе источника этой оплаты.
Здесь мы оставили правило первого касания, но сократили доступную историю. Источник поменялся с поиска на рекламу. Значит, сравнение «первая модель против последней» будет некорректным, если одновременно незаметно поменять окно.
30 дней на схеме относятся только к учебному расчёту CRM. Это не универсальная настройка Яндекса. Метрика описывает завершение истории после перерыва в 90 дней между визитами и не даёт пользователю менять окно. В справке Директа для ряда моделей указаны отдельные сроки. Условия двух сервисов нельзя подменять одним общим числом. Условия Метрики, условия Директа.
Как сравнить Директ, Метрику и CRM
Начните с определения результата. Отправка формы, созданная сделка и поступившая оплата могут принадлежать одному клиенту, но это разные события. Сравнивать количество целей «Заявка» с количеством оплат и объяснять разницу моделью атрибуции преждевременно.
- Выберите одно событие. Например, первую успешную оплату заказа. Уточните, как учитываются повторные оплаты, частичные платежи, отмены и возвраты.
- Зафиксируйте даты. Укажите период и часовой пояс. Проверьте, относится ли строка отчёта к дате визита, целевого действия или поступления денег. Не требуйте равенства от разных временных срезов.
- Проверьте связь событий. У оплаты должен быть заказ или сделка, у сделки связанное обращение, у обращения сохранённый источник. Для сопоставления с сайтом нужны доступные идентификаторы посетителя или клика.
- Запишите полные настройки. Название модели, условия окна, учёт устройств, цели и фильтры. Если одинаковые условия выставить нельзя, это ограничение сравнения, а не повод скрыть различие.
- Разберите несколько конкретных оплат. Сначала восстановите их пути вручную. Затем проверьте, что тот же порядок расчёта воспроизводится в отчёте.
Для начала достаточно таблицы с идентификатором оплаты, временем, суммой, связанной сделкой и последовательностью известных касаний. Сохраняйте исходную историю. Один столбец «источник сделки», который перезаписывается при каждом обращении, не позволит честно пересчитать разные модели.
Если история обрывается раньше расчёта, начните со статей про передачу UTM-меток из Директа в CRM и потерю источников в CRM. Новая модель не восстановит данные, которые никто не сохранил.
Почему одну оплату нельзя сложить из двух отчётов
Предположим, клиент взаимодействовал с двумя рекламными системами. Каждая располагает своей историей и по своим условиям засчитывает себе ту же оплату. Два отчёта показывают результат, но поступление денег было одно.
Для общего отчёта сначала соберите уникальные оплаты из принятого учёта продаж. Затем присвойте им источники по выбранному правилу. Отдельно можно сохранить результаты рекламных систем для сверки, но складывать их как независимые продажи нельзя.
Для модели, которая отдаёт всю продажу одному источнику, сумма продаж по каналам должна совпасть с числом уникальных продаж в выбранном наборе. Неопределённый источник оставляйте отдельной группой. Если модель распределяет доли, проверяйте сумму долей каждой оплаты, а не число строк после распределения.
Когда меняется ROMI, а продажи остаются прежними
Если расходы канала остаются прежними, а выбранная модель относит к нему другие оплаты, оценка его окупаемости изменится. Это следствие перераспределения результата. Сам факт смены цифры не означает, что реклама стала работать лучше или хуже.
Не смешивайте смену модели с изменением состава выручки, возвратов, расходов или маржи. Сначала пересчитайте один и тот же набор продаж по двум правилам, затем объясните, какие именно пути клиентов дали расхождение. Продажа, начавшаяся с рекламы и закончившаяся прямым заходом, объясняет перенос между каналами гораздо лучше, чем спор о «правильном» столбце.
Атрибуция описывает распределение результата в наблюдаемой истории. Чтобы ответить, состоялась бы покупка без рекламы, нужно отдельно оценивать причинное влияние, например с помощью корректно организованного эксперимента.
Что выбрать для рабочего отчёта
Универсально лучшей модели нет. Для поиска начала известного пути полезно первое касание. Для анализа визита с покупкой последний переход. Для сравнения значимых источников перед возвращением отдельный расчёт, который не отдаёт результат прямому заходу.
Выберите основное правило под управленческий вопрос и зафиксируйте его. Вторую модель используйте для проверки чувствительности вывода. Если канал выглядит прибыльным только при одном способе распределения, покажите это различие до решения о бюджете.
В Директе отделяйте выбор модели в отчёте от её смены в стратегии. Стратегия использует атрибуцию для обучения, поэтому изменение настройки влияет на её работу. Для проверки целевых показателей стратегии Яндекс рекомендует ту же модель в отчёте, что и в её настройках. Справка Директа.
Частые вопросы
Last-click всегда ошибается?
Нет. Правило последнего касания отвечает на определённый вопрос и может быть полезным. Ошибка возникает, когда его результат принимают за доказанный вклад всех каналов или сравнивают с отчётом, где другое событие и другая история.
Сохранённый yclid уже означает атрибуцию Директу?
Идентификатор помогает связать рекламный переход с последующими событиями, если интеграция сохранила эту связь. Он сам по себе не заменяет правило выбора источника. При нескольких касаниях всё равно нужно решить, как распределить результат.
Нужно ли добиваться полного совпадения трёх систем?
Сначала нужно добиться объяснимого расхождения. Часть разницы может возникнуть из-за неполной истории, разных дат и правил учёта. Для общего отчёта о продажах зафиксируйте один источник фактов об оплатах, а различия рекламных отчётов показывайте отдельно.
Что проверить перед следующим решением о бюджете
- Сравниваем один результат и один набор уникальных оплат.
- Понимаем, по какой дате построен каждый отчёт.
- Знаем полное название модели и условия доступной истории.
- Можем пройти от оплаты к сделке, обращению и касаниям.
- Не складываем одну продажу из нескольких рекламных отчётов.
- Отделяем перераспределение результата от изменения продаж.
Если эти условия не выполняются, сначала исправьте данные и договоритесь о правилах отчёта. О том, почему один красивый интерфейс эту задачу не решает, читайте в статье «5 ошибок в BI-отчётах».