Парсинг цін із сайтів конкурентів для 1С-Бітрікс

Парсинг цін із сайтів конкурентів для 1С-Бітрікс

Моніторинг цін конкурентів — одна з небагатьох автоматизацій, яка дає прямий вимірюваний ефект на маржинальність. Без нього менеджери або не реагують на зміни, або витрачають години на ручний збір даних. Правильно налаштований парсер цін закриває це завдання з точністю до кількох годин.

Чим парсинг цін відрізняється від парсингу каталогу

Ключова відмінність — частота та обсяг. Каталог парситься рідко (раз на тиждень або при запуску). Ціни потрібно збирати кожні 2–6 годин на живій системі з тисячами позицій. Це означає:

• Немає часу на headless-браузер для кожного товару — потрібні швидкі HTTP-запити
• Ідентифікація товару критична — один і той самий товар на різних сайтах має різні URL
• Зберігання історії цін обов'язкове — тренд важливіший за поточне значення

Ідентифікація товарів конкурентів

Найскладніше технічне завдання — пов'язати свій SKU з карткою конкурента. Три підходи:

За артикулом/EAN: найнадійніше. Шукаємо артикул виробника в тексті сторінки конкурента. Працює, коли обидва продають одні й ті самі брендові товари.

За назвою: fuzzy-matching через similar_text() або Levenshtein. Потребує ручної верифікації першого запуску — багато хибних збігів.

За URL із зовнішніх баз: прайс-агрегатори (Яндекс.Маркет, Price.ru) часто надають прямі посилання на конкурентів із прив'язкою до моделі. Парсимо агрегатор як посередника.

Результат маппінгу зберігається у Highload-блоці CompetitorLinks:

UF_OWN_PRODUCT_ID → ID нашого елемента інфоблоку
UF_COMPETITOR_URL → URL картки конкурента
UF_COMPETITOR_NAME → ідентифікатор конкурента
UF_LAST_PRICE → остання зібрана ціна
UF_LAST_CHECK → дата останньої перевірки

Зберігання історії та аналітика

Поточну ціну у Highload-блоці зберігати можна, але історію — лише в окремій таблиці. Створюємо кастомну таблицю competitor_price_history:

CREATE TABLE competitor_price_history (
    id SERIAL PRIMARY KEY,
    own_product_id INT NOT NULL,
    competitor_name VARCHAR(100),
    price DECIMAL(12,2),
    currency CHAR(3),
    in_stock BOOLEAN,
    parsed_at TIMESTAMP DEFAULT NOW()
);
CREATE INDEX idx_cph_product ON competitor_price_history(own_product_id, parsed_at DESC);

Це дозволяє будувати графіки динаміки цін і знаходити патерни (наприклад, конкурент знижує ціни щоп'ятниці).

Автоматичне реагування на зміни

Після збору даних — бізнес-логіка. Варіанти реакції:

Сповіщення менеджера — через \Bitrix\Main\Mail\Event::send() при відхиленні ціни конкурента від нашої більш ніж на X%.

Автоматична зміна ціни — через CCatalogProduct::Update() з новим значенням у b_catalog_price. Потребує узгодження правил із бізнесом (мінімальна маржа, заборона опускатись нижче собівартості).

Прапорець для переоцінки — додаємо властивість NEEDS_REPRICING = Y до елемента інфоблоку, менеджер бачить список у адміністративній частині.

Кейс: моніторинг 5 конкурентів у ніші автозапчастин

Завдання: 4200 SKU, 5 конкурентів, оновлення кожні 4 години, автоматичне сповіщення при різниці > 7%.

Проблеми при реалізації:

• Два конкуренти використовували Cloudflare — довелось додати ротацію проксі та випадкові затримки
• Один сайт рендерив ціни через JS — для нього окремий воркер на Puppeteer з пулом у 3 інстанси
• Артикули у одного конкурента зберігались у нестандартному атрибуті data-sku

Підсумок: система збирає ~21 000 цінових точок за цикл (4200 × 5), вкладаючись у вікно 4 годин. Менеджер отримує дайджест відхилень вранці та ввечері.

Часові рамки робіт

Разом для 5 конкурентів: 6–10 робочих днів.