Что нужно для сквозной аналитики с CRM

Начните с цепочки сущностей

Визит, человек, обращение, компания и сделка не являются одной записью. Один человек может несколько раз обратиться, одна сделка — объединять несколько контактов, а визиты — происходить с разных устройств. До подключения отчёта опишите, какие связи действительно доступны.

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

Подготовьте идентификаторы

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

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

Карта данных

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

Согласуйте статусы CRM

CRM полезна как источник дальнейших этапов, если сотрудники ведут их одинаково. «Успех» должен означать определённое событие: согласование, оплату или иной утверждённый результат. Нельзя сравнивать подразделения, которые используют один статус в разных смыслах.

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

Разберите дубли и несколько обращений

Повторная отправка одной формы и новое обращение того же клиента — разные ситуации. Определите правило объединения и сохраните историю. Не удаляйте все совпадения телефона автоматически: один контакт может обсуждать несколько самостоятельных задач.

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

Учитывайте время и незавершённость

Длинная B2B-сделка может завершиться значительно позже первого визита. Свежие обращения ещё не прошли все этапы, поэтому их нельзя напрямую сравнивать со старой завершённой группой. Используйте сопоставимое время наблюдения или явно показывайте незавершённость.

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

Проведите контрольную сверку

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

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

Как использовать результат

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

Сквозная аналитика считается подготовленной, когда связи можно объяснить, правила воспроизвести, а расхождения — увидеть. Она не обещает идеальной причинности, зато даёт команде общую основу для решений о рекламе, сайте и обработке обращений.

Пример сверки одной цепочки данных

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

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

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

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

Четыре обращения и три сделки: пример сверки

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

Идентификатор браузера записан у трёх из четырёх заявок: полнота этого поля составляет 75%. Это ещё не доля заказов, привязанных Метрикой к визитам. ClientID относится к браузеру, а успешность внешнего сопоставления проверяется отдельно. Два одинаковых ClientID сами по себе также не доказывают, что перед нами одна бизнес-сделка.

Пусть по D501 подтверждена оплата 120 000 ₽, по D502 — 80 000 ₽, а D503 остаётся в работе без оплаты. Итого в примере три уникальные сделки и 200 000 ₽ подтверждённых оплат. Если присоединить сумму D501 к обеим заявкам и затем сложить строки, получится ошибочные 320 000 ₽. Поэтому отчёт по оплатам сначала определяет единицу учёта и уникальный ключ сделки; для частичных платежей нужна отдельная модель платежных операций.

У L103 сохраняется неизвестный аналитический источник. Её не нужно исключать из бизнес-выручки или автоматически относить к прямому трафику. В отчёте рядом с результатом показывают полноту связи, чтобы сравнение рекламных каналов не скрывало несопоставленную часть.

Что проверить после передачи сделки в Метрику

Согласно документации импорта CRM, при отсутствии привязки заказа к визиту он доступен в отчёте посетителей и клиентов, но не попадает в остальные отчёты; связанные со статусами цели также не передаются в Директ. Поэтому успешную загрузку и найденную связь с визитом отмечают отдельно. Перед внедрением сверяют актуальные сроки дополнения данных и выбранный способ интеграции.

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

Как учитывать сделку, у которой источник так и не определён

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

Покажите долю сопоставленных записей, причины пропусков и период созревания сделок. Проверьте, не перезаписывает ли повторный импорт известный источник пустым значением. В учебной сверке нужны новая заявка, повторный клиент и продажа по нескольким обращениям. Модель распределения вклада должна быть описана до расчёта окупаемости. Сквозной отчёт полезен и с неполными данными, если границы покрытия прозрачны; искусственное заполнение пропусков создаёт ложную точность.