Мониторинг цен конкурентов в 1С-Битрикс: настройка и интеграция

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

Мы работали с крупным онлайн-ритейлером бытовой техники, где цены конкурентов менялись до 15 раз в день. Ручной мониторинг отнимал 2 часа у менеджера ежедневно, а задержка реакции на снижение цены составляла до суток. Результат — потери в маржинальности до 5% по отдельным позициям. Решение — автоматическое отслеживание цен конкурентов прямо внутри 1С-Битрикс.

Отслеживание цен строится одним из двух способов: через готовый сервис мониторинга (Competera, Metacommerce, Priceva) или через собственный парсер. Готовый сервис — проще, надёжнее, но дорого при каталоге от 10 000 SKU. Собственный парсер — гибко, дёшево в эксплуатации, но требует регулярного обслуживания при изменениях на сайтах конкурентов. Задача настройки в обоих случаях одинакова: собрать данные, сохранить в Битрикс, показать менеджеру в удобном виде.

Сравнение подходов: сервис vs парсер

Выбор зависит от вашего бюджета и объёма. Для каталога более 50 000 товаров чаще выгоднее парсер.

Почему нельзя хранить цены конкурентов в инфоблоках?

Инфоблоки Битрикс не предназначены для частых массовых обновлений. При каталоге в 10 000 товаров и 5 конкурентах получаем 50 000 записей, которые перезаписываются каждый час. ORM инфоблоков генерирует лишние события (OnBeforeIBlockElementUpdate), сбрасывает кэш, тормозит админку. Решение — использовать HL-блоки или отдельные таблицы в БД. Мы отдаём предпочтение таблицам — они быстрее, не имеют накладных расходов на события и версионность.

Архитектура хранения данных

Независимо от источника данных (сервис или парсер), структура хранения одинакова. Создаём две основные таблицы:

Конкуренты bl_price_competitors:

CREATE TABLE bl_price_competitors (
    id       SERIAL PRIMARY KEY,
    name     VARCHAR(255) NOT NULL,
    domain   VARCHAR(255) UNIQUE,
    active   BOOLEAN DEFAULT true,
    logo_url VARCHAR(512)
);

Цены конкурентов bl_competitor_prices:

CREATE TABLE bl_competitor_prices (
    id             SERIAL PRIMARY KEY,
    product_id     INT NOT NULL,               -- b_iblock_element.ID
    competitor_id  INT REFERENCES bl_price_competitors(id),
    price          NUMERIC(12,2) NOT NULL,
    url            VARCHAR(512),               -- URL страницы конкурента
    in_stock       BOOLEAN DEFAULT true,
    checked_at     TIMESTAMP NOT NULL DEFAULT NOW(),
    UNIQUE (product_id, competitor_id)         -- одна актуальная цена
);
CREATE INDEX idx_comp_prices_product ON bl_competitor_prices(product_id, checked_at DESC);

История bl_competitor_prices_history — партиционированная по месяцам таблица для хранения изменений без раздувания основной. При каждом обновлении актуальной цены предыдущее значение перемещается в историю.

Интеграция через API сервиса мониторинга

При использовании готового сервиса агент запрашивает данные и записывает в bl_competitor_prices:

function SyncCompetitorPrices(): string
{
    $client = new PriceMonitoringClient(MONITORING_API_KEY);
    $data   = $client->getPrices(['date' => date('Y-m-d')]);

    foreach ($data['products'] as $item) {
        $productId = ProductMapper::findBySku($item['sku']);
        if (!$productId) continue;

        foreach ($item['competitors'] as $comp) {
            $competitorId = CompetitorTable::getOrCreateByDomain($comp['domain']);

            // Сохраняем в историю перед обновлением
            $current = CompetitorPriceTable::getByProductAndCompetitor($productId, $competitorId);
            if ($current && $current['PRICE'] != $comp['price']) {
                CompetitorPriceHistoryTable::add([
                    'PRODUCT_ID'    => $productId,
                    'COMPETITOR_ID' => $competitorId,
                    'PRICE'         => $current['PRICE'],
                    'RECORDED_AT'   => $current['CHECKED_AT'],
                ]);
            }

            CompetitorPriceTable::addOrUpdate([
                'PRODUCT_ID'    => $productId,
                'COMPETITOR_ID' => $competitorId,
                'PRICE'         => $comp['price'],
                'URL'           => $comp['url'],
                'IN_STOCK'      => $comp['in_stock'],
                'CHECKED_AT'    => new \Bitrix\Main\Type\DateTime(),
            ]);
        }
    }

    return __FUNCTION__ . '();';
}

Расчёт ценовой позиции и агрегатов

При каждом обновлении считаем агрегаты и позицию в bl_product_price_position:

-- Обновляется триггером или агентом после синхронизации
INSERT INTO bl_product_price_position (product_id, our_price, min_comp, avg_comp, max_comp, rank, updated_at)
SELECT
    cp.product_id,
    bcp.PRICE as our_price,
    MIN(cp.price) as min_comp,
    ROUND(AVG(cp.price), 2) as avg_comp,
    MAX(cp.price) as max_comp,
    (SELECT COUNT(*) + 1 FROM bl_competitor_prices cp2
     WHERE cp2.product_id = cp.product_id AND cp2.price < bcp.PRICE) as rank,
    NOW()
FROM bl_competitor_prices cp
JOIN b_catalog_price bcp ON bcp.PRODUCT_ID = cp.product_id AND bcp.CATALOG_GROUP_ID = 1
GROUP BY cp.product_id, bcp.PRICE
ON CONFLICT (product_id) DO UPDATE SET
    our_price = EXCLUDED.our_price, min_comp = EXCLUDED.min_comp,
    avg_comp = EXCLUDED.avg_comp, rank = EXCLUDED.rank, updated_at = NOW();

Как настроить оповещения при изменении цен конкурентов?

Агент сравнивает новые цены с предыдущими и отправляет уведомление менеджерам при значимых изменениях — например, когда конкурент только что стал дешевле нас:

foreach ($priceChanges as $change) {
    if ($change['new_price'] < $change['our_price'] && $change['old_price'] >= $change['our_price']) {
        $message = sprintf(
            'Конкурент %s снизил цену на %s до %s руб. (наша: %s руб.)',
            $change['competitor_name'],
            $change['product_name'],
            number_format($change['new_price'], 2, ',', ' '),
            number_format($change['our_price'], 2, ',', ' ')
        );
        \Bitrix\Main\Mail\Event::send([
            'EVENT_NAME' => 'COMPETITOR_PRICE_ALERT',
            'LID'        => SITE_ID,
            'C_FIELDS'   => ['MESSAGE' => $message],
        ]);
    }
}

Типичные ошибки при настройке мониторинга

• Использование инфоблоков для хранения — приводит к деградации производительности при >20 000 записей.
• Отсутствие индексов по полям product_id и checked_at — агент синхронизации выполняется часами вместо минут.
• Парсеры без обработки ошибок — при падении сайта конкурента агент падает с Exception, и синхронизация прерывается до ручного вмешательства.
• Слишком редкое обновление — при частоте раз в сутки вы пропускаете дневные колебания, которые могут составлять до 30%.

Что входит в работу по настройке нашего сервиса?

• Анализ вашего каталога и выбор оптимального источника данных (сервис или парсер).
• Создание таблиц или HL-блоков для хранения конкурентов, цен и истории.
• Разработка агента синхронизации с детальной обработкой ошибок (логирование, повтор при сбоях).
• Реализация модуля расчёта ценовой позиции с ранжированием.
• Вывод цен конкурентов в карточку товара административной панели и на витрину (по желанию).
• Настройка уведомлений по email или в Битрикс24.
• Документация по архитектуре и инструкция по обслуживанию.

Сроки и наши гарантии

Стоимость рассчитывается индивидуально на основе объёма каталога и сложности интеграции. Мы гарантируем стабильную работу агентов в течение 6 месяцев после сдачи. Оценим проект бесплатно — свяжитесь с нами, и мы предложим архитектуру под ваш бюджет. Получите консультацию по архитектуре мониторинга цен, и вы убедитесь, что автоматизация окупается за первые 2 месяца.

Более 10 лет опыта в разработке на Битрикс и Битрикс24, более 50 успешных интеграций с системами мониторинга цен — наш опыт позволяет решать задачи любой сложности.

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

Мы сталкиваемся с ситуацией, когда маркетолог запустил акцию «−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 день оценим проект.