УРОК 1. Назначение и ценность модуля «Сквозная аналитика 2.0»

Сформировать у пользователя целостное понимание того, зачем нужен модуль «Сквозная аналитика 2.0», какие ограничения есть у штатной аналитики Битрикс24 и какую практическую ценность модуль даёт маркетингу, руководству и бизнесу в целом.

• отсутствие связи между Источником, Сквозным источником и UTM;
• ручные правки менеджеров;
• длинные циклы продаж;
• потеря истории источников.

Модуль формирует «единый источник правды» для маркетинга и руководства.

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

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

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

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

UTM-метки приходят извне и не контролируются CRM. Один и тот же канал может фиксироваться под разными значениями. История изменений источников не сохраняется в управляемом виде. В результате отчёты начинают расходиться с реальностью, а показатели эффективности рекламы теряют доверие.
В основе модуля лежит идея формирования единого и непротиворечивого источника данных о происхождении клиента. Для этого вводится чёткое разделение ролей между различными типами источников, система приоритетов и управляемое хранение истории касаний.

Модуль не пытается «угадать» правильный источник. Он создаёт правила, по которым данные обрабатываются одинаково и предсказуемо, независимо от изменений в CRM, рекламе или поведении пользователей.

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

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

Для руководителя модуль формирует прозрачную и устойчивую аналитику, на основе которой можно принимать управленческие решения. Цифры перестают «плавать» от правок и изменений, а отчёты начинают отражать реальную картину бизнеса.

Для CRM-администратора модуль становится инструментом наведения порядка. Он снижает количество ручных правок, позволяет контролировать изменения и предотвращает хаотичное разрастание источников.

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

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

УРОК 2. Базовые термины и логика работы

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

• Источник сущности (SOURCE_ID) – стандартное поле CRM, указывающее канал обращения (например, «Входящий звонок», «Онлайн-чат» и т.д.).
• Источник сквозной аналитики (TRACKING_SOURCE_ID) – справочник, в котором хранятся рекламные каналы (напр. «Яндекс.Директ – РК №1»). Это отдельная таблица, не привязана напрямую к CRM-полям.
• UTM-метки (UTM_SOURCE, UTM_MEDIUM, UTM_CAMPAIGN и др.) – параметры в URL рекламных ссылок, которые указывают источник и детали кампании. Модуль считывает UTM-метки, чтобы определить рекламную кампанию по клику.
• Сущность CRM – объект в Битрикс24 (Лид, Контакт, Компания, Сделка, Заказ), в котором хранятся данные о клиенте и сделке. Модуль обрабатывает изменение любой из этих сущностей.
• Дополнительные поля – например, «Источники» (CUSTOM FIELD) в карточках сущностей, куда модуль записывает результаты вычислений.

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

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

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

Источник в CRM - это стандартное поле Битрикс24, которое используется в лидах, сделках и, в зависимости от конфигурации портала, в контактах и компаниях. Его основная задача - помочь менеджеру сориентироваться в контексте клиента и корректно выстроить работу.

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

В отличие от стандартного поля, сквозной источник не предназначен для ручных правок менеджерами, используется исключительно в аналитике и напрямую связан с UTM-метками и логикой приоритетов. Он стабилен, предсказуем и одинаково трактуется во времени.
UTM_SOURCE - это внешний параметр, который передаётся в Битрикс24 из рекламных систем, ссылок, форм и виджетов. Он формируется вне CRM и полностью зависит от дисциплины маркетологов, подрядчиков и используемых инструментов.

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

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

Благодаря этому ручные правки менеджеров не ломают аналитику, изменения источников не затирают прошлые данные, а вся информация остаётся сопоставимой независимо от длительности сделки или количества взаимодействий с клиентом.

УРОК 3. Подготовка портала

Подготовить портал Битрикс24 к установке и дальнейшей настройке модуля «Сквозная аналитика 2.0», минимизировав риски потери данных, искажений аналитики и некорректной работы модуля.
Модуль «Сквозная аналитика 2.0» не является изолированным инструментом или тестовой надстройкой. Он работает непосредственно с реальными сущностями CRM и взаимодействует с уже существующими данными портала.

В процессе работы модуль:

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

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

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

Особое внимание при резервном копировании следует уделить CRM-сущностям:

• лидам;
• сделкам;
• контактам;
• компаниям;
• а также таблицам, связанным с аналитикой и источниками трафика.

Для корректной установки и настройки модуля пользователь должен обладать правами администратора портала Битрикс24.

Необходимо заранее убедиться, что:

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

До начала установки и настройки модуля крайне важно зафиксировать текущее состояние источников.

Рекомендуется:

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

Ещё до установки модуля важно определить зоны ответственности внутри команды.

Необходимо заранее зафиксировать:

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

УРОК 4. Установка модуля

Модуль устанавливается в коробочной версии Битрикс24.

1. Перейдите в Маркетплейс Битрикс24 (в веб-интерфейсе: «Приложения» → «Маркетплейс»).
2. Найдите приложение «КОСАС - Сквозная аналитика 2.0» и нажмите «Установить».
3. Ознакомьтесь с условиями и подтвердите установку.
4. После установки в левом меню портала появится пункт «Сквозная аналитика 2.0». Нажмите по нему – откроется административный раздел модуля.
5. Убедитесь, что ваша роль позволяет настраивать приложение. Для работы требуются права администратора портала и соответствующие доступы к CRM и рекламным кабинетам.

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

1. Упорядочить справочники источников и сопоставить их. Проверьте в CRM список Источник (SOURCE_ID) и список Источник сквозной аналитики. Удалите неиспользуемые записи и исправьте опечатки. Самое главное – «связать» каждый нужный источник CRM с одним источником сквозной аналитики. Подробно см. ниже (раздел «Настройка соответствия источников»).
2. Настроить использование Источника сквозной аналитики в сущностях. Здесь вы выбираете, какой именно источник сквозной аналитики будет записан в полях лида/сделки и т.д. (см. раздел «Работа с источниками в сущностях CRM»).
3. Настроить использование Источника трафика (CRM Source) в сущностях. Аналогично указывайте, из какого поля «Источник» брать данные при записи в сущности.
4. Проверка UTM-меток: найти и обработать случаи несуществующих или некорректных UTM_SOURCE. Модуль умеет сканировать сущности на такие «битые» метки (см. раздел «Несущественные UTM_SOURCE»).
5. Проверка расхождений UTM и источников: выявить сущности, у которых UTM-метка не соответствует установленному источнику (раздел «Несоответствие UTM_SOURCE…»).
6. Настройка приоритетов: определить логику выбора «главного» источника для каждой сущности (раздел «Приоритеты источников»).
7. Подключение аналитического скрипта (код отслеживания) на сайте: внести адреса доменов и скопировать JS-код. Это нужно, чтобы собирать данные о визитах и формировать мультитрековые цепочки (см. раздел «Скрипт аналитики и SEO-трафик»).
8. Восстановление исторических данных (опционально). Если ранее в вашем портале велась учётная работа с UTM или кампаниями, можно попробовать «перекачать» старые сделки и лиды. Но только после того, как настроены приоритеты, иначе можно исказить статистику.
9. Основные настройки модуля (рассмотрены ниже): задать общие параметры (деактивировать модуль до завершения настройки, выбрать источники по умолчанию, настроить автоматический импорт и т.д.).
10. Настройки периодической загрузки: указать частоту (или включить фоновую загрузку) данных из рекламных кабинетов.
11. Интеграция VK: привязать рекламный кабинет «Вконтакте» для загрузки кампаний (далее в разделе интеграций).
12. Интеграция Calltracking (динамический коллтрекинг): указать телефоны и настройки трекинга (далее).
13. Права доступа к отчётам: настроить, кто в компании может смотреть отчёты и управлять рекламными бюджетами (раздел «Права доступа»).

УРОК 5. Общая стратегия настройки

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

Корректная настройка выполняется строго в определённой последовательности:

1. Сопоставление источников
2. Проверка использования источников
3. Анализ UTM-меток
4. Настройка приоритетов
5. Подключение скриптов
6. Восстановление истории

Раздел «Основные настройки» содержит общие параметры работы всего модуля. Важные моменты:

Параметр	Описание и рекомендации
Отключить работу модуля	Этот переключатель включён по умолчанию. Вы должны провести всю первичную настройку (маппинг, приоритеты, скрипты и т.д.), а затем вручную активировать модуль. Если сразу его включить, а настройки не готовы, отчёты будут с «мусорными» данными.
Выводить только активные источники	По умолчанию показываются все сквозные источники (в т.ч. архивные) в списке настроек. Мы рекомендуем оставить этот флажок выключенным в начале работы, чтобы видеть полный список и не пропустить нужный источник.
Загружать актуальные данные (за текущий день)	Если включить, модуль будет автоматически обновлять статистику из рекламных кабинетов в фоновом режиме (не дожидаясь открытия отчёта). Удобно, но учтите, что поставщики данных (Яндекс, Google) иногда корректируют статистику задним числом (списывают/возвращают деньги). Если подключаете эту опцию, будьте готовы, что изменения могут появляться с задержкой по календарю.
Выбирать сделки по дате	Задаёт логику фильтрации в отчётах («по дате создания» или «по дате закрытия» сделки).
Администратор портала	Укажите учетную запись портального администратора. Этот пользователь будет владельцем задач и ответственных, которые модуль создаёт автоматически (например, при нехватке динамических телефонов, см. ниже).
Сквозная аналитика по умолчанию	Задайте сквозной источник, который будет проставляться, если алгоритмы не найдут других данных. Он же служит «флагом пустоты» (аналогично «Прочий трафик»). Используется для расчётов приоритетов.
Источник по умолчанию	Аналогично, укажите источник CRM, который проставляется при отсутствии данных. Стандартно в лидах при создании ставится первое значение из справочника CRM; если вы хотите иначе, измените порядок «Источников» в CRM-справочнике.
Порядок записи источников (ASC/DESC)	По умолчанию анализируется последний (самый свежий) источник обращения. Если желаете считать главным первый, поменяйте это здесь. Остальные источники при этом уйдут в таблицу «Мультаналитика».
Пауза в выполнении скрипта (сек)	Если ваш портал медленный (HDD-диски или слабый процессор), можно увеличить паузу между записями модуля. По умолчанию стоит 0 (для SSD-серверов изменений не требуется). Для порталов с большим количеством данных и низкой производительностью разумно поставить несколько секунд, чтобы портал успевал обрабатывать изменения.

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

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

Корректная настройка модуля всегда строится по принципу «от базы к деталям». Каждый следующий шаг опирается на предыдущий и не имеет смысла без него.

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

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

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

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

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

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

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

В зависимости от зрелости маркетинга и объёма накопленных данных возможны разные сценарии внедрения.

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

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

УРОК 6. Анализ использования источников

Научить пользователя осознанно анализировать, где и каким образом используются источники данных на портале Битрикс24, прежде чем вносить в них изменения. Этот этап обязателен перед любыми действиями, связанными с удалением, переименованием или объединением источников.



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

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



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

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

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

На практике чаще всего встречаются ошибки, связанные с:

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

Безопасная работа с источниками всегда строится по одному принципу:

1. Сначала анализируется фактическое использование источника.
2. Затем оценивается объём связанных данных.
3. После чего принимается решение о дальнейших действиях.
4. Только после этого выполняются изменения.
5. И обязательно проверяются отчёты.

Такой подход позволяет избежать неожиданных последствий и сохранить контроль над аналитикой на всех этапах.

УРОК 7. Сопоставление источников

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

В Битрикс24 одна и та же аудитория может приходить из одного рекламного канала, но фиксироваться в CRM под разными названиями источников и с различными UTM-метками. Это нормальная ситуация для живого портала, который развивается со временем, меняет подрядчиков, рекламные кабинеты и формы привлечения.

Без сопоставления такие данные дробятся на десятки разрозненных источников. В отчётах один и тот же канал отображается как несколько разных строк, что делает аналитику нечитаемой и не позволяет объективно оценить эффективность рекламы.

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

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

Второй уровень - это источник сквозной аналитики. Это аналитическая сущность, создаваемая и используемая модулем для расчётов, отчётов и восстановления истории. Именно на этом уровне формируется управляемая структура аналитики.

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


При сопоставлении источников необходимо придерживаться строгих логических правил.

Ключевые правила:

• Каждый реальный рекламный канал должен быть представлен одним сквозным источником аналитики.
• К одному сквозному источнику могут быть привязаны несколько источников CRM и несколько значений UTM_SOURCE.
• Недопустима ситуация, при которой один и тот же CRM-источник сопоставляется с разными сквозными источниками.

Перед началом сопоставления необходимо сформировать перечень сквозных источников аналитики. Их названия должны быть понятными, стабильными и отражать именно рекламные каналы, а не отдельные кампании, акции или временные активности.


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

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



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

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

Нажимая на ссылку “Скачать файл по источникам” вы получите файл со всеми источниками на вашем портале.

Нажимая на ссылку “Скачать файл по источникам сквозной аналитики” вы получите файл со всеми источниками на вашем портале.



Нажимая на ссылку “Сводные данные (Источник, сквозной источник, UTM)” вы получите файл со всеми данными по Источникам и Сквозным источникам, включая UTM метки и другие данные на вашем портале. Этот файл будет самым удобным для работы, т.к. в нём будет находиться исчерпывающая информация по всем справочникам на текущий момент.
Перейдите на вкладку “Импорт“ и выберите на диске ваш подготовленный файл. Нажмите кнопку “Загрузить”.

Если вы всё сделали верно, то появится таблица с сопоставительными данными. На этой странице тоже можно вносить изменения, но лучше вносить корректировки в таблице – первоисточнике.

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

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

На практике чаще всего встречаются ошибки, связанные с:

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

После завершения сопоставления необходимо убедиться, что:

• количество сквозных источников соответствует реальному числу каналов;
• в системе отсутствуют дубли;
• отчёты по источникам формируются логично и предсказуемо.

Первый и ключевой шаг – сопоставление источников CRM и источников сквозной аналитики. В административной части модуля откройте раздел «Соответствие источников». Здесь вы вручную связываете каждую запись из списка Источники (SOURCE_ID) с записью Источники сквозной аналитики (TRACKING_SOURCE_ID).

Ключевой принцип: Один источник CRM должен ссылаться на один источник сквозной аналитики; однако одному источнику сквозной аналитики могут соответствовать сразу несколько CRM-источников (например, несколько онлайн-чатов или прямых телефонов).

Пример корректного сопоставления: если у вас несколько онлайн-чатов с разными отделами, все они можно связать с единым сквозным источником «Сайт компании» (имя и домен сайта).

Источник CRM	Источник сквозной аналитики
Онлайн-чат – Конгресс центр	Сайт компании site.ru
Онлайн-чат – Кейтеринг (Банкеты)	Сайт компании site.ru
Онлайн-чат – Аренда офисов	Сайт компании site.ru
Онлайн-чат – Telegram	Сайт компании site.ru
Онлайн-чат – WhatsApp	Сайт компании site.ru

Модуль автоматически проставляет Источник сквозной аналитики и Источник CRM при создании или изменении сущностей (Лид, Контакт, Компания, Сделка, Заказ). При этом используются данные:

• UTM-метки: если в форму (или визит) клиент попал по ссылке с UTM-метками, модуль фиксирует их (поля UTM_SOURCE, UTM_MEDIUM и др.) и далее может использовать как первоисточник.
• Источник сквозной аналитики: берётся из CRM-полей или из таймлайна лидов (откуда был лид) в соответствии с приоритетами.
• Источник CRM (SOURCE_ID): при создании лида по умолчанию в поле “Источник” заносится то значение, которое стоит первым в справочнике «Источники» (по умолчанию обычно «Внешний источник» или «Прочий трафик»). Модуль позволяет перевыбрать его приоритет (см. раздел «Основные настройки»).

УРОК 8. Работа с UTM_SOURCE

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



UTM_SOURCE формируется вне Битрикс24. Он приходит из рекламных систем, ссылок, форм, email-рассылок и других внешних источников. На него влияют настройки подрядчиков, человеческий фактор, автогенерация UTM и изменения в рекламных кабинетах.

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

Модуль «Сквозная аналитика 2.0» предоставляет отдельный раздел для работы с UTM_SOURCE, задача которого - не просто показать список значений, а дать пользователю инструмент анализа и управления этим параметром.

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

На вкладке “Поиск не существующих UTM_SOURCE” позволит вам найти проблемные сущности в которых ситуация описанная выше была обнаружена.


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

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



Для удобства работы модуль предоставляет инструменты поиска и фильтрации по значениям UTM_SOURCE. Это особенно важно для порталов с большим объёмом данных, где ручной просмотр всех значений невозможен.

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

В данном окне можно выбрать тип сущности и заменить либо же удалить UTM_SOURCE сразу для всех элементов одного типа.

Работа с UTM_SOURCE напрямую связана с ранее выполненным сопоставлением источников. Только после того как UTM_SOURCE приведены к понятной и стабильной структуре, имеет смысл окончательно настраивать приоритеты источников и восстанавливать историю.

На практике чаще всего встречаются ошибки, связанные с:

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

УРОК 9. Настройка приоритетов

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

Рекомендуемый приоритет внутри сущности:
UTM → Сквозной источник → Источник → Таймлайн.

Также настраиваются приоритеты между сущностями. В разделе «Настройка приоритетов» модуля настраивается порядок проверки полей для каждой сущности. Приоритеты определяют, какой источник считать «правильным» (основным) среди имеющихся. Логика примерная:

UTM_SOURCE – если в лиде заполнена UTM-метка, модуль берёт её и считает главным источником. Далее эти данные записываются и в поле «Источник CRM», и в «Источник сквозной аналитики».

Источник сквозной аналитики (TRACKING_SOURCE_ID) – если UTM нет, следующий проверяется сквозной источник (из справочника).

Источник сущности (SOURCE_ID) – если и он отсутствует (например, лид был создан из формы без явного источника), идём к этому полю в карточке.

Источник из таймлайна – например, если лид конвертирован в контакт/компанию, может браться источник того родителя.

Телефон/email, через который пришло обращение – как крайняя мера, если нет других данных. В настройках сопоставления указываются номера телефонов, которые привязаны к конкретным сквозным источникам; если лид пришёл с этого номера, модуль привяжет указанный источник.



Данная последовательность гибкая: вы можете менять порядок пунктов, добавлять свои. Главное – помнить опцию «Перезаполнять данные в заполненных источниках» в основных настройках. Если она включена, то значения всех полей будут перезаписываться согласно приоритету. Если выключена, то существующие заполненные поля «Источник» и «Сквозная аналитика» не будут затронуты модулем, что может привести к рассогласованию с UTM (см. «Несоответствие UTM»).

Один из типовых сценариев: маркетологи часто ставят UTM_SOURCE на первое место, потому что рекламным каналам уделяется больше внимания, а технологически Битрикс24 не даёт менять UTM вручную в карточках. Это полностью оправдано – UTM отражает источник клика. Но если приоритеты выставлены так, что менеджер пытается изменить «Источник» лида вручную, модуль всё равно переопределит его значением из UTM (или предыдущей записанной цепочкой), потому что UTM «главнее» по настройке. Чтобы исправить такую ситуацию, администратор может временно передвинуть в приоритетах «Сквозной источник» выше UTM или провести массовую коррекцию через «умный сценарий».

Также приоритеты задаются между сущностями. Например, если в CRM стандартно в начале появляется лид, а позже из него конвертируются контакт/компания и сделка, то корректным источником для сделки может считаться связанный лид. Наш модуль позволяет строить цепочки приоритетов: «сначала проверяем лид, потом контакт, потом компанию и т.д.» для каждого типа сущности. Это решает классическую проблему Bitrix24, когда сделка из компании получает «Прочий трафик», несмотря на то, что лид пришёл по рекламной кампании. Механизм приоритетов «подхватывает» нужные данные из предыдущих звеньев цепочки и сохраняет правильный источник для сделки.

На старте настройте приоритеты так, чтобы UTM_SOURCE шёл первым (как правило, это оправданно).
Проверьте сценарии конвертации: создайте тестовые лиды с разными комбинациями UTM и вручную конвертируйте их, чтобы убедиться, что итоговый источник сделки соответствует ожиданиям.
При необходимости добавляйте в приоритетах правило «Сначала в своих полях, потом из связанных сущностей».

УРОК 10. Мультианалитика и восстановление истории

После подключения скрипта модуль собирает цепочку источников каждого клиента (приходил он из Яндекс.Директ, потом вернулся по прямой, потом перешёл из email-рассылки и т.д.). Все эти шаги сохраняются и выводятся на вкладке «Мультианалитика» в карточке сущности.

Чтобы посмотреть накопленную цепочку за всё время, можно сделать перенос данных в эту таблицу вручную (в разделе «Перенос данных сквозного источника в мультианалитику»). При переносе выбирается сущность (Лид/Контакт и т.д.), диапазон записей и запускается процесс. После этого все предыдущие источники попадут на вкладку «Мультианалитика» для анализа.

Восстановление истории используется для корректировки данных за прошлые периоды и выполняется только после полной настройки.

Если вы ранее вели аналитику (например, заполняли источники вручную или пользовались внешним сервисом), модуль позволяет перенести историю CRM в собственные отчёты. Процесс сложный и требует готовности портала:

1. Сделайте полную резервную копию портала (ежели что-то пойдет не так, можно будет откатиться).
2. Убедитесь, что приоритеты выставлены корректно для каждого типа сущности (см. предыдущий раздел).
3. Отключите модуль временно (в «Основных настройках»), чтобы чисто скопировать данные, не мешая работе (в разделе «Восстановление данных» модуль проверяет, что он выключен).
4. Перейдите в раздел «Восстановление исторических данных», выберите тип сущности (например, лиды) и источник, который будет назначен по умолчанию всем перепривязываемым записям. Укажите, сколько записей обрабатывать за проход – лучше брать небольшими пакетами (50–100), чтобы не перегрузить портал. Нажмите «Обновить» и дождитесь обработки. Модуль пройдёт по всем выбранным сущностям и выставит источники согласно приоритетам.
5. Если нужно прервать процесс и возобновить с места, просто обновите страницу и укажите последний обработанный ID.

 

УРОК 11. Скрипты и сбор данных

Для корректной работы необходимо:

1. установить скрипт аналитики;
2. проверить формы и виджеты;
3. убедиться в передаче источников.

Для сбора веб-аналитики на стороне сайта (особенно UTM-меток и поведения посетителей) нужно правильно подключить JS-скрипты:

1. В разделе «Настройки скрипта аналитики» административной части добавьте адреса ваших сайтов (например, site.ru) и сохраните.
2. Скопируйте предложенный модулем код «Скрипт для мультианалитики, подмены номера» и вставьте его перед закрывающим тегом </head> на все страницы сайта. Этот скрипт отслеживает UTM, заполняет скрытые поля форм и обменивается данными с коллтрекингом.
3. На странице сайта разместите код форм лидов или виджеты Битрикс24 как обычно (включая метки <input name="SOURCE"> для скрытых полей «Источник»). Для каждой формы в параметрах нужно добавить скрытое поле «Источник» (field “SOURCE”), чтобы автоматически заполнять его значением из UTM (включите «Экспертный режим» в настройках формы).

SEO-трафик: модуль позволяет разделять и учитывать трафик из поисковых систем на основе домена и URL. На вкладке «Переходы из поисковых систем» укажите, какой сквозной источник присваивать посетителям из Яндекса, Google, Bing и т.д.

Примеры настройки:

• Yandex SEO > mysite.ru > yandex > пустота – все переходы из Yandex (любой домен, например yandex.ru) будут относиться к источнику «Yandex SEO».
• Yandex SEO > mysite.ru/page1/* > yandex > пустота – если нужно выделить SEO-трафик на конкретный раздел, используйте /* (вышестоящий раздел и всё, что внутри).

УРОК 12. SEO и прямые переходы

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



В отличие от платного трафика, SEO и прямые переходы не всегда содержат UTM-метки. Источник таких визитов определяется косвенно - по рефереру, домену, браузеру или отсутствию параметров перехода.




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

Модуль «Сквозная аналитика 2.0» использует список поисковых систем и правила определения органического трафика для корректной классификации входящих визитов.

Если переход осуществляется с домена поисковой системы и не содержит рекламных UTM-меток, он относится к SEO-источнику. При этом модуль позволяет не просто учитывать SEO как единый канал, а разделять его по конкретным поисковым системам, что особенно важно для оценки вклада разных каналов органического трафика.

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

Модуль позволяет учитывать прямые переходы как отдельный источник аналитики, не смешивая их с SEO или рекламными каналами. Это даёт более честную картину поведения аудитории и позволяет отслеживать влияние бренда и узнаваемости.

Ключевая задача этого раздел - чётко разделить органический трафик и прямые заходы, исключив их пересечения. Модуль позволяет задать правила, по которым визиты классифицируются в зависимости от наличия реферера, домена поисковой системы и UTM-параметров.

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

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

УРОК 13. Динамический коллтрекинг

Настраиваются:

• время жизни номера;
• источники;
• резервные номера.

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

Список источников, для которых будет отрабатывать коллтрекинг – отметьте те сквозные источники (рекламные каналы), в рамках которых будет выделяться динамический номер. Обычно это все источники, связанные с телефонией (Яндекс.Директ, VK, статические интернет-номера и т.д.).

Время хранения телефона для пользователя (секунд) – на каждого нового посетителя сайт выдаёт персональный номер из общего пула. Этот номер «закрепляется» за посетителем на указанное время (таймаут сессии). Если выставить слишком маленькое значение, тот же пользователь может получить несколько разных номеров за сессию; слишком большое значение потребует огромного пула номеров. Опирайтесь на среднюю длительность сессии в вашей нише (можно смотреть Яндекс.Метрику). Настройте это с осторожностью – слишком маленькая сессия увеличит расход, слишком большая заставит модуль зарезервировать много номеров.

Время хранения незавершенной статистики по UTM меткам – задаёт, сколько сохранять «висящие» UTM-заходы, если пользователь ушёл со страницы до окончания сессии. Не устанавливайте слишком большое время, чтобы не раздувать БД (особенно на высоконагруженных сайтах).

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

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

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

Как работает в итоге: при звонке система записывает номер, по звонку создаётся лид, модуль смотрит, какой номер выпал и по базе сверяет – этот номер привязан, например, к сквозному источнику «Яндекс.Директ - РК 123». Тогда лиду ставится этот источник и заполняются все поля; в «Окупаемость рекламы» сделка по этому лиду попадёт в статистику Яндекс.Директа.

УРОК 14. Права доступа и отчёты

Модуль поддерживает разграничение прав доступа и формирование отчётов по окупаемости рекламы и мультиканальной аналитике.

В разделе «Настройки прав для отчётов» настраиваются, какие пользователи могут видеть отчёты модуля и управлять рекламными данными. Часто в крупных компаниях администратору достаточно одного пользователя для администрирования источников и рекламных подключений, а остальные сотрудники (маркетологи, руководители) получают доступ только к чтению отчётов «Окупаемость рекламы» и «Мультиканальная аналитика».


Особенность нашей доработки отчётов: мы изменили стандартный отчёт «Окупаемость рекламы» так, чтобы использовать внутренние таблицы с выгруженными данными из рекламных кабинетов. Благодаря этому загрузка отчёта стала очень быстрой. Также отчёт может группировать данные по отделам и департаментам: для этого в названиях источников и кампаний рекомендуется указывать префикс «DEP|» или подобные (например, «DEP1 | Яндекс Директ»), и модуль разнесёт данные по этим департаментам.

УРОК 15. Интеграции

Поддерживаются интеграции с:

• Яндекс Метрикой;
• VK;
• MyTarget.

Интеграции позволяют автоматически получать расходы и источники. Приложение «Сквозная аналитика 2.0» принципиально отличается от штатной аналитики Битрикс24 и сторонних сервисов:

Преимущество	Описание
Восстановление связей и истории	в Битрикс24 и у внешних сервисов при последовательных конверсиях (лид → контакт → сделка) источники часто теряются. Например, лид пришёл от рекламной кампании, но пока не было сделки, сервис увидит только «обращение» и не знает о деньгах. После получения сделки через полгода, внешняя аналитика покажет доходы без источника, а наш модуль «припишет» продажу к оригинальному рекламному источнику.
Учет всех каналов (мультиканальность)	ни один внешний сервис не показывает всю цепочку переходов клиента на сайте. В нашей «Мультианалитике» видны все каналы (по которому пользователь перешёл на сайт, а потом вернулся и т.д.). Это важно для комплексной оценки путей клиента.
Гибкость приоритетов	внешние сервисы обычно фиксируют только первый или последний известный канал (и никак не учитывают промежуточные). Мы даём возможность настраивать, что считать основным («первый или последний»), а остальные каналы сохраняем в мультитреке.
Динамический номер	в отличие от многих сервисов (например, Roistat), мы можем настраивать «время жизни» динамического номера. Если у вас долгий цикл продаж, вы можете увеличить время закрепления номера, чтобы не потерять источник.
История в БД портала	наше решение – обычный модуль Битрикс24. Все данные сохраняются в базе портала. Это значит, что если вы в будущем перестанете оплачивать сервис или решите перейти на другой тариф, данные не потеряются. Внешние сервисы хранят информацию у себя: при окончании подписки они могут просто выключить доступ и вы потеряете старые цифры. Мы храним всё прямо у вас.
Отсутствие проблем с REST-токенами	внешние аналитические приложения подключаются через REST к Битрикс24 и иногда их токены «слетают» при большой нагрузке – отчёты перестают обновляться, а вы об этом даже не узнаёте. Наше приложение работает внутри портала без дополнительных внешных соединений, поэтому таких проблем не бывает.
Выявление коллизий и ошибок	сторонние сервисы не умеют находить логические ошибки в данных. Наш модуль, например, умеет находить в CRM лиды с несуществующими UTM-метками или с несовпадением UTM и источника. Также он «ставит задачу» при нехватке динамических телефонов и имеет встроенную логику по умолчанию, чего нет в простых решениях.

  В целом, «Сквозная аналитика 2.0» - это глубоко настраиваемый инструмент для маркетологов. В дополнение к перечисленному модуль содержит два основных отчёта – «Окупаемость рекламы» (ROI) и «Мультиканальная аналитика» (цепочки переходов). В отчёте «Окупаемость рекламы» есть расширенные фильтры по источникам и UTM-меткам (поиск по части названия, выбор нескольких меток через запятую). Для рекламных источников, подключённых к кабинетам (Я.Директ, VK, MyTarget и т.д.), появляются кнопки «+» для перехода в статистику по кампаниям и объявлениям. Отчёт «Мультиканальная аналитика» показывает цепочки источников для каждого лида.

ВКонтакте. Для детальной аналитики по рекламным кампаниям VK у модуля реализована собственная интеграция. В административной части в разделе «Настройки рекламных кабинетов» можно подключить кабинет VK (используется стандартный OAuth VK из «Сквозной аналитики» Битрикс24) и загрузить список рекламных кампаний. Затем в настройках источников для канала «Вконтакте» выберите сквозной источник, который будет проставляться лидам из этой соцсети. Также есть кнопка «Обновить кампании»: если вы внесли изменения в объявления или кампании в кабинете VK, нажмите её, чтобы изменения подтянулись в отчёты.



MyTarget (Mail.Ru). Новый рекламный канал «MyTarget» объединяет сервисы Mail.Ru (VK, Одноклассники, Mail.ru и др.). Мы сделали отдельную интеграцию с MyTarget. Введите Client ID и секретный код вашего приложения MyTarget (инструкции для получения – на официальном сайте target.my.com). После подключения модуль будет загружать статистику MyTarget и отображать её в отчёте «Окупаемость рекламы» с разбивка до конкретного объявления и ключевого слова. Как и в случае VK, нужно в источниках указать, какой сквозной источник соответствует MyTarget: обычно это «MyTarget – Объявления».



Пример настройки: в разделе «Настройки рекламных кабинетов» выберите «Настройки MyTarget», введите учётные данные API (Client ID и Secret), подтвердите загрузку кампаний. В списке источников укажите, что все лиды из MyTarget будут иметь Сквозной источник «MyTarget – РК». Это позволит модулю автоматически проставлять его при создании лида с этой платформы.



 Если вы хотите дополнительно получать статистику визитов из Яндекс.Метрики, можно подключить метрику к модулю (выгрузка аналитики в Битрикс24). Для этого в разделе «Настройки рекламных кабинетов» выберите «Настройки Яндекс Метрики» и следуйте инструкциям:

1. Заведите новое приложение в OAuth-панели Яндекса (PDD) – тип веб-сервис, redirect URI https://oauth.yandex.ru/verification_code .
2. При создании выберите права metrika:read (чтение статистики) и metrika:write (изменение собственных счетчиков).
3. Скопируйте ClientID приложения и вставьте в специальную ссылку: https://oauth.yandex.ru/authorize?response_type=token&client_id= . При переходе по ней вы получите токен доступа.
4. Введите в настройках метрики ID вашего счётчика (номер, присвоенный Метрикой сайту).

После этого модуль сможет автоматически подтягивать данные: число визитов, источники переходов, цели. В отчёте «Окупаемость рекламы» появится новая колонка «Метрика», показывающая метрику ключевого показателя (например, глубину просмотра).

УРОК 16. Отличия от штатной аналитики

Показать принципиальные отличия модуля «Сквозная аналитика 2.0» от штатных инструментов аналитики Битрикс24 и объяснить, в каких задачах стандартных возможностей системы недостаточно.



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

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

Кроме того, штатная аналитика плохо справляется с мультиканальными сценариями, когда клиент взаимодействует с несколькими источниками до совершения целевого действия. Одно из ключевых отличий модуля «Сквозная аналитика 2.0» - сохранение и управление историей данных. Модуль позволяет фиксировать и восстанавливать историю с учётом актуальной логики источников, а не пересчитывать данные автоматически и неконтролируемо.

Штатные инструменты Битрикс24 в основном ориентированы на упрощённую модель атрибуции и не позволяют гибко учитывать несколько касаний клиента с разными каналами.

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

Из-за отсутствия единой логики источников, нестабильной работы с UTM и пересчётов истории штатная аналитика часто даёт искажённую картину. Цифры могут выглядеть корректно формально, но не соответствовать реальности.

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

Именно в этих сценариях модуль «Сквозная аналитика 2.0» раскрывает свою основную ценность.

УРОК 17. Практические рекомендации

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

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

UTM-метки - самый нестабильный элемент аналитики, так как формируются вне CRM. Их корректность напрямую зависит от дисциплины маркетологов, подрядчиков и рекламных систем.

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

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

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

При работе с модулем «Сквозная аналитика 2.0» важно понимать границу ответственности между системой и пользователем.

Модуль не перекладывает аналитику полностью на пользователя, но и не устраняет последствия хаотичных действий автоматически. Он:

• ограничивает опасные сценарии;
• фиксирует историю;
• задаёт жёсткую логику обработки данных.

Однако решения о структуре источников, логике UTM, моменте изменений - принимает пользователь.

Курс описывает рекомендуемую и логически правильную последовательность настройки.

Не все рекомендации равнозначны.

Критически обязательные:

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

Желательные:

• ведение документа изменений;
• проверка отчётов после каждого этапа;
• ограничение прав на изменение источников.