B2B-аналитика в личном кабинете на 1С-Битрикс: дашборды, KPI и отчёты

Личный кабинет собирает заказы, персональные цены, баланс и документы дилера — но у собранных за месяцы данных есть второй пласт ценности, который часто остаётся неиспользованным. Клиент хочет понимать, сколько и на что он тратит, растут ли его закупки, сколько он должен и на чём экономит по персональным ценам. Руководитель поставщика хочет видеть, кто из клиентов растёт, а кто «сдувается», как работают менеджеры, где висит дебиторка и на каком этапе застревают сделки. Всё это — не отдельные отчёты в Excel «по запросу», а живая B2B-аналитика прямо в кабинете, разграниченная по ролям.

Эта статья — практический разбор того, как устроена B2B-аналитика в Битрикс: какие дашборды и метрики нужны клиенту, а какие — менеджеру и владельцу, откуда берутся данные (заказы сайта, CRM, 1С), как визуализировать это графиками и таблицами с экспортом, как не «уронить» кабинет тяжёлыми отчётами и разграничить доступ. Материал из нашей практики — по делу, без выдуманных цифр и обещаний «роста в два раза от дашборда». Собираем такие решения в рамках услуги личного кабинета с аналитикой продаж и KPI.

Зачем аналитика в B2B-кабинете

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

Аналитика в кабинете снимает эту нагрузку с обеих сторон. Клиент сам смотрит динамику и структуру своих закупок, не отвлекая менеджера. Руководитель открывает дашборд и видит картину по всей базе — без ожидания выгрузки. Менеджер работает с приоритетами, а не с интуицией. Данные, которые и так копятся в заказах, CRM и 1С, превращаются в инструмент решений.

Выгода тут двусторонняя, и её важно назвать честно, без завышенных обещаний:

• Для клиента — контроль закупок: видно, сколько и на что уходят деньги, растут ли объёмы, сколько он должен и на чём экономит по персональным ценам.
• Для менеджера — фокус: понятно, кто из закреплённых клиентов растёт, кто снижает закупки, где висит долг и какие сделки застряли в воронке.
• Для владельца — управление: продажи по клиентам и менеджерам, план/факт, ABC/XYZ базы, общая дебиторка — картина для решений, а не набор разрозненных отчётов.

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

Две аудитории: клиент и управление

Главная ошибка при постановке задачи на B2B-аналитику — считать, что «дашборд один и он для всех». На самом деле у аналитики в кабинете две принципиально разные аудитории, и путать их метрики нельзя.

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

Дальше в статье мы разберём сначала клиентский срез (разделы 3–10), затем управленческий (разделы 11–16), а потом — общие для обоих технические темы: источники данных, визуализацию, обновление, права и реализацию в Битрикс.

Дашборд закупок клиента: из чего состоит

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

Типовой состав клиентского дашборда:

• Ключевые плитки (KPI-виджеты). Сумма закупок за период, число заказов, средний чек, текущий баланс и задолженность — крупными числами сверху.
• Динамика закупок. График объёма закупок по месяцам — видно, растёт клиент или снижается.
• Структура по категориям. Круговая или столбчатая диаграмма: на какие группы товаров уходят деньги.
• Топ-товары. Таблица позиций, которые клиент закупает чаще и больше всего.
• Баланс и дебиторка. Текущее сальдо, сумма к оплате, кредитный лимит и его остаток.
• Статусы активных заказов. Что в работе, что отгружается, что ждёт оплаты.
• Экономия по персональным ценам. Сколько клиент сэкономил относительно базовой цены за счёт своих условий.
• Быстрые действия и выгрузки. Повторить заказ, скачать отчёт по закупкам, акт сверки.

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

Динамика закупок клиента

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

Что полезно показывать в динамике:

• Объём закупок по периодам. Сумма закупок по месяцам или неделям — базовая линия тренда.
• Число заказов и средний чек. Отдельно от суммы: клиент видит, растёт объём за счёт частоты или за счёт размера заказа.
• Сравнение с прошлым периодом. Текущий квартал против предыдущего или год к году — чтобы оценить рост в контексте.
• Выбор периода. Переключатель «месяц / квартал / год» и произвольный диапазон дат.

Важный нюанс — что считать закупкой. Оформленный на сайте заказ, отгруженная реализация в 1С и оплаченная поставка — это разные события с разными суммами. Для динамики закупок клиента обычно берут либо заказы сайта (оперативно, но включает неотгруженное), либо реализации из 1С (точнее по факту, но с задержкой обмена). Выбор источника нужно проговорить заранее и подписать на графике, на каких данных он построен, чтобы клиент понимал, что видит.

Ещё одна тонкость — не выдавать желаемое за действительное. Динамика показывает факт: если закупки снизились, график это честно отразит. Это нормально и даже полезно — клиент сам заметит провал и вернётся к менеджеру с вопросом. Пытаться «сгладить» неудобные периоды или показывать только рост — значит подорвать доверие к аналитике.

Структура закупок по категориям

Динамика отвечает на вопрос «сколько», структура — на вопрос «на что». Закупщику важно видеть, как распределяются его деньги по группам товаров: где основная доля, что он берёт понемногу, а что не берёт вовсе, хотя мог бы.

Как обычно строят структуру закупок:

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

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

Топ-товары и повторяемость заказов

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

Что показывает блок топ-товаров и повторяемости:

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

Здесь аналитика напрямую смыкается с функциональностью кабинета. Повторный заказ и списки закупок — это уже действия, а топ-товары — их аналитическое основание: система показывает клиенту его типовую закупку и предлагает повторить её в один клик. Механику повторного заказа и загрузки из файла мы подробно разбираем в статье про личный кабинет дилера на 1С-Битрикс — аналитика топ-товаров добавляет к ней слой понимания «что именно повторять».

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

Баланс и дебиторка в кабинете клиента

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

Что показывает финансовый блок клиента:

• Текущий баланс. Сальдо по контрагенту: должен клиент или есть переплата.
• Дебиторская задолженность. Сумма к оплате и, если ведётся в 1С, разбивка по срокам — что просрочено, что в пределах отсрочки.
• Кредитный лимит и остаток. Сколько ещё можно заказать в долг до достижения лимита.
• История платежей и отгрузок. Движение по счёту для самостоятельной сверки.
• Динамика долга. Как менялась задолженность во времени — не растёт ли она незаметно.

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

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

Статусы заказов и отгрузок

Аналитика — это не только графики за прошлое, но и картина текущего состояния. Закупщику важно оперативно видеть, что происходит с его активными заказами: что принято, что в сборке, что отгружено, что ждёт оплаты. Это оперативный срез аналитики, который живёт рядом с историческими дашбордами.

Что полезно отражать в блоке статусов:

• Сводка по статусам. Сколько заказов в каждом состоянии — принят, согласован, в сборке, отгружен, закрыт.
• Частичные отгрузки. Один заказ может отгружаться частями с разных складов — клиент видит каждую отгрузку отдельно.
• Заказы к оплате. Что ждёт оплаты и на какую сумму — связка со статусом и дебиторкой.
• Резервы и ожидаемые поступления. Что зарезервировано под клиента, а что придёт позже, если такие данные ведутся в 1С.

Как и баланс, статусы и отгрузки — данные учётной системы. Они ведутся в 1С и передаются на сайт обменом, а кабинет их отображает и агрегирует в сводку. Качество этого блока напрямую зависит от полноты обмена: если 1С не отдаёт частичные отгрузки, аналитика их не покажет.

Персональные цены и экономия клиента

У B2B-клиента есть персональные условия — оптовые или дилерские цены, скидки по объёму, индивидуальный прайс. Аналитика может сделать ценность этих условий видимой: показать, сколько клиент сэкономил относительно базовой цены. Это одновременно и полезная метрика для закупщика, и мягкий аргумент удержания со стороны поставщика.

Как обычно показывают экономию:

• Экономия за период. Разница между базовой (розничной или прайсовой) стоимостью закупок и суммой по персональным ценам клиента.
• Средняя скидка. На сколько в среднем персональные цены ниже базовых по факту закупок.
• Экономия по категориям. Где персональные условия дают наибольшую выгоду — подсказка, что выгоднее брать именно у этого поставщика.
• Прогресс к следующему уровню. Если условия зависят от объёма — сколько осталось до следующей ценовой ступени.

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

Отдельно стоит подумать, показывать ли экономию всем клиентам. Иногда её показывают только там, где скидка действительно существенна и её видимость выгодна поставщику. Это бизнес-решение: аналитика даёт инструмент, а компания решает, какому сегменту и как его подавать.

Выгрузки и отчёты для клиента

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

Что обычно выгружает клиент:

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

Формат тоже подбирают под задачу. Таблицы данных (закупки, детализация) выгружают в Excel/CSV для дальнейшей обработки. Сводные отчёты и «красивые» дашборды — в PDF для печати и пересылки. Бухгалтерские документы вроде акта сверки формирует 1С и отдаёт как файл — сайт их не «рисует» сам, чтобы не разойтись с учётом.

Аналитика для менеджера и владельца

Переходим от клиентского среза к управленческому. Здесь аудитория другая — сотрудники поставщика, — и вопросы другие: не «что со мной», а «что с бизнесом». Управленческая аналитика работает поверх всей базы клиентов и опирается на данные заказов, CRM и 1С одновременно.

Что входит в управленческий контур аналитики:

• Продажи по клиентам. Кто сколько принёс, кто растёт, кто снижается, кто перестал покупать.
• План/факт. Сравнение фактических продаж с планом — по компании, менеджеру, клиенту, категории.
• KPI менеджеров. Показатели работы каждого менеджера: объём, число сделок, средний чек, дебиторка его клиентов.
• ABC/XYZ клиентов. Классификация базы по вкладу и стабильности — куда направлять внимание.
• Воронка продаж. На каком этапе сделки и где они застревают — из CRM.
• Дебиторка по всей базе. Общий долг, просрочка, распределение по клиентам и менеджерам.

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

Продажи по клиентам и план/факт

Базовый управленческий отчёт — продажи в разрезе клиентов. Он отвечает на главный вопрос руководителя: кто делает выручку и что с этими клиентами происходит во времени.

Что показывает отчёт по клиентам:

• Оборот по клиенту за период с динамикой — растёт, стабилен или падает.
• Сравнение периодов. Текущий квартал против прошлого, год к году — рост в контексте.
• Клиенты в зоне риска. Те, у кого закупки резко снизились или пропали привычные позиции, — ранние сигналы оттока.
• Новые и вернувшиеся. Кто пришёл в этом периоде, кто возобновил закупки после паузы.

Поверх продаж по клиентам строится план/факт. План продаж — это ориентир, который компания задаёт на период (по всей компании, по менеджеру, по клиенту или по категории), а факт берётся из реальных продаж. Аналитика показывает разрыв: где идём с опережением, где отстаём, сколько осталось до плана. Это превращает абстрактную цель в управляемый показатель.

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

KPI менеджеров

Если у поставщика есть отдел продаж, руководителю нужна аналитика работы менеджеров. KPI (ключевые показатели эффективности) переводят абстрактное «менеджер хорошо работает» в конкретные измеримые числа, которые видно на дашборде.

Какие KPI обычно смотрят по менеджерам в B2B:

• Объём продаж закреплённых клиентов за период и его динамика.
• Выполнение плана. Процент выполнения личного плана продаж.
• Число сделок и средний чек — за счёт чего растёт объём.
• Активность клиентской базы. Сколько клиентов активны, сколько «уснуло», сколько новых.
• Дебиторка его клиентов. Сумма и просрочка долга по закреплённым партнёрам — качество работы, а не только объём.
• Конверсия воронки. Как менеджер проводит сделки по этапам, если это ведётся в CRM.

Здесь есть важная оговорка. KPI — мощный, но обоюдоострый инструмент: люди начинают работать на показатель. Если считать только объём, менеджер может «раздувать» отгрузки в ущерб дебиторке; если только число сделок — дробить заказы. Поэтому набор KPI подбирают сбалансированным (объём + качество долга + активность базы), и — что важно — формулы и цели задаёт бизнес, а не разработчик. Аналитика лишь честно считает то, что определила компания.

Технически KPI менеджеров — это агрегаты по продажам и дебиторке с группировкой по ответственному. Ответственный берётся из CRM или из закрепления контрагента за менеджером. Поэтому качество KPI зависит от того, насколько аккуратно ведётся это закрепление: если клиенты «висят без менеджера» или закреплены неверно, показатели поедут.

ABC/XYZ-анализ клиентов

Когда клиентов много, все они «размазаны» в общем списке, и непонятно, на кого тратить время. ABC/XYZ-анализ наводит порядок: он группирует базу по двум осям и превращает список в понятную матрицу приоритетов.

Две оси классификации:

• ABC — по вкладу в оборот. A — немногие клиенты, дающие основную выручку; B — средние; C — многочисленные мелкие. Правило Парето в действии: меньшинство клиентов обычно даёт большинство оборота.
• XYZ — по стабильности закупок. X — покупают регулярно и предсказуемо; Y — с колебаниями и сезонностью; Z — эпизодически, разово.

Пересечение осей даёт матрицу из девяти групп, и каждая требует своей тактики:

Ключевая оговорка: ABC/XYZ — это инструмент группировки, а не готовое решение. Аналитика раскладывает клиентов по группам, но пороги (какая доля оборота = группа A, какой разброс закупок = X) и трактовку задаёт бизнес. Одна и та же матрица у дистрибьютора и у производителя означает разное. Поэтому в кабинете важно дать настройку порогов, а не зашивать их жёстко «как в учебнике».

И ещё: ABC/XYZ — это срез для руководителя и, возможно, менеджера, но никогда — для клиента. Партнёр не должен видеть, в какую группу его отнесли и как он сравнивается с другими. Это часть темы разграничения прав, к которой мы вернёмся ниже.

Воронка B2B-продаж

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

Что даёт аналитика воронки:

• Число и сумма сделок по этапам. Сколько в работе, на согласовании, в оплате — и на какие суммы.
• Конверсия между этапами. Какая доля сделок проходит дальше, а где основной отвал.
• Застрявшие сделки. Что «зависло» на этапе дольше нормы — повод вмешаться менеджеру.
• Воронка по менеджерам. У кого узкое место на каком этапе — качественная сторона KPI.

Данные воронки живут в CRM, а не в заказах сайта. Заказ на сайте — это уже почти закрытая сделка, а воронка описывает путь до неё: обращения, переговоры, счета. Поэтому аналитика воронки строится на связке кабинета с CRM (в экосистеме Битрикс это часто Битрикс24 или CRM того же продукта), где ведётся работа со сделками. Если CRM не используется и вся работа — только через заказы сайта, полноценной воронки не будет: покажется лишь «хвост» процесса от оформления заказа.

Тему сквозной аналитики, которая связывает воронку с источниками трафика и рекламой, мы разбираем отдельно — в статье про сквозную аналитику для e-commerce на Битрикс. Воронка в B2B-кабинете — это её управленческая часть, сфокусированная на работе менеджеров со сделками, а не на маркетинге.

Дебиторка по всей базе клиентов

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

Что показывает управленческий дашборд дебиторки:

• Общая дебиторка по компании и её динамика — растёт ли долг в целом.
• Разбивка по срокам. Текущая задолженность в пределах отсрочки и просроченная, с градацией по дням просрочки.
• Топ должников. Клиенты с наибольшим и наиболее просроченным долгом — кому звонить в первую очередь.
• Дебиторка по менеджерам. Какой долг «висит» на клиентах каждого менеджера — часть его KPI.
• Использование лимитов. Кто близко к кредитному лимиту, у кого превышение.

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

Источники данных: сайт, CRM, 1С

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

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

Отсюда главное правило, которое повторяется во всей статье: финансовые цифры не пересчитываются на сайте. Оборот, баланс, долг, лимит берутся из 1С обменом. Заказы сайта используют для аналитики закупок и динамики, но не как источник финансовой правды. Смешивать источники в одной метрике нельзя — для каждого показателя источник определяется один раз и фиксируется.

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

Визуализация и экспорт в Excel/PDF

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

Базовый набор форм визуализации в B2B-аналитике:

• KPI-плитки. Крупное число + подпись + сравнение с прошлым периодом. Для главных показателей на первом экране.
• Линейные графики. Динамика во времени — закупки, продажи, дебиторка по месяцам.
• Столбчатые диаграммы. Сравнение категорий, клиентов, менеджеров, план/факт.
• Круговые/долевые диаграммы. Структура — по категориям, срокам дебиторки, ABC-группам. Уместны, когда долей немного.
• Таблицы. Детализация, топ-списки, построчные данные — то, что нужно выгрузить и обработать.

Практическое правило: сначала таблица и число, потом график. B2B-пользователь — это закупщик, менеджер, финансист; ему часто нужнее точная цифра и выгрузка, чем эффектная диаграмма. Графики хороши для трендов и структуры, но не должны вытеснять таблицы, из которых берут конкретику. Не стоит увлекаться экзотическими типами визуализации ради красоты — простые графики читаются однозначно, сложные требуют расшифровки.

Экспорт — обязательная часть визуализации, а не опция. Таблицы выгружаются в Excel/CSV для дальнейшей обработки, сводные отчёты и дашборды — в PDF для печати и пересылки. Как уже говорилось, выгрузка должна формироваться из того же слоя данных, что и экран, чтобы цифры совпадали. И экспорт, и отображение проверяют права: пользователь выгружает только то, что ему разрешено видеть.

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

Обновление данных и кэш

Аналитика по всей базе за длинный период — это тяжёлые вычисления. Если считать их «на лету» при каждом заходе, кабинет будет открываться секундами, а на большой базе — падать по таймауту. Поэтому производительность аналитики — не деталь, а условие её жизнеспособности.

Ключевой приём — предрасчёт агрегатов. Обороты по клиентам, суммы по категориям, значения KPI, дебиторка по срокам считаются заранее по расписанию (например, ночью или несколько раз в день) и складываются в отдельные таблицы. Дашборд читает уже готовые числа, а не пересчитывает всю историю при каждом открытии. Это на порядки быстрее и снимает нагрузку с базы.

Как устроено обновление данных на практике:

1. Обмен с 1С и CRM по расписанию. Реализации, взаиморасчёты, отгрузки, сделки приходят на сайт и складываются в свои таблицы.
2. Предрасчёт агрегатов. Фоновая задача (агент или крон) считает обороты, KPI, ABC/XYZ, дебиторку и сохраняет результат.
3. Кэш дашбордов. Готовые срезы кэшируются; персональные дашборды клиента — с привязкой к пользователю, чтобы никто не увидел чужие данные из общего кэша.
4. Отображение с датой актуальности. Дашборд показывает данные и дату последней синхронизации, чтобы пользователь понимал, насколько они свежие.
5. Точечное обновление. Оперативные блоки (статусы активных заказов) могут обновляться чаще тяжёлых исторических срезов.

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

Права на аналитику: роли и доступ

Аналитика показывает чувствительные данные: обороты, дебиторку, сравнение клиентов и менеджеров. Ошибка в правах здесь опаснее, чем в обычном разделе, — можно раскрыть одному клиенту обороты другого или дать менеджеру всю базу, которую ему видеть не положено. Поэтому разграничение доступа — фундамент, а не настройка «на потом».

Типовая ролевая модель доступа к аналитике:

Технически это те же роли, что и в остальном кабинете. Доступ к каждой выборке проверяется на бэкенде: данные фильтруются по привязке пользователя к контрагенту (для клиента) или по закреплению клиентов за менеджером (для управления). Правило то же, что и с закрытыми ценами: если что-то не должно быть видно, оно не должно приходить с сервера, а не «приходит, но скрыто в интерфейсе». Иначе данные достаются из кода страницы или прямым запросом к API дашборда.

Ролевую модель B2B-портала — как устроены роли внутри контрагента и на стороне поставщика — мы подробно разбираем в отдельной статье про роли и права в B2B-портале на Битрикс. Аналитика встраивается в эту модель: каждый дашборд и каждая выгрузка привязаны к роли, а не открыты «всем, кто дошёл до раздела».

Интеграция с BI-системами

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

Когда встроенной аналитики достаточно, а когда нужна BI:

В сценарии с BI сайт перестаёт быть местом, где строятся сложные отчёты, и становится одним из источников данных. Заказы, закупки и события кабинета выгружаются в хранилище (data warehouse) — регулярной выгрузкой или через API, — а BI-платформа строит отчёты поверх нескольких систем сразу: сайта, 1С, CRM, рекламных кабинетов. Клиентские дашборды при этом обычно остаются в кабинете, а «тяжёлую» управленческую аналитику уводят в BI.

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

Реализация в 1С-Битрикс

Перейдём от «что показывать» к «на чём это делается». Аналитика в кабинете на 1С-Битрикс собирается поверх штатного фундамента платформы, но сами дашборды — это почти всегда проектная разработка, а не готовый компонент «из коробки».

Из чего складывается реализация:

• Кастомные разделы кабинета. Аналитика — это отдельные страницы личного раздела со своими компонентами и контроллерами, а не доработка штатных sale.personal.*. Их встраивают в навигацию кабинета рядом с заказами, балансом и документами.
• Выборки и агрегаты. Данные для дашбордов считаются запросами к таблицам заказов, торгового каталога и собственным таблицам, куда сложены данные 1С и CRM. Тяжёлые агрегаты предрассчитываются фоновыми агентами и складываются отдельно.
• Графики. Диаграммы рисуются клиентскими библиотеками по данным, которые контроллер отдаёт через AJAX; сложные PDF-отчёты формируются на сервере.
• Обмен с 1С и CRM. Расширенный обмен подтягивает реализации, взаиморасчёты, дебиторку, лимиты и сделки — без них аналитика останется только по заказам сайта.
• Права на уровне контроллеров. Каждая выборка и каждая выгрузка проверяет роль на бэкенде и фильтрует данные по привязке пользователя.

Как это собирается по шагам:

1. Определяем метрики и роли. Что показываем клиенту, что менеджеру, что руководителю; как считается каждая цифра и из какого источника. Это делают до кода — вместе с бизнесом.
2. Настраиваем обмен. 1С отдаёт реализации, взаиморасчёты, дебиторку и лимиты; CRM — сделки и ответственных. Данные складываются в таблицы на стороне сайта.
3. Строим слой агрегатов. Фоновые задачи считают обороты, KPI, ABC/XYZ, дебиторку по срокам и сохраняют результат для быстрого чтения.
4. Разрабатываем разделы и дашборды. Кастомные страницы кабинета, компоненты и контроллеры, графики и таблицы, экспорт в Excel/PDF.
5. Закрываем права и кэш. Фильтрация по роли на бэкенде, персональный кэш, дата актуальности данных.
6. Проверяем под всеми ролями. Клиент видит только своё, менеджер — своих, руководитель — всё; цифры сходятся с 1С, отчёты не тормозят.

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

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

Частые ошибки

Эти промахи повторяются в проектах B2B-аналитики чаще всего — зная их, вы сэкономите время и сохраните доверие к дашбордам:

• Считают деньги на сайте. Оборот, баланс и дебиторку складывают из заказов вместо обмена с 1С — цифры расходятся с бухгалтерией, аналитике перестают верить.
• Тяжёлые отчёты «на лету». Агрегаты по всей базе считают при каждом заходе без предрасчёта — кабинет тормозит и падает по таймауту на большой базе.
• Один дашборд для всех. Пытаются показать клиенту и руководителю одно и то же — либо клиент видит лишнее, либо руководителю не хватает данных.
• Слабое разграничение прав. Данные фильтруются в интерфейсе, а не на бэкенде — чужие обороты достаются из кода страницы или прямым запросом.
• Смешивают источники в метрике. В одном показателе мешают заказы сайта, отгрузки 1С и оплаты — получается несопоставимая цифра, которую невозможно объяснить.
• Кэш без учёта пользователя. Персональный дашборд кэшируется «для всех» — клиент видит из общего кэша чужие данные.
• Выгрузка расходится с экраном. Excel считается отдельной логикой от дашборда — числа в файле и на экране разные.
• Красота вместо ясности. Экзотические графики ради вида вместо простых таблиц и понятных диаграмм — пользователь не понимает, что видит.
• Метрики без определений. «Продажа», «план», «активный клиент» не определены однозначно — цифры становятся поводом для споров, а не основой решений.
• Начинают с BI. Строят внешнее хранилище и BI-платформу под пять отчётов — проект раздувается, а встроенной аналитики хватило бы.
• KPI без баланса. Меряют менеджеров только объёмом — те раздувают отгрузки в ущерб дебиторке и качеству базы.
• Нет даты актуальности. Дашборд не показывает, на какой момент данные — пользователь удивляется, что свежая оплата не отразилась.

Чек-лист внедрения аналитики

Короткий список для приёмки аналитики перед запуском — по нему удобно проверить, что и клиентский, и управленческий контур закрыты:

1. Метрики и источники определены. Для каждой цифры зафиксировано, что она значит и из какого источника берётся (сайт / CRM / 1С).
2. Клиентский дашборд работает. Динамика и структура закупок, топ-товары, баланс и дебиторка, статусы, экономия — только свой срез.
3. Управленческий контур закрыт. Продажи по клиентам, план/факт, KPI менеджеров, ABC/XYZ, воронка, дебиторка по базе.
4. Деньги — из 1С. Баланс, оборот, дебиторка и лимиты приходят обменом, а не считаются на сайте.
5. Права разграничены. Клиент видит своё, менеджер — своих, руководитель — всё; фильтрация на бэкенде проверена под каждой ролью.
6. Предрасчёт и кэш настроены. Тяжёлые агрегаты считаются по расписанию, персональные дашборды кэшируются по пользователю.
7. Дата актуальности показана. На дашбордах видно, на какой момент данные.
8. Экспорт совпадает с экраном. Выгрузки в Excel/CSV и PDF формируются из того же слоя, что и дашборд.
9. Визуализация читается. Простые графики и таблицы, понятные без расшифровки; главное — числами сверху.
10. Обмен отдаёт нужное. 1С и CRM передают реализации, взаиморасчёты, дебиторку, лимиты, сделки и признаки для группировки.
11. Производительность проверена. Дашборды открываются быстро на реальном объёме базы и истории.
12. Цифры сверены. Ключевые показатели дашборда совпадают с 1С и выгрузками — контрольная сверка пройдена.

Вывод

B2B-аналитика в личном кабинете на 1С-Битрикс — это не один дашборд «для красоты», а два продукта в одном кабинете. Клиенту она даёт контроль над закупками: динамику и структуру, топ-товары и повтор, баланс и дебиторку, экономию по персональным ценам. Менеджеру и владельцу — управление: продажи по клиентам, план/факт, KPI, ABC/XYZ базы, воронку и дебиторку по всем. Данные сходятся из трёх источников — заказов сайта, CRM и 1С, — каждый со своей ролью.

Три принципа определяют, будет аналитика работать или разочарует. Первый — 1С как источник истины по деньгам: оборот, баланс, дебиторка и лимиты приходят из учётной системы, а не считаются на сайте, иначе цифры разойдутся и доверие рухнет. Второй — предрасчёт вместо расчёта на лету: тяжёлые агрегаты считаются заранее и кэшируются, тогда дашборды остаются быстрыми на большой базе. Третий — разграничение прав на бэкенде: клиент видит только своё, менеджер — своих, руководитель — всё, а фильтрация работает на сервере, а не скрытием в интерфейсе. Соблюдая их, вы получаете аналитику, которой доверяют обе стороны: клиент видит честную картину своих закупок, а руководитель — реальную картину бизнеса. А начинать стоит с понятного минимума метрик и наращивать срезы под реальные вопросы, а не строить «BI мечты» до того, как определены хотя бы базовые показатели.