Розробка дашборда з KPI для адміністратора 1С-Бітрікс

Стандартна адміністративна панель Бітрікс показує технічні метрики — навантаження, помилки, стан модулів. Бізнес-KPI там немає: виручку за сьогодні, конверсію воронки, середній чек по менеджерах дивляться в окремих системах або взагалі в Excel. Дашборд з бізнес-метриками, вбудований прямо в Бітрікс, прибирає цей розрив. Ми розробляємо такі дашборди під ключ: від SQL-запитів до візуалізації в адмінці або публічній сторінці.

Які KPI реально потрібні бізнесу?

Часто керівники просять «всі метрики», але реальна користь — у 5–6 ключових показниках. Інтернет-магазину потрібні виручка, конверсія, середній чек, топ товарів. Оптовому дистриб'ютору — дебіторка, прострочення, завантаження менеджерів. Ми допомагаємо виділити саме ті KPI, які впливають на прийняття рішень.

Чому стандартні звіти Бітрікс не підходять?

Штатні звіти — це зрізи на момент запиту, без динаміки та порівняння періодів. Немає єдиного вікна: виручку дивляться в 1С, конверсію — в Метриці, завантаження — в Управлінні персоналом. Дашборд об'єднує ці дані в одному інтерфейсі, заощаджуючи 2–3 години на день на зведенні.

Архітектура дашборду

Дашборд реалізується як окрема сторінка в адміністративній частині: /bitrix/admin/kpi_dashboard.php. Або як публічна сторінка в закритому розділі — для доступу менеджерів без права на /bitrix/admin/.

Дані агрегуються безпосередньо з бази через SQL — це швидше, ніж послідовні виклики Бітрікс API для кожного віджета. Візуалізація — Chart.js або ApexCharts, підключаються як JS-залежності.

Ключові SQL-запити для KPI

Виручка за період з розбивкою по днях:

SELECT
    DATE(o.date_insert) AS day,
    COUNT(o.id)         AS orders_count,
    SUM(o.price)        AS revenue,
    AVG(o.price)        AS avg_check
FROM b_sale_order o
WHERE
    o.lid = 's1'
    AND o.canceled = 'N'
    AND o.date_insert >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY DATE(o.date_insert)
ORDER BY day;

Конверсія кошика в замовлення:

WITH baskets AS (
    SELECT DATE(date_insert) AS day, COUNT(DISTINCT fuser_id) AS basket_users
    FROM b_sale_basket
    WHERE site_id = 's1' AND date_insert >= CURRENT_DATE - INTERVAL '30 days'
    GROUP BY DATE(date_insert)
),
orders AS (
    SELECT DATE(date_insert) AS day, COUNT(DISTINCT user_id) AS order_users
    FROM b_sale_order
    WHERE lid = 's1' AND date_insert >= CURRENT_DATE - INTERVAL '30 days'
    GROUP BY DATE(date_insert)
)
SELECT b.day,
       b.basket_users,
       COALESCE(o.order_users, 0) AS order_users,
       ROUND(COALESCE(o.order_users, 0)::NUMERIC / NULLIF(b.basket_users, 0) * 100, 2) AS conversion
FROM baskets b
LEFT JOIN orders o ON o.day = b.day
ORDER BY b.day;

Топ товарів по виручці:

SELECT
    ie.name AS product_name,
    SUM(bi.quantity) AS qty_sold,
    SUM(bi.price * bi.quantity) AS revenue
FROM b_sale_basket_item bi
JOIN b_sale_order_shipment_item si ON si.basket_id = bi.id
JOIN b_sale_order o ON o.id = bi.order_id
JOIN b_iblock_element ie ON ie.id = bi.product_id
WHERE o.canceled = 'N' AND o.date_insert >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY ie.id, ie.name
ORDER BY revenue DESC
LIMIT 20;

PHP-реалізація віджетів

Дані віддаються через AJAX-endpoint і рендеряться Chart.js:

// /local/ajax/kpi_data.php
if (!$USER->IsAdmin()) {
    header('HTTP/1.1 403 Forbidden');
    exit;
}

$widget = $_GET['widget'] ?? '';
$dateFrom = $_GET['date_from'] ?? date('Y-m-d', strtotime('-30 days'));
$dateTo   = $_GET['date_to']   ?? date('Y-m-d');

$db = \Bitrix\Main\Application::getConnection();

switch ($widget) {
    case 'revenue_chart':
        $data = $db->query("
            SELECT DATE(date_insert) as day,
                   SUM(price) as revenue,
                   COUNT(*) as cnt
            FROM b_sale_order
            WHERE lid = ? AND canceled = 'N'
              AND DATE(date_insert) BETWEEN ? AND ?
            GROUP BY DATE(date_insert)
            ORDER BY day
        ", [SITE_ID, $dateFrom, $dateTo])->fetchAll();
        break;

    case 'top_products':
        // ... см. запрос выше
        break;
}

header('Content-Type: application/json');
echo json_encode(['success' => true, 'data' => $data ?? []]);

// Инициализация графика выручки
const startDate = new Date();
startDate.setDate(startDate.getDate() - 30);
fetch(`/local/ajax/kpi_data.php?widget=revenue_chart&date_from=${encodeURIComponent(startDate.toISOString().slice(0,10))}`)
    .then(r => r.json())
    .then(({ data }) => {
        const ctx = document.getElementById('revenueChart').getContext('2d');
        new Chart(ctx, {
            type: 'bar',
            data: {
                labels: data.map(d => d.day),
                datasets: [{
                    label: 'Выручка, ₽',
                    data: data.map(d => d.revenue),
                    backgroundColor: '#4F81BD',
                }]
            },
            options: { responsive: true, plugins: { legend: { display: false } } }
        });
    });

Кейс: дашборд для інтернет-магазину електроніки (наш клієнт)

Проєкт — e-commerce з 4 менеджерами, 50–80 замовлень на день. Задача: керівник хоче бачити виручку в реальному часі, конверсію та завантаження менеджерів. Ми реалізували дашборд з 6 віджетами:

1. Виручка сьогодні / вчора / тиждень тому (порівняння в числах та %)
2. Графік виручки за 30 днів (Bar chart)
3. Воронка: відвідувачі → кошики → замовлення (дані з Бітрікс + Яндекс.Метрика API)
4. Топ-10 товарів по виручці за період
5. Завантаження менеджерів: кількість замовлень в роботі на кожного
6. Незакриті замовлення старші 3 днів (потребують уваги)

Дашборд оновлюється кожні 5 хвилин через setInterval. Важкі агрегатні запити кешуються на 5 хвилин з інвалідацією при зміні статусів замовлень. Керівник проєкту зазначив: дашборд скоротив час на аналіз даних втричі.

Час розробки — 12 робочих днів (SQL-запити, PHP-backend, верстка дашборду, інтеграція з Метрикою). Економія часу керівника — до 10 годин на місяць на підготовці звітів.

Типові помилки при розробці дашбордів

• Запити без кешування — при 10 000+ замовленнях сторінка завантажується 20+ секунд.
• Спроба витягнути всі дані через GetList() — на великих об'ємах це катастрофа.
• Відсутність фільтра по датах — дашборд марний для аналізу динаміки.
• Невраховані права доступу: менеджери бачать чужі замовлення.

Ми вирішуємо ці проблеми на етапі проєктування: використовуємо сирі SQL-запити, теговане кешування, рольову модель.

Що входить в роботу

Строки

Чому обирають нас

Досвід наших інженерів — понад 10 років в Бітрікс, більше 50 проєктів з дашбордами. Ми — сертифікований партнер 1С-Бітрікс. Гарантуємо: дашборд не впаде на піку навантаження, дані свіжі з точністю до 5 хвилин, візуалізація адаптивна для будь-якого екрану. Вартість розробки визначається після аналізу вашого проєкту.

Оцінимо ваш проєкт безкоштовно. Зв'яжіться з нами, щоб обговорити метрики та отримати прототип дашборду за 1 день.

Чому аналітика 1С-Бітрікс часто вводить в оману?

Лічильники стоять, пікселі повішені, CRM підключена — а цифри розходяться на всі боки. Конверсія e-commerce не передається в dataLayer. UTM-мітки втрачаються на редиректах ЧПУ. Маркетолог бачить 100 лідів, комерційний директор — 70 угод, і кожен рахує по-своєму. Рішення приймаються на відчуттях, а рекламний бюджет летить у нікуди — за нашими даними, втрати через некоректну аналітику сягають 30–40% бюджету. Для магазина з витратами на рекламу 100 000 грн на місяць це 30–40 тис. грн щомісячних втрат.

Ми налаштовуємо аналітику 1С-Бітрікс більше 10 років. Через наші руки пройшло 500+ проєктів — від дрібних інтернет-магазинів до федеральних рітейлерів зі значним товарообігом. Досвід показує: у 90% випадків dataLayer або відсутній, або зібраний з помилками, які крадуть 30–40% e-commerce подій. Наш підхід — не «поставив лічильник і забув», а повноцінна наскрізна аналітика з гарантією коректної передачі всіх критичних параметрів. Після впровадження похибка даних знижується з 40% до 1–2%, а маркетинговий бюджет починає працювати на повну.

Як аналітика 1С-Бітрікс вирішує проблему розбіжності даних?

Рішення — не в додаванні нових лічильників, а у виправленні dataLayer та замиканні ланцюжка «візит → лід → угода → оплата». Ми впроваджуємо коректну передачу e-commerce подій, налаштовуємо наскрізну аналітику з прив'язкою до CRM та будуємо дашборди, де кожен канал видно з реальним ROI. Результат: ROI зростає в середньому на 25% за квартал — для магазина з оборотом 1 млн грн на місяць це додаткові 250 000 грн прибутку.

Як виправити e-commerce трекінг у Яндекс.Метриці та GA4?

Базове налаштування — і чому його зазвичай роблять криво

• Встановлення через GTM, а не вставкою в header.php — інакше при оновленні шаблону лічильник злетить.
• Цілі: не абстрактні «клік по кнопці», а конкретні — basket_add, відправка форми bx_form_submit, перехід на /personal/order/make/.
• Вебвізор — вмикаєш, а він пише 1% сесій, тому що в налаштуваннях стоїть семплювання. Потрібно явно задати відсоток запису — 20–30% для збалансованих даних — і не забути про 152-ФЗ.
• Фільтрація внутрішнього трафіку — без цього трафік співробітників додає 15–20% сміттєвих візитів. Фільтруємо по IP, cookie _ym_debug, заголовкам.

Електронна комерція — найнедооціненіша фіча

Модуль eCommerce в Метриці передає повний ланцюжок купівельної поведінки. Проблема в тому, що в Бітрікс з коробки він працює тільки з компонентом sale.order.ajax, і то криво — втрачає remove_from_cart при AJAX-оновленні кошика.

Що ми передаємо в dataLayer:

• Перегляд картки — id, name, brand, category, price. Без brand Метрика не побудує звіт за брендами, без category — за категоріями.
• Додавання в кошик — ловимо подію onBXAddToBasket через JS, а не через обробник OnSaleBasketItemAdd на сервері. Серверний обробник не знає про JS-контекст.
• Видалення з кошика — тут пастка: штатний компонент sale.basket.basket при AJAX-оновленні не генерує окрему подію видалення. Потрібен свій обсёрвер.
• Покупка — передаємо на sale/order/complete/, включаючи coupon та revenue з урахуванням знижок.

Приклад налаштування dataLayer для події add_to_cart:

BX.addCustomEvent('onBXAddToBasket', function(product) {
    window.dataLayer.push({
        'event': 'add_to_cart',
        'ecommerce': {
            'items': [{
                'item_id': product.id,
                'item_name': product.name,
                'price': product.price,
                'quantity': 1
            }]
        }
    });
});

Чому GA4 на Бітрікс вимагає ручного налаштування?

GA4 працює на подіях, а не на хітах. Немає «переглядів сторінок» у звичному сенсі — є page_view як одна з подій. Для Бітрікса це означає, що AJAX-переходи (фільтрація каталогу, пагінація) потрібно пушити вручну.

Ключові події e-commerce: view_item_list → select_item → view_item → add_to_cart → view_cart → begin_checkout → add_shipping_info → add_payment_info → purchase. Кожна подія вимагає свій набір параметрів. purchase без transaction_id — не зарахується. add_to_cart без масиву items — марний. GA4 мовчки проковтне невалідні дані і покаже порожні звіти. За нашою статистикою, в 60% Бітрікс-проектів GA4 налаштований з порушенням специфікації Enhanced E-commerce. Це призводить до втрати до 40% транзакцій у звітах.

Користувацькі параметри, які реально потрібні:

• user_type — guest / registered / wholesale
• user_group — група користувача з Бітрікс
• order_count — кількість замовлень у користувача
• cumulative_discount — накопичувальна знижка
• first_source — UTM першого візиту

Що дає наскрізна аналітика на Бітрікс?

Метрика бачить візити. CRM бачить угоди. Рекламний кабінет бачить витрати. А зв'язок між ними — розрив. Менеджер закрив велику угоду, але Метрика показує джерело (direct), тому що клієнт прийшов за прямим посиланням із закладок, а перший контакт був через Директ три місяці тому.

Наскрізна аналітика замикає ланцюжок: рекламний клік → візит → лід в CRM → угода → оплата → ROI. Після впровадження клієнти перерозподіляють бюджет на користь каналів з високим LTV, і ROI зростає в середньому на 25% за квартал. Roistat показує на 40% точнішу атрибуцію порівняно з Calltouch за нашими тестами на великих проектах.

Як збираємо

1. UTM-мітки фіксуємо в cookie з TTL 90 днів і дублюємо в наскрізну систему.
2. При створенні ліда в Бітрікс24 записуємо UTM в користувацькі поля угоди.
3. Коллтрекінг підміняє номер і прив'язує дзвінок до візиту.
4. Менеджер веде угоду по воронці, закриває — сума прив'язана до джерела.
5. Сервіс агрегує витрати через API рекламних кабінетів.
6. ROI = (виручка — витрати) / витрати по кожній кампанії.

Дашборди та воронка: де шукати діри

Будуємо дашборди в DataLens або Looker Studio. Ключове — не перевантажувати.

• Дашборд для директора — виручка, кількість замовлень, середній чек, порівняння з минулим періодом. П'ять віджетів, оновлення раз на годину.
• Дашборд для маркетолога — трафік по каналах, CAC, ROI кампаній, конверсія воронки, ефективність промокодів.
• Дашборд для комерційного — конверсія менеджерів, швидкість обробки замовлень, повторні покупки. DataLens підключаємо напряму до PostgreSQL/MySQL Бітрікса через b_sale_order і b_sale_basket.

Провал на чекауті — найнайдорожчий. Користувач уже хотів купити, вже поклав у кошик, і тут sale.order.ajax кидає 500-ку через неналаштований обробник доставки. Після аудиту воронки ми фіксуємо проблему, і конверсія чекауту зростає в 1.5-2 рази за місяць.

Когортний аналіз і LTV: групуємо за місяцем першої покупки, дивимося retention через 30, 60, 90 днів. В DataLens будується через SQL-запит до b_sale_order з GROUP BY DATE_TRUNC('month', DATE_INSERT). Головний інсайт — який канал приваблює клієнтів з високим LTV. Контекст може давати дешеві перші замовлення, але нульовий repeat rate. А SEO-трафік конвертується гірше, зате повертається. Без цього аналізу ви ризикуєте переплачувати за канали, які дають одноразових покупців.

Терміни та вартість налаштування аналітики

Що входить в налаштування: аудит поточного dataLayer та виправлення помилок; налаштування коректного e-commerce трекінгу для Метрики та GA4; розробка користувацьких подій під бізнес-вимоги; інтеграція наскрізної аналітики (Roistat/Calltouch) з Бітрікс24; створення дашбордів в DataLens/Looker Studio; документація по всіх подіях та параметрах; навчання маркетологів та комерційного відділу роботі зі звітами; технічна підтримка на місяць після запуску.

Вартість розраховується індивідуально залежно від обсягу робіт та складності інтеграцій. Отримайте консультацію — ми проаналізуємо ваш поточний dataLayer та запропонуємо оптимальне рішення. Замовте аудит або налаштування аналітики, щоб перестати втрачати гроші на некоректних даних. Звертайтеся — перевіримо, чи не втрачаєте ви гроші на аналітиці, за один день.