Битрикс24 и аналитика данных: BI Конструктор, Power BI и внешнее хранилище

Обновлено 3 сентября 2026 года.

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

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

Сначала определите, какой вопрос решает отчёт

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

Четыре способа построить аналитику

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

Что умеет BI Конструктор сейчас

BI Конструктор основан на Apache Superset. Он позволяет работать с готовыми отчётами и создавать свои. Для коробочной версии официальная справка указывает модуль biconnector версии 24.900.0 или выше. Возможность работы в облаке определяется актуальным тарифом; это уже не функция, которую «только ожидают».

Собственный отчёт создают из раздела BI Конструктор Битрикс24. При редактировании системного отчёта создаётся копия. Такой порядок позволяет сохранить исходный вариант и адаптировать графики. Инструкция: создание отчётов.

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

В интерфейсе SQL Lab используется подключение trino. Сам Trino — распределённый движок SQL-запросов, а не самостоятельная OLAP-база для постоянного хранения всех данных. Поэтому схема «Trino хранит CRM, Superset её показывает» без описания реальных источников некорректна.

Какие данные доступны

В актуальном каталоге наборов есть не только лиды и сделки. Для выбора полезны следующие примеры:

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

BI Конструктор также поддерживает внешние данные. В каталоге описаны CSV, рекламные источники и данные 1С. Подключение расходов Яндекс.Директа и VK и наборы tracking_source / tracking_source_expenses разобраны в отдельной инструкции. Поэтому утверждение, что штатная аналитика «ничего не знает о рекламных расходах», неверно.

Лимиты и актуальность отчёта

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

По обновлённой логике лимитов, описанной в августе 2026 года, при превышении блокируется конкретный запрос, а не работа BI Конструктора целиком. Для старых отчётов Power BI требуется обновить код загрузки из актуального шаблона. Не подставляйте случайную функцию из давней статьи: перенесите код нужного запроса из текущего шаблона Битрикс24.

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

Когда достаточно внешнего Power BI без собственного хранилища

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

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

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

Когда оправдано отдельное хранилище

Оно полезно, если требуется фиксировать состояния воронки на прошлые даты, соединять несколько порталов и учётных систем, выдавать аналитикам контролируемый SQL-доступ или обслуживать несколько BI-продуктов через общие витрины. Ещё один повод — необходимость воспроизводить расчёт на сохранённой версии данных.

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

Размещение копии данных снижает повторные аналитические запросы к порталу, но получение этой копии всё равно расходует ресурсы источника. Внешний коннектор не отменяет права, ограничения REST или BI API и требования подписки. Условия для облака ru и коробки различаются; они разобраны в обзоре Маркетплейса и интеграций.

Синхронизация и история

1. Первичная загрузка. Зафиксируйте набор сущностей, поля, временной диапазон и контрольные количества.
2. Обновления. Повторно получайте изменившиеся записи, а не только новые. Используйте устойчивую контрольную точку и обработку повторов.
3. Удаления и пропуски. Определите, как обнаруживаются исчезнувшие объекты, потерянные события и временная недоступность API.
4. Версии. Если нужна история, храните её отдельно от текущего состояния. Обычный UPDATE по идентификатору заменяет значение и не сохраняет прошлое.
5. Сверка. Периодически сравнивайте количество и суммы с источником за одинаковые периоды и фильтры.

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

Для нескольких порталов используйте ключ вида «портал + тип сущности + ID». Сделка с ID 42 в двух разных порталах — две разные записи. Идентификаторы должны сохраняться и при передаче в учётную систему, иначе сопоставление по названию клиента даст неоднозначные связи.

Пример ошибки: сделки, товары и оплаты

Учебный набор: одна сделка на 100 000 ₽, две товарные строки на 40 000 и 60 000 ₽, два платежа на 20 000 и 40 000 ₽. Если соединить все три набора по ID сделки, получится четыре комбинации: каждый товар с каждым платежом.

Решение зависит от вопроса отчёта: сохранить отдельные таблицы фактов с корректными связями либо предварительно агрегировать товары и платежи до одной строки на сделку. Нельзя исправлять проблему случайным DISTINCT по сумме: у разных реальных объектов могут совпадать суммы.

Платежи в примере составляют 60 000 ₽, хотя сделка записана на 100 000 ₽. Это разные показатели. Для прибыли дополнительно нужны правила признания выручки и затрат; стадия «выиграна» сама по себе не рассчитывает P&L. Подробнее о связях — в руководстве по структуре данных Битрикс24, о маркетинговых показателях — в материале по сквозной аналитике.

Права доступа к отчётам и выгруженным данным

В BI Конструкторе настраиваются роли и действия с группами отчётов: просмотр, создание, изменение и другие операции. Справка описывает эти права отдельно. Возможность открыть раздел, право редактировать отчёт и ограничение строк — разные уровни настройки.

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

При выгрузке в PostgreSQL, MySQL или другую базу права CRM не переносятся автоматически. У копии должны быть собственные роли, правила хранения и резервного копирования. Публичная ссылка на отчёт не подходит для конфиденциальных данных. Доступ к источнику, к модели и к опубликованному отчёту проверяется отдельно.

Какие задачи закрывают приложения BI Data и Media Targeting

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

Текущая карточка BI Data содержит версию 7 от 29 июня 2026 года с поддержкой MS SQL и исправлениями REST-выгрузки. Это сведения о версии приложения. Они не подтверждают бесконечный объём, мгновенные отчёты, полную резервную копию портала или гарантированный прирост продаж.

Как принять готовую аналитику

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

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