Розробка модуля аналітики для адміністратора 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;