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

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

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

Почему штатный журнал не подходит для мониторинга?

Журнал событий Битрикс фиксирует каждое действие парсера построчно. Если за сутки обрабатывается 10 000 товаров, вы видите 10 000 записей. Нет агрегации по времени, нет цветовой индикации ошибок, нет возможности быстро увидеть проблемный источник. Дашборд решает эту проблему: он собирает данные из таблицы задач парсера и показывает сводную картину за 5 секунд.

Что выводим на дашборд

Дашборд отвечает на вопрос «всё ли в порядке?» за 5 секунд. Ключевые метрики:

Индикаторы состояния (верхняя полоса):

• Всего источников / из них активных / с ошибками.
• Товаров обработано за сутки: создано / обновлено / пропущено / ошибки.
• Время последнего успешного запуска по каждому источнику.

Графики (центральная область):

• Количество обработанных элементов по дням (stacked bar — created/updated/skipped/error).
• Время выполнения парсинга по источникам (line chart).
• Процент ошибок по источникам (bar chart).

Таблица источников (нижняя часть):

Цветовая схема: зелёный — последний запуск успешен и был менее 2 интервалов назад, жёлтый — ошибки >1%, красный — последний запуск failed или просрочен.

Как ускорить загрузку дашборда на больших каталогах?

Для каталогов до 100 000 товаров и 10 источников стандартные SQL-запросы выполняются мгновенно. Если каталог больше, мы используем материализованное представление: таблица parser_stats_daily, обновляемая агентом раз в час. Это сокращает время загрузки дашборда до долей секунды.

Источник данных

Дашборд строится на данных из таблицы задач парсера. Минимальная схема:

CREATE TABLE parser_task (
    id SERIAL PRIMARY KEY,
    source_id INT NOT NULL,
    status VARCHAR(20),
    started_at TIMESTAMP,
    finished_at TIMESTAMP,
    total_items INT DEFAULT 0,
    created_items INT DEFAULT 0,
    updated_items INT DEFAULT 0,
    error_items INT DEFAULT 0
);

Агрегация выполняется SQL-запросами при загрузке дашборда. Для графика по дням:

SELECT DATE(started_at) AS day,
       SUM(created_items) AS created,
       SUM(updated_items) AS updated,
       SUM(error_items) AS errors
FROM parser_task
WHERE started_at >= NOW() - INTERVAL '30 days'
GROUP BY DATE(started_at)
ORDER BY day;

На каталоге до 100 000 товаров и 10 источниках эти запросы выполняются мгновенно. Для крупных проектов добавьте материализованную таблицу parser_stats_daily, обновляемую агентом раз в час.

Реализация в административной панели

Дашборд реализуется как административная страница (/local/admin/parser_dashboard.php), подключённая через меню модуля. Для графиков используем встроенную в Битрикс библиотеку amCharts (доступна в CAdminPage) или подключаем Chart.js через $APPLICATION->AddHeadScript(). В наших проектах мы чаще используем Chart.js — он гибче в настройке и даёт больше возможностей для кастомизации.

Структура страницы:

1. Виджеты-карточки вверху — <div> с числовыми показателями, стилизованные через adm-detail-content. Битрикс CSS предоставляет классы adm-info-message, adm-warning-message, adm-error-message для цветовой индикации.
2. Canvas-графики в центре — данные подгружаются AJAX-запросом к обработчику, который возвращает JSON с агрегатами.
3. CAdminList внизу — стандартный список источников с кастомными колонками.

Автообновление

Дашборд должен обновляться без перезагрузки страницы. Добавьте setInterval с периодом 60 секунд, запрашивающий /local/admin/ajax/parser_stats.php. Обработчик возвращает JSON с текущим состоянием. На клиенте обновляем числа в карточках и перерисовываем графики.

Для индикации «парсер сейчас работает» используйте polling статуса из parser_task с status = 'running'. Показывайте анимированный спиннер рядом с названием источника.

Алерты прямо из дашборда

Добавьте кнопку «Настроить алерты» рядом с каждым источником. По клику — модальное окно с порогами: максимальный процент ошибок, максимальное время выполнения, максимальная задержка между запусками. Пороги хранятся в b_option модуля. Агент проверяет пороги и отправляет уведомление при превышении.

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

• Проектирование схемы данных и SQL-агрегаций.
• Разработка виджетов, графиков и таблицы источников.
• Настройка автообновления и индикации активного парсера.
• Реализация алертов с настраиваемыми порогами.
• Интеграция с существующей системой автонаполнения.
• Тестирование на нагрузку до 100 000 товаров.
• Обучение администраторов и документация.

Гарантируем, что дашборд будет работать под ключ в течение 1-2 недель. Оценим ваш проект за 2 дня — напишите нам.

Сроки реализации

Более 5 лет опыта с 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 с учётом скидок

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
            }]
        }
    });
});

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

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 = (выручка — расходы) / расходы по каждой кампании

Инструменты

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

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

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

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

Сроки

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

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