KPI продаж из коробочного Битрикс24: Power BI, DataLens и Superset

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

Для аналитики продаж из коробочного Битрикс24 можно использовать штатные наборы BI, REST API или отдельную витрину данных. Выбор зависит от состава показателей, истории изменений, ограничений доступа и допустимой нагрузки на портал.

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

BI-аналитика, BI Конструктор и собственный Superset

Штатный BI-коннектор Битрикс24 и сторонние продукты для выгрузки, включая BI Data Connector, — отдельные решения. Их возможности, лицензии и способы подключения нужно оценивать раздельно.

Что изменилось в коробочной версии

Официальная справка указывает для BI Конструктора модуль biconnector версии 24.900.0 или выше. Это минимальное условие из инструкции, а не обещание наличия всех функций новых выпусков в любой старой установке. Доступность инструмента проверяют по конкретной редакции и установленным обновлениям; переносить названия облачных тарифов на редакции коробки неверно.

В журнале версий biconnector отдельно отмечены:

• 26.600.0 от 22 мая 2026 года — добавлен локальный режим BI Конструктора;
• 26.800.0 от 15 июля 2026 года — добавлена поддержка PostgreSQL;
• 26.1000.0 от 3 августа 2026 года — автоматические повторные попытки восстановления запуска.

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

PostgreSQL как рабочая СУБД самого Битрикс24 связан с редакцией Enterprise и поддерживаемыми версиями продукта; это указано в технических требованиях. Внешняя аналитическая PostgreSQL-витрина — другой сценарий: она не требует менять СУБД рабочего портала.

Как выбрать способ выгрузки

Штатные наборы BI

Начните с каталога наборов и проверьте конкретные поля. Для продаж полезны crm_deal, crm_deal_uf, crm_deal_stage_history и crm_deal_product_row. Лиды, их пользовательские поля и история представлены собственными наборами. Наличие сущности в CRM не означает, что любой её атрибут доступен выбранным способом выгрузки.

Лимиты зависят от условий продукта и считаются по источникам. Например, несколько наборов в одном отчёте не превращаются автоматически в одну общую квоту строк. Уточните действующее значение в портале и справке вместо использования старой таблицы «Базовый — 10 000, Профессиональный — 100 000» для всех установок.

Согласно описанию новой логики лимитов, при превышении блокируется конкретный запрос, а BI Конструктор продолжает работу. Для Power BI нужно перенести код загрузки из актуального шаблона в рабочий отчёт. Готовые имена функций из старой статьи не заменяют проверку своего шаблона.

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

REST API

REST подходит для регулярной выгрузки и собственной обработки. Используйте документированные методы, пагинацию и права интеграции. Например, crm.item.list возвращает элементы выбранного типа; набор полей и продолжение страницы нужно обрабатывать явно.

Для истории стадий есть crm.stagehistory.list. В запросе используется entityTypeId, например 2 для сделок, и фильтр OWNER_ID для конкретного объекта. В документированном примере выбираются ID, STAGE_ID и CREATED_TIME. Это не параметр ENTITY со строкой «сделка», а записи истории не следует без проверки считать готовыми парами «старая стадия — новая стадия».

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

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

Чтение физической базы

В коробочной версии возможен контролируемый доступ к СУБД. Такой путь требует знания схемы установленной версии и бизнес-смысла полей. Таблицы b_crm_* нельзя считать точной копией наборов BI или ответа REST. Историю и множественные связи нужно проверять по реальной схеме.

Для аналитики обычно выделяют пользователя с необходимыми правами чтения и ограничивают сетевой доступ. Тяжёлые запросы целесообразно проверять на отдельной реплике или витрине. SELECT не изменяет строки, но способен занять память, процессор, I/O и время; права чтения сами по себе не защищают портал от перегрузки.

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

Экспорт CSV или Excel

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

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

Подключение Power BI

1. Откройте BI-аналитику своего портала и данные для подключения Microsoft Power BI.
2. Получите актуальный шаблон из предусмотренного для вашей установки источника. Условия его установки могут зависеть от подписки и способа распространения.
3. Откройте шаблон в Power BI Desktop, укажите параметры портала и секретный ключ. Для нужного смарт-процесса задайте его тип, если шаблон это предусматривает.
4. Ограничьте стартовый период на этапе загрузки, проверьте число строк, поля и контрольные сделки.
5. Настройте обновление и права на отчёт в выбранном способе размещения.

Порядок работы описан в инструкции подключения Power BI. Параметры копируйте из портала и своего шаблона: не подменяйте их произвольным URL, OData-адресом или универсальной функцией из другого примера.

При использовании отдельной PostgreSQL-витрины доступен штатный PostgreSQL-коннектор Power Query с Import и DirectQuery. У MySQL-коннектора другие возможности. Режим получения данных не следует выбирать по аналогии между разными СУБД.

Разработка в Desktop, публикация в Power BI Service и локальное размещение отчётов имеют разные условия доступа, лицензирования и обновления. Для данных внутри сети может понадобиться шлюз. Бесплатный Desktop сам по себе не предоставляет коллективный веб-доступ к отчёту.

Подключение Yandex DataLens

В текущей инструкции DataLens Битрикс24 находится в разделе партнёрских подключений. Порядок следующий:

1. Создайте подключение Битрикс24 в DataLens.
2. Укажите портал в требуемом формате и токен из BI-аналитики Битрикс24, вкладка Yandex DataLens.
3. Оставьте включённым автоматическое создание дашборда, чартов и датасетов, если нужны стандартные примеры.
4. Проверьте подключение, выберите воркбук и сохраните его под понятным именем.
5. Сверьте стандартные показатели и только затем расширяйте отчёт дополнительными наборами.

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

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

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

BI Конструктор и внешний Superset

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

BI Конструктор не ограничен только внутренними CRM-наборами. Актуальная инструкция внешних MySQL и PostgreSQL описывает подключение таких баз. В коробке параметры базы указывают напрямую; отдельное серверное приложение из облачной инструкции не требуется. Сервер Битрикс24 должен иметь сетевой доступ и необходимые права чтения.

Самостоятельный Apache Superset имеет собственные подключения и эксплуатацию. Ему нужен поддерживаемый драйвер и источник данных; произвольный JSON REST API не становится SQL-датасетом только от указания URL. Обычно данные сначала загружают в базу либо используют подходящий специализированный интерфейс.

У Superset нет языка DAX Power BI. Меры и контекст расчёта при переносе нужно воспроизвести в SQL и семантическом слое, а затем проверить на тех же фильтрах. Встроенный BI Конструктор также не следует считать любой текущей версией открытого Superset: это продуктовая интеграция со своим набором функций.

Согласуйте KPI продаж

По описанию наборов сделок, CLOSEDATE — планируемая дата закрытия. В crm_deal_stage_history DATE_CREATE отражает дату записи и перехода на стадию; START_DATE и END_DATE связаны с датами сделки. Использовать их разность как готовую длительность каждого этапа нельзя.

Коды стадий отличаются по воронкам. Для группировки исходов используйте их семантику и справочник выбранного интерфейса. Физический JOIN только с ENTITY_ID = ‘DEAL_STAGE’ не является универсальным решением для всех направлений.

Пример расчёта времени на стадии

Следующий SQL для PostgreSQL работает только с учебными событиями. Названия QUALIFY, PROPOSAL, WON и LOST придуманы для примера; их нужно сопоставить со стадиями реальной CRM. Время — календарное, момент наблюдения фиксирован.

WITH cutoff AS (
  SELECT TIMESTAMPTZ '2026-08-06 10:00+03' AS as_of
), events(event_id, deal_id, stage, occurred_at) AS (
  VALUES
    (1, 1, 'QUALIFY', TIMESTAMPTZ '2026-08-01 10:00+03'),
    (2, 1, 'PROPOSAL', TIMESTAMPTZ '2026-08-02 10:00+03'),
    (3, 1, 'QUALIFY', TIMESTAMPTZ '2026-08-03 10:00+03'),
    (4, 1, 'WON', TIMESTAMPTZ '2026-08-04 10:00+03'),
    (5, 2, 'QUALIFY', TIMESTAMPTZ '2026-08-02 10:00+03'),
    (6, 2, 'LOST', TIMESTAMPTZ '2026-08-03 10:00+03'),
    (7, 3, 'WON', TIMESTAMPTZ '2026-08-04 10:00+03'),
    (8, 4, 'QUALIFY', TIMESTAMPTZ '2026-08-04 10:00+03'),
    (9, 5, 'QUALIFY', TIMESTAMPTZ '2026-08-07 10:00+03')
), ordered AS (
  SELECT e.*,
         LEAD(occurred_at) OVER (
           PARTITION BY deal_id ORDER BY occurred_at, event_id
         ) AS next_at
  FROM events e CROSS JOIN cutoff c
  WHERE e.occurred_at <= c.as_of
)
SELECT deal_id,
       ROUND(SUM(EXTRACT(EPOCH FROM
         (COALESCE(next_at, c.as_of) - occurred_at)) / 3600)::numeric, 2)
         AS qualify_hours,
       BOOL_OR(next_at IS NULL) AS has_open_interval
FROM ordered CROSS JOIN cutoff c
WHERE stage = 'QUALIFY'
GROUP BY deal_id
ORDER BY deal_id;

Результат: сделка 1 провела на QUALIFY суммарно 48 часов за два посещения стадии; сделка 2 — 24 часа; сделка 4 — 48 часов к моменту наблюдения и всё ещё находится на стадии. Сделка 3 не проходила QUALIFY, а будущее событие сделки 5 исключено.

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

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

Пример корректной конверсии этапа

В этих учебных данных до даты наблюдения QUALIFY достигли сделки 1, 2 и 4. После него успешно завершилась только сделка 1: наблюдаемая конверсия — 1 / 3, или 33,33%. Сделка 3 выиграна, но не входила в эту когорту, поэтому её нельзя добавить в числитель. Сделка 4 ещё открыта, и результат когорты может измениться.

Отдельно можно посчитать долю успехов среди уже завершённых сделок этой когорты: 1 / 2 = 50%. Это другой показатель с другим знаменателем. Названия и правила расчёта должны позволять читателю различать их.

История ответственности и отделов

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

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

Поля наборов BI, связи пользователей и REST-методы проверяйте по документации своей версии. Не стоит придумывать универсальную таблицу b_department или рассчитывать на недокументированный ADMIN_MODE для получения всей структуры.

Проверьте свежесть, права и суммы

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

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

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

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