Разработка модуля аналитики для администратора 1С-Битрикс

Разработка модуля аналитики для администратора 1С-Битрикс

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

За 10+ лет мы реализовали более 500 проектов на 1С-Битрикс, и кастомная аналитика — одна из самых востребованных доработок. Модуль строится на агрегационных таблицах, которые дают скорость загрузки в 100 раз выше, чем прямой SQL. Рассмотрим, как это работает.

Почему стандартных отчетов недостаточно?

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

Данные для аналитики разбросаны по нескольким таблицам:

Прямые запросы к этим таблицам в реальном времени для дашборда — плохая идея: b_sale_order на активном магазине содержит миллионы записей. Решение — агрегационные таблицы, которые пересчитываются ночью и при необходимости инкрементально. Такая архитектура даёт скорость чтения в 100 раз выше, чем прямой SQL.

Этапы разработки модуля аналитики

Процесс внедрения модуля состоит из нескольких этапов:

1. Анализ бизнес-требований — выявление ключевых метрик и сценариев использования. Мы собираем пожелания руководителя и определяем, какие данные нужны в дашборде.
2. Проектирование схемы данных — создание агрегационных таблиц с индексами и партиционированием для быстрой загрузки.
3. Разработка агентов и событий — настройка фоновых заданий для пересчёта агрегатов и инкрементальных обновлений каждые 15 минут.
4. Создание дашборда — интерфейс с фильтрами, графиками и таблицами. Верхняя панель показывает ключевые показатели сегодня.
5. Интеграция с внешними API — при необходимости подключаем Яндекс.Метрику, CRM, сервисы рассылок.
6. Тестирование и настройка прав доступа — разграничение видимости отчётов для разных ролей.
7. Документация и обучение — описание схемы, агентов, инструкция администратора.
8. Гарантийная поддержка — 1 месяц после сдачи.

Как устроена агрегация?

Создаём отдельную таблицу с дневными суммами:

-- Дневные агрегаты CREATE TABLE myvendor_analytics_daily ( date DATE NOT NULL, orders INT DEFAULT 0, revenue DECIMAL(14,2) DEFAULT 0, avg_check DECIMAL(14,2) DEFAULT 0, new_users INT DEFAULT 0, canceled INT DEFAULT 0, PRIMARY KEY (date) ); 

Агент в 02:00 пересчитывает предыдущий день и обновляет строку. Данные текущего дня обновляются каждые 15 минут инкрементально — от последней обработанной записи по b_sale_order.DATE_STATUS. Подробнее о механике агентов читайте в документации 1С-Битрикс.

Структура дашборда

Верхняя панель — ключевые показатели сегодня:

• Выручка (и % изменения vs вчера / прошлую неделю)
• Количество заказов
• Средний чек
• Конверсия: посетители → заказы (если подключена Метрика)

Блок "Топ товаров" за выбранный период: по количеству продаж, по выручке, по количеству возвратов. Данные из агрегационной таблицы myvendor_analytics_product_daily.

Воронка заказов. Показывает потери на каждом этапе:

• Добавили в корзину (из b_sale_fuser + b_sale_basket)
• Перешли к оформлению
• Оплатили
• Получили (статус доставки)

Это самый ценный отчёт — он показывает, где именно теряются деньги.

Детально: отчёт по когортам

Когортный анализ — насколько хорошо магазин удерживает покупателей. Когорта — группа пользователей, сделавших первый заказ в один период (неделя или месяц). Когортный анализ позволяет объективно оценить retention.

-- Первый заказ каждого пользователя WITH first_orders AS ( SELECT user_id, MIN(DATE_TRUNC('month', date_insert)) AS cohort_month FROM b_sale_order WHERE canceled = 'N' AND user_id > 0 GROUP BY user_id ), -- Все последующие заказы repeat_orders AS ( SELECT o.user_id, fo.cohort_month, DATE_TRUNC('month', o.date_insert) AS order_month FROM b_sale_order o JOIN first_orders fo ON o.user_id = fo.user_id WHERE o.canceled = 'N' ) SELECT cohort_month, order_month, COUNT(DISTINCT user_id) AS users FROM repeat_orders GROUP BY cohort_month, order_month ORDER BY cohort_month, order_month;