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

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Услуги, которые мы предлагаем
Показано 1 из 1Все 1626 услуг
Разработка дашборда с KPI для администратора 1С-Битрикс
Средний
~1-2 недели
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1378
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    968
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    705
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    851
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    747
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1096

Стандартная административная панель Битрикс показывает технические метрики — нагрузку, ошибки, состояние модулей. Бизнес-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-запросы, тегированное кэширование, ролевую модель.

Что входит в работу

Компонент Описание
Техническое задание Описание метрик, источников данных, макетов
Прототип Интерактивный макет в админке
Разработка SQL-запросы, PHP-эндпоинты, JS-виджеты
Интеграция 1С, Яндекс.Метрика, CRM (по необходимости)
Тестирование Нагрузочное тестирование на 1000+ заказов
Документация Инструкция по добавлению новых виджетов
Передача прав Исходный код, доступы к кэшированию

Сроки

Объём Срок
3–4 виджета (выручка, заказы, топ товаров) 4–6 дней
6–8 виджетов + фильтры по периоду 8–12 дней
Полный дашборд + интеграция с внешними источниками 12–20 дней

Почему выбирают нас

Опыт наших инженеров — более 10 лет в Битрикс, свыше 50 проектов с дашбордами. Мы — сертифицированный партнёр 1С-Битрикс. Гарантируем: дашборд не упадёт на пике нагрузки, данные свежие с точностью до 5 минут, визуализация адаптивна для любого экрана. Стоимость разработки — от 40 000 до 150 000 ₽ в зависимости от числа метрик и сложности.

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

Почему аналитика 1С-Битрикс часто вводит в заблуждение

Счётчики стоят, пиксели повешены, CRM подключена — а цифры расходятся во все стороны. Конверсия e-commerce не передаётся в dataLayer. UTM-теряются на редиректах ЧПУ. Маркетолог видит 100 лидов, коммерческий директор — 70 сделок, и каждый считает по-своему. Решения принимаются по ощущениям, а рекламный бюджет улетает в никуда.

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

Как аналитика 1С-Битрикс решает проблему расхождения данных

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

Яндекс.Метрика: настройка e-commerce без потерь

Базовая настройка — и почему её обычно делают криво

Счётчик Метрики ставят все. Правильно — единицы.

  • Установка через 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
            }]
        }
    });
});

Данные, которые уходят в Метрику

Параметр Откуда берём Грабли
ID товара PRODUCT_ID из инфоблока Не путать с ID торгового предложения — это разные сущности
Категория Цепочка разделов инфоблока Метрика ждёт формат «Электроника/Смартфоны», разделитель — /
Бренд Свойство инфоблока Если Highload-справочник — нужен дополнительный запрос
Цена CATALOG_PRICE_1 или тип цены контрагента Передавать финальную, после скидок
Купон CSaleBasket::GetList → DISCOUNT_COUPON Может быть пустым — не ломайте dataLayer

Google Analytics 4: почему Битрикс требует ручной настройки?

Чем GA4 отличается от Universal Analytics

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% транзакций в отчётах.

Пользовательские параметры, которые реально нужны

Не надо передавать всё подряд. Пять параметров, дающих 80% пользы:

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

Сквозная аналитика: замыкаем цепочку от клика до сделки

Метрика видит визиты. CRM видит сделки. Рекламный кабинет видит расходы. А связь между ними — разрыв. Менеджер закрыл сделку на 500К, но Метрика показывает источник (direct), потому что клиент пришёл по прямой ссылке из закладок, а первый контакт был через Директ три месяца назад.

Сквозная аналитика замыкает цепочку: рекламный клик → визит → лид в CRM → сделка → оплата → ROI. <cite>По нашим данным, после внедрения сквозной аналитики клиенты перераспределяют бюджет в пользу каналов с высоким LTV, и ROI растёт в среднем на 25% за квартал.</cite>

Как собираем

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

Инструменты

Платформа Сильная сторона Слабое место
Roistat Мультиканальная атрибуция, коллтрекинг, интеграция с Битрикс24 Ежемесячная стоимость
Calltouch Лучший коллтрекинг на рынке Сквозная аналитика слабее, чем у Roistat
CoMagic (UIS) Связка звонки + чат + аналитика Интерфейс устарел
Битрикс24 CRM-аналитика Бесплатно, внутри CRM Не считает расходы на рекламу, нет коллтрекинга

Дашборды: три экрана вместо десяти отчётов

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

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

Воронка: где именно дыра

Типичная воронка Битрикс-магазина:

Этап Что смотрим Где обычно проблема
Каталог → Карточка CTR по товарам Плохие фото, нет цены в списке
Карточка → Корзина Add-to-cart rate Нет кнопки «Купить» в первом экране
Корзина → Чекаут Checkout initiation Неожиданная стоимость доставки
Чекаут → Заказ Completion rate Обязательная регистрация, падение sale.order.ajax

Провал на чекауте — самый дорогой. Пользователь уже хотел купить, уже положил в корзину, и тут 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-трафик конвертируется хуже, зато возвращается. Без этого анализа вы рискуете переплачивать за каналы, которые дают одноразовых покупателей.

Что входит в настройку аналитики 1С-Битрикс

  • Аудит текущего dataLayer и исправление ошибок
  • Настройка корректного e-commerce трекинга для Метрики и GA4
  • Разработка пользовательских событий под бизнес-требования
  • Интеграция сквозной аналитики (Roistat/Calltouch) с Битрикс24
  • Создание дашбордов в DataLens/Looker Studio
  • Документация по всем событиям и параметрам
  • Обучение маркетологов и коммерческого отдела работе с отчётами
  • Техническая поддержка на месяц после запуска

Сроки

Задача Срок
Метрика + eCommerce (с корректным dataLayer) 3-5 дней
GA4 + Enhanced E-commerce 3-5 дней
Сквозная аналитика (Roistat/Calltouch + CRM) 2-4 недели
Дашборды в DataLens/Looker Studio 1-2 недели
Комплексная система 4-8 недель

Закажите аудит или настройку аналитики

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