Сквозная аналитика в Битрикс24: схема внедрения без потери источников

01

Что именно считает сквозная аналитика в Битрикс24

Сквозная аналитика не является одним виджетом в CRM. Это связанная цепочка данных: рекламное объявление или органический переход, визит на сайт, обращение, лид либо сделка, этап продаж, счёт или оплата. Руководителю она нужна не для красивой диаграммы, а для ответа на конкретный вопрос: какой канал принёс оплаченные заказы и с какой экономикой.

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

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

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

03

Спроектируйте маршрут данных до настройки сервисов

Начните не с подключения рекламных кабинетов, а с карты событий. Для каждого способа обращения укажите точку входа, кто создаёт сущность CRM, какие поля передаются и где возникает сумма продажи. Минимальный набор каналов: формы сайта, динамический номер или callback, чат, email, ручное создание менеджером и импорт заказов интернет-магазина. Ручной канал тоже нужен: иначе часть выручки окажется без причины появления.

На стороне сайта фиксируйте исходный URL, реферер, UTM первого визита, UTM текущего визита, дату первого визита и идентификатор браузера. Не заменяйте первое касание текущими метками при каждом повторном визите. В форме передавайте их скрытыми полями вместе с техническим идентификатором отправки. Если используется штатная CRM-форма, проверьте, какие поля она создаёт и какие не умеет заполнять без доработки.

В Битрикс24 создайте отдельные пользовательские поля, а не пытайтесь складывать всю строку запроса в комментарий. Например: «Источник первого обращения», «Канал первого обращения», «Кампания первого обращения», «Источник последнего обращения», «Client ID», «Дата первого визита». Для лида и сделки заранее определите наследование значений. Описание создания и типов пользовательских полей есть в справке Битрикс24.

04

Какие поля и правила нужны в CRM

Стандартное поле «Источник» удобно для верхнеуровневой классификации, но его редко хватает для анализа рекламных расходов. Кампания, объявление, поисковая фраза и идентификатор визита должны жить в отдельных полях. Тогда маркетолог строит срез по кампаниям, а разработчик не разбирает строку из комментария регулярными выражениями. Тип полей выбирайте по задаче: строки — для UTM, список — для нормализованного канала, дата-время — для первого обращения, число — для рекламных расходов при простых моделях.

Заранее настройте обязательность полей только там, где их вводит сотрудник. Нельзя требовать UTM у менеджера при ручном создании лида: он начнёт выбирать случайные значения. Для ручного обращения добавьте список «Источник обращения» с вариантом «Ручной ввод» и обязательное поле «Причина отсутствия трекинга». Это сохранит честность данных.

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

05

Свяжите сайт, телефонию и рекламу с одной воронкой

Форма сайта должна создавать лид или сделку предсказуемым способом. В задаче зафиксируйте обработчик: CRM-форма, вебхук, REST API или промежуточный сервис. Для нестандартных форм лучше передавать данные через серверную часть сайта: так можно валидировать поля, записать журнал ошибки и не раскрывать входящий URL вебхука в браузере. Обязательно передавайте внешний идентификатор отправки, чтобы повторная отправка не создала дубль без отметки.

Звонки требуют отдельной проверки. Коллтрекинг должен передать в CRM номер подмены, дату, длительность, статус звонка и сессию визита. Если звонок создаёт отдельный лид без UTM, отчёт не свяжет его с рекламой. Сверьте правила создания лида при пропущенном, коротком и повторном звонке: эти события могут учитываться в маркетинговой статистике по-разному.

Расходы из рекламных систем можно загружать в BI или в отдельную таблицу по дате, источнику и кампании. Не пытайтесь хранить дневные расходы в карточке сделки: это не позволит корректно пересчитать CPL и ROMI. Для аналитики в CRM особенно важно единое написание utm_source и utm_medium: «Yandex», «yandex_direct» и «yandex» станут тремя разными строками отчёта.

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

06

Порядок внедрения: от аудита к первому отчёту

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

На этапе аудита выгрузите 20–30 свежих лидов и сделок разных типов. Проверьте заполненность источника, наличие дублей, разницу между датой лида и датой сделки, использование воронок и причины отказов. Одновременно посмотрите цели веб-аналитики: отправка формы не должна считаться подтверждённой заявкой, если API CRM вернул ошибку.

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

1. 1

   Зафиксируйте модель продажи. Определите сущность, этап и дату, по которым сделка считается выручкой.

2. 2

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

3. 3

   Утвердите справочник UTM. Задайте допустимые source и medium, правила именования кампаний и владельца изменений.

4. 4

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

5. 5

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

6. 6

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

07

Как принять работу и не получить отчёт с красивыми, но неверными цифрами

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

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

Для контроля качества полезны ежедневные сигналы: доля сделок без источника, доля «прочих» каналов, число дублей и расхождение между количеством CRM-лидов и подтверждённых отправок формы. Установите допустимый порог и владельца реакции. Например, 5% сделок без источника — не повод править отчёт вручную, а повод открыть задачу на диагностику канала.

08

Типовые ошибки в отчётах по рекламе и продажам

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

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

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

09

Когда схема готова к управленческим решениям

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

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

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