Моніторинг цін конкурентів у 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-блоків для зберігання конкурентів, цін та історії.
• Розробка агента синхронізації з детальною обробкою помилок (логування, повтор при збоях).
• Реалізація модуля розрахунку цінової позиції з ранжуванням.
• Виведення цін конкурентів у картку товару адміністративної панелі та на вітрину (за бажанням).
• Налаштування сповіщень електронною поштою або в Бітрікс24.
• Документація з архітектури та інструкція з обслуговування.

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

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

Більше 10 років досвіду в розробці на Бітрікс та Бітрікс24, більше 50 успішних інтеграцій із системами моніторингу цін — наш досвід дозволяє вирішувати завдання будь-якої складності.

Ціни та знижки: коли акція дає −44% замість −20%

У нашій практиці поширена ситуація: маркетолог запустив акцію «−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) — конструктор умов без розробника, але з можливістю все зламати.

«Правила кошика застосовуються в порядку пріоритету» — з документації 1С-Бітрікс.

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

• Знижка від суми: 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. Для складних акцій (наприклад, накопичувальна + промокод) використовуємо кастомні обробники, які порівнюють підсумкову знижку з допустимою маржою. Це гарантує, що клієнт не піде зі збитковим чеком. Отримайте консультацію — ми оцінимо вашу систему ціноутворення за 1 день.

Накопичувальні знижки та програми лояльності

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

• Порогова — знижка зростає із сумою покупок. Простіше для клієнта та підтримки.
• Бальна — нарахування за покупки, оплата балами. Гнучкіше, але складніше у сприйнятті.
• Рівнева — срібний/золотий/платиновий. Гейміфікація утримує.
• Кешбек — повернення на внутрішній рахунок (b_sale_user_account).

Порогова система: приклад реалізації

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

Додаткові можливості:

• Повідомлення «Вам залишилося 3 200 руб. до золотого статусу» — через кастомний компонент в особистому кабінеті.
• Термін дії рівня — річний (перерахунок агентом CAgent) або безстроковий.
• Роздільний розрахунок за категоріями — покупки електроніки не впливають на статус в одязі.

Кейс з нашої практики: побутова техніка, 15 000 SKU

Ми налаштували накопичувальну програму для нашого клієнта — інтернет-магазину побутової техніки з товарною матрицею в 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.

Як ми налаштовуємо ціни та знижки: покроковий процес

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

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

• Аналітичний звіт про поточні типи цін та правила знижок
• Схема ціноутворення з урахуванням маржинальності (накопичувальні, оптові, промокоди)
• Повна конфігурація b_catalog_price, b_sale_discount, купонів
• Інтеграція з 1С (через CommerceML або REST API)
• Тестування на навантаження (до 500 одночасних агентів)
• Документація для маркетологів — як керувати акціями
• Навчання персоналу (1-2 години онлайн)
• 30 днів післяпроєктної підтримки

Строки

Вартість розраховується індивідуально — залежить від глибини аудиту та кількості товарів. Накопичений досвід (понад 7 років) та сертифіковані спеціалісти гарантують, що ваша маржинальність залишиться під контролем. Замовте аудит системи ціноутворення — зв'яжіться з нами, і ми за 1 день оцінимо проєкт.