BI-аналитика Битрикс24: первый отчёт из CRM
Собираем в BI Конструкторе отчёт по созданным сделкам и текущим ответственным: от выбора данных до сверки результата с CRM.
В этой инструкции результатом станет небольшая таблица, которую можно объяснить: у кого сейчас находятся сделки, созданные за выбранную неделю или месяц, и из каких записей складывается каждое число. Это удобная первая задача для руководителя или сотрудника, который осваивает BI Конструктор.
Если нужно сначала разобраться в самом подходе, прочитайте объяснение BI-аналитики простыми словами. Здесь сразу переходим к настройке в Битрикс24. Инструкция сверена с официальной справкой; расположение и названия отдельных элементов могут зависеть от версии интерфейса вашего портала.
Определите, что должен показывать первый отчёт
Запишите вопрос целиком: «Сколько сделок создано за выбранный период и кто отвечает за них сейчас?» Оставьте в выборке все стадии. Если отобрать только успешные сделки, получится уже другой показатель — число созданных за период сделок, которые к моменту просмотра стали успешными.
Зафиксируйте одну воронку либо договоритесь считать все. Выберите неделю или месяц, где есть знакомые записи: на таком периоде проще проверить результат. Заголовок будущей таблицы должен отражать эти условия, например «Созданные сделки по текущим ответственным».
Учитывайте слово «текущим». Передача сделки другому сотруднику изменит распределение после обновления данных. Этот отчёт не отвечает на вопрос, кто создал запись или вёл её месяц назад. Не используйте его для оценки исторического вклада менеджеров без отдельного правила расчёта.
Проверьте доступ к BI Конструктору
Убедитесь, что инструмент доступен на тарифе вашего портала и вам разрешены создание и редактирование отчётов в нужной группе. Если раздел или действие не видно, попросите администратора проверить доступность функции и вашу роль. Для просмотра отчёта и для его изменения могут требоваться разные права.
Не покупайте внешний коннектор только ради этого примера: в штатном BI Конструкторе используются наборы данных Битрикс24. Внешняя BI-система — другой вариант реализации, который стоит выбирать под конкретные источники и требования, а не для повторения одного графика.
Правила доступа описаны в официальной инструкции по ролям и группам отчётов.
Создайте отчёт и выберите данные сделок
В разделе «BI Конструктор» внутри Битрикс24 нажмите «Создать» и задайте название отчёта. Другой стартовый вариант — сделать копию подходящего стандартного отчёта. Для этой инструкции проще отдельный небольшой отчёт: чужие графики и фильтры не будут мешать сверке.
Откройте редактор кнопкой «BI Конструктор». В нём есть вкладка Dashboards, но новый отчёт следует создавать из Битрикс24: официальная справка предупреждает, что созданным напрямую во вкладке Dashboards отчётом нельзя будет работать в Битрикс24.
Перейдите в Charts → «+ График», выберите датасет crm_deal и тип «Таблица». Если набора нет в списке, добавьте его через Datasets → «+ Датасет»: база trino, схема bitrix24, таблица crm_deal. Создайте датасет и перейдите к графику.
Для первой версии не присоединяйте товары и историю стадий. У одной сделки может быть несколько товарных строк или переходов; после соединения число строк перестаёт быть числом сделок. Сначала получите проверенный итог на одном наборе, затем усложняйте модель.
Настройте таблицу: ответственный и число уникальных сделок
Выберите режим «Агрегация», чтобы получить одну строку на ответственного, а не список отдельных сделок. В группировку добавьте ASSIGNED_BY — поле с идентификатором и именем сотрудника. Группировка только по имени может объединить разных людей с одинаковыми именами.
Добавьте меру для поля ID с подсчётом уникальных значений — COUNT_DISTINCT(ID). Если редактор меры предлагает SQL-выражение, тот же расчёт записывается как COUNT(DISTINCT ID). Подпишите столбец «Созданные сделки» и отсортируйте строки по этому числу по убыванию.
| Настройка | Поле или мера | Смысл |
|---|---|---|
| Источник | crm_deal | Один набор сделок, без присоединения товаров и истории стадий |
| Единица подсчёта | ID | Одна уникальная сделка |
| Дата отбора | DATE_CREATE | Когда сделка создана, независимо от её нынешней стадии |
| Группировка | ASSIGNED_BY | Текущий ответственный: идентификатор и имя |
| Мера | COUNT_DISTINCT(ID) | Количество уникальных сделок в каждой группе |
| Воронка | CATEGORY | Одна согласованная воронка или все — одинаково в BI и CRM |
В фильтрах графика добавьте DATE_CREATE как поле даты и времени и задайте нужный интервал. Если работаете с одной воронкой, добавьте её в условия отбора. Названия полей в редакторе могут быть показаны в нижнем регистре или с понятными подписями; сверяйте системное имя в описании набора.
CLOSEDATE не заменяет дату создания. В официальном описании crm_deal это планируемая дата закрытия. Стадия, дата изменения и дата создания тоже отвечают на разные вопросы. Поля и их значения можно сверить в справочнике набора сделок.
Выполните запрос или обновите предпросмотр, затем сохраните график в созданный отчёт. Дайте графику понятное имя, разместите его на дашборде и сохраните изменения. Для такого расчёта не нужно начинать с полного SQL-запроса или установки внешней BI-системы.
Добавьте выбор периода и проверьте его действие
В редакторе отчёта откройте настройки фильтров и добавьте временной интервал. Если фильтр «Период» уже есть, проверьте его настройки. Можно задать значение по умолчанию, чтобы отчёт открывался с понятным периодом, и область применения — нужный график.
После сохранения выберите два периода с заведомо разным числом созданных сделок. Если результат одинаковый, не делайте вывод о данных: проверьте поле даты, фильтры самого графика и область применения фильтра отчёта. Официальная справка указывает, что для временной фильтрации набор должен содержать колонку даты и времени.
При сверке записей на границе дня сравните фактическое время создания в CRM и используемые границы интервала. Запишите, как учитывается часовой пояс. Разница между «до начала следующего дня» и «до конца предыдущего» важна для сделок, созданных около полуночи.
Сверьте результат с исходными сделками CRM
Откройте список сделок в CRM и задайте те же даты создания, воронку и ответственного. Не оставляйте фильтр стадии, которого нет в BI. Сравнивайте данные с учётом доступа пользователя: список, из которого часть записей скрыта, не подходит для сверки полного итога.
Проверьте общее число уникальных ID, затем одну строку по сотруднику. Найдите несколько записей по ID: в начале и конце периода, с разными стадиями, а также переданную другому ответственному, если такая есть. Если данных мало, сверяйте весь список. Так вы проверите не только число, но и смысл отбора.
Учебный пример: в период попали пять разных сделок с ID 301–305. За Анной сейчас закреплены 301, 302 и 305, за Борисом — 303 и 304. В таблице ожидаем 3 и 2, всего 5. Если к сделке 301 добавили ещё два товара, количество сделок по-прежнему должно быть 5. Это условные данные для проверки логики, не статистика TrueTell или клиента.
Новые изменения могут не появиться сразу. BI Конструктор кеширует полученные данные на час; при необходимости используйте доступную кнопку «Обновить данные» в «Настройки → Общие настройки», затем проверьте запись повторно. Условия и доступность повторного обновления смотрите в интерфейсе. Как устроено обновление отчёта.
Первый отчёт готов к использованию, когда вы можете назвать условия выборки, объяснить каждую строку и найти исходные сделки. Совпадения красивой итоговой цифры без этой проверки недостаточно.
Что проверить, если цифры не совпали
Ищите одну конкретную сделку, которая есть только в одной из сравниваемых выборок. Её дата, воронка, ответственный и время обновления обычно дают полезнее объяснение, чем попытка одновременно перенастроить весь отчёт.
| Проблема | Что проверить | Критерий проверки |
|---|---|---|
| Итог не меняется при выборе периода | Дата и область применения фильтра | DATE_CREATE участвует в фильтрации именно этого графика |
| В BI сделок больше, чем в списке CRM | Период, воронка, стадии и доступ пользователя | Сравнивается одна выборка с одинаковыми условиями |
| После добавления товаров число выросло | Строки исходного набора и уникальные ID | Одна сделка не посчитана отдельно для каждого товара |
| Новая сделка ещё не появилась | Время получения данных и кеш | После доступного обновления запись находится по ID |
| Два сотрудника попали в одну строку | Поле группировки | Используется идентификатор сотрудника вместе с именем |
Подсчёт уникальных ID защищает количество от повторения строк, но не исправляет любое объединение данных. Например, сумма сделки после присоединения товаров может повториться в каждой товарной строке. Прежде чем добавлять деньги, отдельно определите единицу расчёта и способ проверки суммы.
Как развивать отчёт после первой проверки
Откройте сохранённый отчёт снова из Битрикс24 и убедитесь, что период и график работают. Новый отчёт сохраняется как черновик: сотрудник с правом просмотра его ещё не увидит. В настройках отчёта выберите группу, доступную нужным сотрудникам, а после сверки откройте Меню (≡) → Опубликовать. Этот порядок описан в официальной инструкции по публикации.
После публикации проверьте отчёт с сотрудником, которому передаёте результат. Права в BI Конструкторе назначаются на группы отчётов; передача ссылки сама по себе не заменяет настройку доступа. Убедитесь, что сотруднику разрешено видеть выбранную группу и данные отчёта.
Следующий показатель выбирайте под вопрос руководителя. Для набора управленческих показателей пригодится статья о дашборде руководителя; для проверки результатов продаж — разбор отчётов по продажам Битрикс24. Если нужно связать рекламу с обращениями и сделками, переходите к настройке сквозной аналитики.
Усложняйте модель, когда понятен недостающий ответ: нужны ли исторические ответственные, оплаты, товарные строки или данные склада. Тогда можно оценить, достаточно ли штатного конструктора или необходим отдельный BI-проект. Решение TrueTell для аналитики торговли показывает другой сценарий — отчёты на данных продаж и склада; необходимость подключения CRM и объём работ следует обсудить отдельно.
Если следующий вопрос — где сделки теряются или задерживаются, прочитайте разбор воронки продаж и проблемных этапов. Подсчёт созданных сделок из этого примера сам по себе не показывает историю переходов.
Частые вопросы
Можно ли сделать первый BI-отчёт без SQL?
Да, для описанного примера достаточно набора crm_deal, группировки по ответственному, меры подсчёта уникальных ID и фильтра по DATE_CREATE. Полный SQL-запрос нужен, когда задача требует собственного набора или объединения данных. Если редактор меры запрашивает выражение, для подсчёта используйте COUNT(DISTINCT ID).
Нужно ли подключать внешний коннектор к CRM?
Для этого примера в штатном BI Конструкторе используются наборы данных самого Битрикс24. Подключение CRM к внешней BI-системе — отдельный сценарий со своим коннектором, правами и настройкой обновления.
Какую дату выбрать для новых сделок?
DATE_CREATE — дату и время создания. CLOSEDATE в описании набора crm_deal обозначена как планируемая дата закрытия. Для отчёта о созданных сделках она не заменяет DATE_CREATE.
Почему свежие изменения CRM не сразу видны в отчёте?
BI Конструктор кеширует полученные данные на час. Если нужно проверить свежую запись, используйте доступное обновление данных в разделе «Настройки → Общие настройки», затем повторно проверьте её ID и условия отбора.
Почему количество по менеджеру изменилось без новых сделок?
В этом отчёте сделки распределяются по текущему ответственному. Если запись передали другому сотруднику, распределение может измениться после обновления данных. Отчёт не показывает, кто отвечал за сделку в прошлом: для исторического вопроса нужна другая модель данных.
Можно ли из этой таблицы получить конверсию и выручку?
Количество созданных сделок не является конверсией, оплатой или выручкой. Для каждого следующего показателя отдельно определите числитель, знаменатель, дату и источник данных. Сумму сделки нельзя автоматически считать поступившими деньгами.