Настройка дашборда сравнения цен с конкурентами 1С-Битрикс

Категорийный менеджер тратит до 30% времени на ручную проверку цен — открывает карточку товара, сверяется с конкурентами, повторяет по циклу. При каталоге в 50 000 SKU это сотни человеко-часов в месяц, которые можно было бы потратить на стратегическое ценообразование. Мы ставим дашборд, который за 30 секунд показывает проблемные позиции, разницу в рублях и процентах, и позволяет изменить цену прямо на экране. Такой подход сокращает время анализа в 10 раз по сравнению с ручной сверкой и снижает вероятность ошибок при копировании данных.

На одном из проектов с каталогом 120 000 товаров мы внедрили дашборд за 8 дней. После запуска менеджеры сократили время на ценовой анализ с 4 часов до 15 минут в день. Средняя экономия времени на ценовом анализе — 30%, окупаемость внедрения составляет 2–3 месяца за счёт сокращения ручного труда. Оценим ваш проект за 1 день и дадим смету без переплат. Свяжитесь с нами для консультации.

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

Дашборд строится на трёх таблицах:

• bl_competitor_prices — актуальные цены конкурентов
• bl_product_price_position — агрегаты (мин/макс/среднее конкурентов, наш ранг)
• b_catalog_price — наши текущие цены

Данные в агрегатную таблицу обновляются агентом после каждой синхронизации цен конкурентов. Для ускорения запросов мы добавляем индексы по полям product_id, rank и updated_at. Оптимизация SQL позволяет обрабатывать каталоги до 1 млн товаров без заметных задержек. При каталогах свыше 500 000 SKU дополнительно настраиваем партиционирование таблиц и кэширование тегированное через Bitrix Cache.

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

Вместо того чтобы листать бесконечные товары, менеджер видит сразу, какой раздел каталога «горит». Мы формируем карту: зелёный (>70% на 1-м месте), жёлтый (50–70%), красный (<50%). Это сокращает время анализа в 10 раз по сравнению с ручной проверкой.

// Запрос агрегатов по разделам
$sectionStats = \Bitrix\Main\Application::getConnection()->query("
    SELECT
        s.NAME as section_name,
        COUNT(*) as total_products,
        COUNT(CASE WHEN ppp.rank = 1 THEN 1 END) as on_first_place,
        ROUND(AVG(ppp.rank), 1) as avg_rank,
        COUNT(CASE WHEN ppp.our_price > ppp.min_comp THEN 1 END) as losing_count
    FROM bl_product_price_position ppp
    JOIN b_iblock_element ie ON ie.ID = ppp.product_id
    JOIN b_iblock_section s ON s.ID = ie.IBLOCK_SECTION_ID
    GROUP BY s.ID, s.NAME
    ORDER BY losing_count DESC
")->fetchAll();

Какие метрики показывает дашборд?

Ценовая позиция — распределение товаров по местам:

SELECT rank, COUNT(*) as product_count
FROM bl_product_price_position
WHERE updated_at > NOW() - INTERVAL '24 hours'
GROUP BY rank
ORDER BY rank;

Отображается как bar chart: «1 место — 34 товара, 2 место — 87, 3 место — 124...»

Товары, где мы дороже минимальной цены конкурента:

SELECT
    ie.ID,
    ie.NAME,
    ppp.our_price,
    ppp.min_comp as competitor_min,
    ROUND((ppp.our_price - ppp.min_comp) / ppp.min_comp * 100, 1) as diff_pct,
    ppp.rank
FROM bl_product_price_position ppp
JOIN b_iblock_element ie ON ie.ID = ppp.product_id
WHERE ppp.our_price > ppp.min_comp
  AND ppp.min_comp > 0
ORDER BY diff_pct DESC
LIMIT 50;

Упущенная выручка (оценка):

SELECT
    SUM(
        (ppp.our_price - ppp.min_comp) / ppp.our_price * oe.order_count * ppp.our_price
    ) as estimated_lost_revenue
FROM bl_product_price_position ppp
JOIN (
    SELECT product_id, COUNT(DISTINCT order_id) as order_count
    FROM b_sale_basket
    WHERE date_insert > NOW() - INTERVAL '30 days'
    GROUP BY product_id
) oe ON oe.product_id = ppp.product_id
WHERE ppp.our_price > ppp.min_comp;

Как обновляются данные без перезагрузки?

Кнопка «Обновить данные» запускает AJAX-запрос к бэкенду, который синхронизирует данные с источником цен и пересчитывает агрегаты. Интерфейс остаётся отзывчивым — никаких F5.

document.getElementById('refresh-btn').addEventListener('click', function() {
    this.disabled = true;
    fetch('/bitrix/services/main/ajax.php?action=PriceDashboard:refresh', {
        method: 'POST',
        headers: {'X-Bitrix-Csrf-Token': BX.bitrix_sessid()}
    })
    .then(r => r.json())
    .then(data => {
        if (data.status === 'ok') location.reload();
    });
});

Структура страницы дашборда

Страница в /bitrix/admin/price_dashboard.php состоит из трёх блоков:

Верхний блок — сводные KPI:

• Всего товаров под мониторингом: N
• Из них дороже конкурентов: N (XX%)
• Средняя ценовая позиция: X.X место
• Товаров на 1-м месте: N

Средний блок — тепловая карта по разделам каталога (описана выше).

Нижний блок — таблица проблемных товаров с колонками:

Кнопка «Изменить цену» — инлайн-редактирование с сохранением через AJAX в b_catalog_price. При сохранении в лог bl_price_change_log записывается: кто, когда, с какой цены, на какую.

Процесс работы

1. Анализ — изучаем текущий каталог, источники конкурентных цен, типовые запросы менеджеров. Определяем ключевые метрики.
2. Проектирование — проектируем структуру HL-блоков, агентов, SQL-запросов и интерфейса.
3. Реализация — пишем код: агрегатные запросы, дашборд с Chart.js, инлайн-редактирование, экспорт.
4. Тестирование — проверяем на боевых данных, замеряем производительность, исправляем узкие места.
5. Запуск — деплоим на продакшн, проводим обучение менеджеров, передаём документацию.

Экспорт в Excel

Кнопка «Выгрузить в Excel» формирует отчёт через \PhpOffice\PhpSpreadsheet: все товары с ценами конкурентов по столбцам (каждый конкурент — отдельный столбец), нашей ценой, позицией, рекомендованной ценой (если настроен репрайсер).

Что входит в работу (deliverables)

• Настроенные агрегатные таблицы с оптимизированными индексами
• SQL-запросы для KPI, тепловой карты и списка проблем
• Интерфейс дашборда (PHP + JS + Chart.js)
• Инлайн-редактирование цен с логированием
• Экспорт в Excel
• Инструкция для менеджеров по работе с дашбордом
• Гарантия 30 дней на стабильную работу

Сроки

Типичные ошибки при внедрении дашборда

Игнорирование индексов. Без правильных индексов (особенно по product_id и rank) запросы на каталоге 100 000 товаров выполняются минутами. Мы всегда проверяем EXPLAIN и добавляем композитные индексы.

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

Отсутствие логирования изменений. Без лога bl_price_change_log невозможно отследить, кто и когда менял цены. Это критично для отчётов и аудита.

С нашим опытом (более 50 внедрений дашбордов на Битрикс) мы избегаем этих граблей. Сертифицированные специалисты с 7+ годами работы с 1С-Битрикс гарантируют стабильное решение. Закажите настройку дашборда под ключ.

Получите консультацию — свяжитесь с нами, мы оценим ваш проект и подготовим дорожную карту. Ваш коммерческий менеджер получит инструмент, который реально экономит время. Для подробностей о работе с HL-блоками обратитесь к официальной документации 1С-Битрикс по Highload-блокам.

Настройка цен и скидок: типовые проблемы

Мы сталкиваемся с ситуацией, когда маркетолог запустил акцию «−20% на электронику», менеджер вручную поставил спеццену VIP-клиенту, а система лояльности насчитала ещё 10%. Итог: покупатель видит −44% вместо запланированных −20%, товар уходит ниже себестоимости. Корень — неправильные приоритеты правил корзины в модуле sale и конфликт типов цен в b_catalog_price. Правильная настройка цен и скидок на 1С‑Битрикс устраняет хаос и сохраняет маржинальность даже при сотнях активных акций. Оценим ваш проект за один день — просто свяжитесь.

Типы цен: таблица b_catalog_price и выбор стратегии

Битрикс хранит цены в таблице b_catalog_price — по строке на каждый тип цены для каждого товара. Типы определяются в b_catalog_group и привязываются к группам пользователей через b_catalog_group2group. Грамотная настройка типов цен — база для любых скидочных механик.

Для каждого типа настраиваем:

• Автоматический расчёт через формулы наценки/скидки от базовой (CCatalogProductProvider или обработчик OnGetOptimalPrice).
• Валюту и правила округления в b_catalog_rounding.
• Импорт/экспорт через CSV и синхронизацию с 1С (CommerceML).

Мультивалютность реализуется через обновление курсов \Bitrix\Currency\CurrencyManager::updateCBRFRates() или вручную в b_catalog_currency. Отображение в валюте пользователя — по геолокации (через geoip) или по настройкам профиля. Скидки корректно работают после конвертации: процент считается от сконвертированной суммы.

Правила корзины: как избежать конфликтов скидок

Модуль sale, раздел «Правила работы с корзиной» (/bitrix/admin/sale_discount.php) — конструктор условий без разработчика, но с возможностью всё сломать.

Типовые сценарии:

• Скидка от суммы: BASKET_AMOUNT >= 5000 → DISCOUNT 10%
• «3 по цене 2» — условие на количество в корзине по секции каталога
• Скидка на комплект: «Телефон + чехол + стекло = −15%» — через правило с множественным условием PRODUCT_ID IN (...)
• Таймер: скидка активна с 23:00 до 07:00 через поля ACTIVE_FROM / ACTIVE_TO
• Скидка для группы: проверка USER_GROUP в условиях правила

Приоритеты — где обычно стреляют в ногу

Две скидки по 20% — это не 40%. При последовательном применении: 100 → 80 → 64, итог −36%. При параллельном: 100 − 20 − 20 = 60, итог −40%. Если забыть поставить приоритет, Битрикс может применить обе как отдельные правила и дать −36%. Или наоборот.

Настраиваем:

• Поле PRIORITY для порядка применения
• Флаг LAST_DISCOUNT = Y — «после этой скидки другие не применять»
• Максимальный процент через кастомный обработчик OnBeforeSaleOrderFinalAction
• Исключение товаров/категорий из правил через EXCLUDE условия

Наша настройка приоритетов с LAST_DISCOUNT снижает вероятность конфликтов скидок в 5 раз по сравнению с хаотичным применением. В 8 из 10 магазинов, где скидки «складывались» неожиданно, проблема была именно в приоритетах и отсутствии флага LAST_DISCOUNT. Мы фиксируем это на этапе аудита.

Как избежать конфликтов правил корзины?

Без чётких приоритетов легко получить каскад неконтролируемых скидок. Решение — установить порядок применения через PRIORITY и запретить дальнейшие скидки с помощью LAST_DISCOUNT = Y. Для сложных акций (например, накопительная + промокод) используем кастомные обработчики, которые сравнивают итоговую скидку с допустимой маржой. Это гарантирует, что клиент не уйдёт с убыточным чеком.

Накопительные скидки и программы лояльности

Четыре модели на выбор:

• Пороговая — скидка растёт с суммой покупок. Проще для клиента и поддержки.
• Балльная — начисление за покупки, оплата баллами. Гибче, но сложнее в восприятии.
• Уровневая — серебряный/золотой/платиновый. Геймификация удерживает.
• Кэшбэк — возврат на внутренний счёт (b_sale_user_account).

Пороговая система: пример реализации

Технически: обработчик OnSaleOrderPaid пересчитывает сумму оплаченных заказов через CSaleOrder::GetList() с фильтром PAYED = Y, обновляет группу пользователя через CUser::SetUserGroup(). Группа привязана к типу цены — скидка применяется автоматически при следующем заходе.

Дополнительные возможности:

• Уведомление «Вам осталось 3 200 руб. до золотого статуса» — через кастомный компонент в личном кабинете.
• Срок действия уровня — годовой (пересчёт агентом CAgent) или бессрочный.
• Раздельный расчёт по категориям — покупки электроники не влияют на статус в одежде.

Как это работает на практике: кейс

Недавно настроили накопительную программу для интернет-магазина бытовой техники с товарной матрицей в 15 000 SKU. До этого лояльность отсутствовала — скидки выдавались вручную менеджерами. Внедрили пороговую систему с 4 уровнями. Результат: повторные покупки выросли на 40% за полгода, маржинальность не упала — скидка редко превышает 10% по средней корзине.

Промокоды и их возможности

Управление через CSaleDiscount и кастомный административный интерфейс:

• Одноразовые — уникальный код, привязанный к купону (b_sale_discount_coupon).
• Многоразовые — общий код с лимитом через MAX_USE.
• Персональные — привязка к USER_ID.
• Массовая генерация — CSaleDiscountCoupon::Add() в цикле, хоть тысяча за минуту.

Ограничения: минимальная сумма заказа, категории товаров, лимит на пользователя, дата действия, совместимость с другими скидками. Статистика — кто, когда, с каким чеком использовал — через отчёт по b_sale_discount_coupon с JOIN на b_sale_order. Привязка к UTM-меткам показывает, какой канал реально приносит конверсию.

Оптовые цены (B2B)

Механизмы, которых нет в коробке:

• Автоматическое переключение типа цены при количестве > N через обработчик OnGetOptimalPrice.
• Шкала цен — отображение в карточке товара через кастомный компонент: «1–9 шт: 1000₽, 10–49: 900₽, 50–99: 800₽, 100+: 700₽».
• Персональные прайс-листы — генерация PDF/Excel из личного кабинета через PhpSpreadsheet.
• Запрос спеццены через форму → лид в CRM.
• Кредитный лимит и отсрочка платежа через b_sale_user_account и кастомный платёжный обработчик.

Акции и персонализация

Расписание через ACTIVE_FROM / ACTIVE_TO — автоматический старт и завершение. Таймер обратного отсчёта — JS-компонент, привязанный к ACTIVE_TO элемента. Ограничение количества акционных товаров через свойство QUANTITY_LIMIT и проверку в обработчике корзины. Раздел «Акции» — через смарт-фильтр по свойству IS_SALE = Y.

Типы: распродажа, товар дня (ротация агентом), флеш-сейл, ликвидация остатков, сезонные.

Персонализация:

• VIP-скидки через индивидуальную группу пользователя → персональный тип цены.
• Корпоративные условия: отсрочка платежа, индивидуальная доставка.
• Сегментация по поведению через b_sale_order → автоматическое назначение скидок.
• Динамическое ценообразование — кастомный модуль, корректирующий цену на основе спроса, остатков и цен конкурентов.

Интеграция с 1С

• Импорт типов цен через CommerceML (стандартный обмен bitrix:catalog.import.1c).
• Синхронизация скидочных карт: номер карты → группа пользователя → тип цены.
• Правила округления и НДС — согласование между 1С и Битрикс, чтобы цена на сайте совпадала с ценой в накладной.
• Обновление по расписанию (cron + агент) или в реальном времени через REST API.

Дополнительная информация: Wikipedia: 1С-Битрикс и CommerceML.

Как мы настраиваем цены и скидки: пошаговый процесс

1. Аудит текущей системы ценообразования — выявление конфликтов правил, ошибок в приоритетах, неиспользуемых типов цен.
2. Разработка схемы скидок — с учётом маржинальности и бизнес-логики (накопительные, оптовые, промокоды, персонализация).
3. Настройка правил корзины — приоритеты, флаги, исключения.
4. Интеграция с 1С — синхронизация типов цен, скидочных карт, округлений.
5. Тестирование — нагрузочное тестирование при 100+ активных правилах, проверка конфликтов.
6. Документация — описание всех настроек, инструкция для маркетологов.
7. Обучение менеджеров — как создавать и отключать акции без риска.
8. Поддержка 30 дней — после запуска исправляем нештатные ситуации.

Сроки

Стоимость рассчитывается индивидуально — зависит от глубины аудита и числа товаров. Накопленный опыт (более 7 лет) и сертифицированные специалисты гарантируют, что ваша маржинальность останется под контролем. Получите консультацию по настройке цен и скидок — свяжитесь с нами, и мы за 1 день оценим проект.