Коллтрекинг в сквозной аналитике: каналы, телефония, CRM и продажи

Начните с одного вопроса, а не со списка интеграций

Фраза «нам нужна сквозная аналитика» слишком широкая для постановки задачи. Она может означать разные проблемы:

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

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

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

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

Разделите цепочку на пять разных объектов

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

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

Назначьте источник правды для каждого факта

Сквозной отчет не должен заставлять одну систему отвечать за все. Рекламный кабинет лучше знает расход и параметры кампании. Телефония надежнее фиксирует сам вызов. CRM хранит работу с обращением. Финансовая или учетная система подтверждает оплату.

У каждого факта должен быть один источник правды, а у каждого перехода между системами - устойчивый идентификатор и ответственный. Иначе одна и та же сделка меняет источник при обновлении, пропущенный звонок внезапно становится лидом, а сумма в отчете расходится с учетом без понятной причины.

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

Сохраните идентификаторы раньше, чем понадобятся отчеты

Название канала вроде Яндекс Директ не связывает конкретный звонок с конкретным визитом. Для этого нужны технические ключи, которые проходят через системы и не меняются при редактировании названия кампании или статуса сделки.

Минимальный набор зависит от инфраструктуры, но обычно включает:

1. идентификатор визита или пользователя в веб-аналитике;
2. идентификатор рекламного клика, если канал его передает;
3. собственный идентификатор звонка в телефонии или коллтрекере;
4. нормализованный телефон либо другой контактный признак;
5. идентификатор контакта, лида и сделки в CRM;
6. идентификатор заказа или платежа в учетной системе;
7. дату и время каждого события в согласованном часовом поясе.

Яндекс Метрика может получать от коллтрекера время звонка, длительность разговора и ожидания, признак пропуска и повторности, номер, URL и метки. При динамическом методе звонок связывается с подходящим визитом, а статический звонок остается доступен в отчетах без обычной привязки к визиту. Это описано в справке Яндекс Метрики. В детальном отчете также видны идентификатор конверсии и причина, по которой сопоставление не состоялось; для связи могут использоваться ClientId, UserId, Yclid или PurchaseId (описание отчета «Звонки, детально»).

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

Передавайте в CRM исходные данные и интерпретацию отдельно

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

Я предлагаю разделить данные на три слоя.

Исходные признаки

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

Нормализованные поля

Это единый словарь, который делает данные сопоставимыми: канал, кампания, регион, новое или повторное обращение, направление услуги, ответственный отдел. Значение нормализуется по утвержденному правилу, но исходное поле сохраняется для проверки.

Коммерческие статусы

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

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

Не перезаписывайте историю одним последним источником

Человек может увидеть рекламу, вернуться из поиска, позвонить по сохраненному номеру и спустя время заключить сделку. В этой цепочке нет одного универсально «правильного» источника. Есть несколько разных фактов:

• первый известный источник;
• источник визита, с которым связан звонок;
• последний источник перед обращением;
• канал, которому отчет приписывает результат по выбранной модели;
• собственный или партнерский канал повторного контакта.

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

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

Сверяйте не общие итоги, а переходы между системами

Одинаковое количество строк во всех системах не является целью. Телефония считает вызовы, CRM - контакты и сделки, финансы - принятые платежи. Полезная сверка показывает, сколько объектов прошло каждый переход и почему часть не прошла.

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

Развивайте контур по одному ограничению

Полная архитектура может включать рекламу, SEO, карты, офлайн-размещения, динамические номера, виртуальную АТС, CRM, BI и финансовый учет. Подключать все одновременно имеет смысл редко. Полезнее двигаться последовательными версиями.

1. Версия канала. Разделить крупные источники и убедиться, что звонки вообще не смешиваются в общей телефонии.
2. Версия визита. Связать нужные телефонные обращения с конкретными посещениями и сохранить идентификаторы.
3. Версия CRM. Передать исходные данные звонка в контакт и коммерческую сущность без дублей.
4. Версия качества. Добавить единые статусы, причины и ответственного за обработку.
5. Версия результата. Связать сделку с подтвержденным итогом в учетной системе.
6. Версия управления. Использовать собранные данные для одного регулярного решения по каналу, странице или обработке.

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

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

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

У каждого перехода должен быть владелец

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

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

Какие показатели нужны для контроля самой архитектуры

До оценки каналов полезно видеть здоровье данных. Для этого достаточно нескольких диагностических долей:

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

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

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