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

Ціновий моніторинг конкурентів: від ручного збору до автоматизації

Ви втрачаєте прибуток, коли конкуренти змінюють ціни, а ви дізнаєтеся про це через тиждень. Ручний моніторинг — це не лише години роботи менеджерів, а й втрачена вигода. Парсинг цін для 1С-Бітрікс — одна з небагатьох автоматизацій, яка дає прямий вимірний ефект на маржинальність. Правильно налаштований парсер цін вирішує це завдання з точністю до кількох годин. Наш досвід — 10+ років у Бітрікс, понад 50 проєктів з моніторингу конкурентів. Економія бюджету до 30% і часу — до 10 годин на тиждень. Ми гарантуємо, що система працюватиме стабільно завдяки сертифікованим рішенням та багаторічному досвіду.

Парсинг цін у 5 разів ефективніший за ручний моніторинг. Вартість налаштування парсингу для одного конкурента — від $500.

Як працює парсинг цін?

Парсинг цін для інтернет-магазину на 1С-Бітрікс — це не просто збір чисел. Це повноцінний інструмент конкурентної розвідки, який потребує грамотної архітектури: ідентифікація товарів, зберігання історії, автоматична реакція. Нижче розберемо ключові технічні складності та рішення.

Відмінності парсингу цін від парсингу каталогу

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

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

Як ідентифікувати товар на сайті конкурента?

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

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

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

За 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%. Наша система в 3 рази швидша за ручний моніторинг і забезпечує повну точність.

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

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

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

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

• Аналіз сайтів конкурентів і підготовка документації.
• Налаштування доступів до сервера та системи.
• Розробка парсерів з урахуванням захисту (Cloudflare, JS).
• Інтеграція з 1С через CommerceML.
• Навчання менеджерів роботі зі сповіщеннями.
• Технічна підтримка протягом 3 місяців після запуску.

Налаштування парсингу за 5 кроків

1. Аналіз конкурентів: визначаємо список сайтів, їх захист і структуру сторінок.
2. Вибір методу ідентифікації: артикул, fuzzy-matching або зовнішні бази.
3. Розробка парсерів: пишемо модулі для кожного конкурента з урахуванням їх особливостей.
4. Зберігання даних: налаштовуємо Highload-блок і таблицю історії.
5. Автоматизація реакцій: підключаємо сповіщення або авторепрайсинг.

Кожен крок може бути адаптований під ваш асортимент. Замовте консультацію з парсингу цін — ми проаналізуємо ваших конкурентів і запропонуємо архітектуру рішення.

Обсяг робіт

Таймлайн робіт

Разом для 5 конкурентів: 6–10 робочих днів. Зв'яжіться з нами для оцінки вашого проєкту — підберемо оптимальне рішення під ключ. Ми працюємо на ринку більше 5 років, маємо сертифікати 1С-Бітрікс і гарантуємо якість на кожному етапі.