Сквозная аналитика: как связать рекламу, заявки и оплаченные заказы
Как собрать сквозную аналитику: связать расходы, обращения, сделки и оплаты, разобраться в расхождениях и проверить первую версию отчёта.
Рекламный кабинет показывает обращения. На сайте фиксируются отправки формы. В CRM менеджеры видят сделки. Бухгалтерия — поступившие деньги. Все работают с одной компанией, но цифры могут описывать совершенно разные события.
Сквозная аналитика нужна, чтобы связать эти части и ответить на конкретный вопрос бизнеса. Например: какие обращения дошли до оплаты и что известно об их источнике. Для этого недостаточно поставить рядом несколько графиков. Нужно понять, как одна запись узнаёт другую и что именно считается результатом.
Я бы начинал с пути отдельного заказа. Если его нельзя объяснимо проследить вручную, красивый общий отчёт тоже будет вызывать вопросы.
Сначала определите вопрос отчёта
Компания может хотеть сравнить источники обращений, увидеть путь до оплаты или понять, как возвращаются покупатели. Это разные задачи, и набор данных для них различается.
Допустим, руководителю нужно видеть, какие рекламные кампании приводят к оплаченным заказам. Тогда понадобятся расходы, данные об источнике обращения, связь с продажей и подтверждённые сведения об оплате.
А если задача — оценивать повторные покупки, одной рекламной метки уже мало. Нужна история клиента и правила, по которым покупки относятся к одному покупателю. Такой анализ можно продолжить через RFM-сегментацию клиентской базы.
Запишите вопрос обычными словами. Затем определите, какие решения вы будете принимать по ответу. Это помогает ограничить первую версию аналитики и не собирать данные, которыми никто не пользуется.
Из каких частей собирается связь
Для первого разбора удобно разделить путь на пять участков.
| Участок | Что нужно зафиксировать | Что может пойти не так |
|---|---|---|
| Привлечение | Расходы и параметры кампании за согласованный период | Разные валюты, состав расходов и даты |
| Посещение | Доступные сведения об источнике перехода | Метки потерялись или были переписаны |
| Обращение | Запись запроса и её идентификатор | Повторная отправка создала ещё одну запись |
| Продажа | Связь обращения со сделкой и результатом работы | Несколько обращений относятся к одной продаже |
| Оплата | Подтверждённое событие и связь с заказом | Платёж не сопоставлен, есть частичная оплата или возврат |

Технический способ передачи может различаться. Важнее договориться, какие значения сохраняются, где находится исходная запись и кто исправляет несоответствие.
Например, рекламе известен переход, сайту — отправленная форма, CRM — номер сделки. Между ними требуется понятное сопоставление. По одному имени клиента надёжно связать все события обычно не получится: имена повторяются и меняются, обращения могут поступать от нескольких сотрудников одной организации.
Не путайте человека, обращение и продажу
Покупатель мог дважды заполнить форму и потом позвонить. В системе появилось несколько событий. Это ещё не доказывает появление нескольких новых клиентов или независимых продаж.
Бывает и обратная ситуация: один постоянный покупатель делает несколько самостоятельных заказов. Объединять их в одну продажу тоже неправильно для такого отчёта.
Поэтому до построения показателей согласуйте модель записей. В статье о лидах, контактах и сделках разобрано, что хранит каждая сущность и зачем нужны связи между ними.
В самой аналитике должны оставаться объяснимыми правила повторов. Руководителю полезно видеть не только итог, но и возможность открыть исходные записи и проверить, почему они попали в показатель.
На одном условном заказе проверьте всю цепочку
Представим обращение L-17. После уточнения задачи оно связано со сделкой D-31. Подтверждённая оплата P-94 относится к заказу этой сделки. Обозначения условные — они показывают принцип связи.
Проверьте, можно ли от оплаты вернуться к заказу, от него — к сделке и исходному обращению. А затем увидеть источник, который действительно сохранился для этого обращения.

Если на каком-то шаге связь отсутствует, это отдельная задача. Возможно, номер заказа не передаётся в платёж, сотрудник создаёт сделку вручную без исходного обращения или интеграция сохраняет новый объект вместо обновления прежнего.
Разбор передачи данных при обработке заказов помогает определить, где должны сохраняться идентификаторы и подтверждённые значения.
Разберём одну цепочку от обращения до денег: какие записи уже существуют и на каком участке теряется связь.
Ваша текущая скидка: …
Обсудить связь данных и получить скидкуПочему два правильных отчёта могут не совпасть
Разница не всегда означает поломку. Один отчёт считает обращения по дате поступления, другой — оплаты за этот же календарный период. Часть оплат могла относиться к запросам прошлого месяца.
Есть и вопрос источника. Человек впервые пришёл из поиска, позже вернулся по рекламе и затем написал напрямую. Чтобы отнести продажу к каналу, нужно выбрать правило распределения результата между касаниями — модель атрибуции.
У такого правила есть условия и ограничения. Оно помогает последовательно считать данные, но само по себе не доказывает, что определённый канал единолично вызвал покупку. Поэтому модель и окно рассмотрения должны быть понятны пользователю отчёта.
Отдельно обсудите:
- входят ли в сумму неоплаченные или отменённые заказы;
- как учитываются частичные платежи и возвраты;
- сравниваются ли сделки одного периода создания или поступления денег;
- какая часть обращений остаётся без определённого источника;
- что происходит с ручными заказами и офлайн-общением.
Категорию «источник не определён» лучше видеть явно. Произвольное распределение неизвестных обращений между красивыми каналами сделает отчёт убедительнее внешне, но слабее для принятия решений.
Что подготовить до выбора сервиса
Я бы составил карту источников: рекламные кабинеты, сайт, CRM, учёт и платёжная система. Для каждого указал доступные данные, ответственного, способ выгрузки и допустимую задержку обновления.
Затем проверил, можно ли получить нужные поля и связи в выбранной CRM. Об этом стоит подумать ещё до покупки системы. Наличие раздела «Аналитика» в демонстрации не подтверждает, что туда попадёт ваша конкретная история заказа.
Не нужно собирать лишние персональные сведения ради самого факта сбора. Доступ к данным, сроки хранения и использование идентификаторов согласуют с ответственными в компании. Рекламные метки не должны превращаться в место хранения телефонов, имён и другой лишней информации о человеке.
Как принимать первую версию
Для проверки возьмите разные исходы: оплаченный заказ, отказ, повторное обращение, частичную оплату и возврат, если эти ситуации встречаются в работе.
По каждому пройдите путь от исходной записи до итоговой строки. Проверьте период, источник, сумму, статус и правило включения. Посмотрите, как исправление в рабочей системе отражается в отчёте.
Когда магазин показывает мало заказов, параллельно проверьте корректность событий и путь покупателя. Ошибка измерения и реальное затруднение при покупке требуют разных действий.
После такой приёмки у руководителя должен появиться ответ не только «сколько получилось», но и «из каких записей это собрано». С этого начинается аналитика, которой можно пользоваться в обсуждении рекламы, продаж и доработок систем.
В Goncharoff.PRO можно согласовать вопрос отчёта, источники и правила связи данных. Начнём с результата, который важно видеть вашей компании.
Ваша текущая скидка: …
Разобрать задачу аналитики и получить скидку
Комментарии
Пока нет комментариев. Поделитесь своим мнением первым.