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

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

Інтернет-магазин без актуальних даних про конкурентів втрачає позиції за ціною та асортиментом. Ручний моніторинг 500+ товарних позицій нерентабельний. Завдання вирішується парсером, який збирає товарні дані із сайтів конкурентів та завантажує їх в інфоблок 1С-Бітрікс для подальшого аналізу або автоматичного реагування.

Архітектура рішення

Парсер конкурентів — це окремий модуль, який не торкається основного каталогу напряму. Типова схема:

1. Збирач — PHP/Python-скрипт з Guzzle або Symfony HttpClient, обходить сторінки конкурента
2. Проміжне сховище — окремий інфоблок COMPETITORS_CATALOG або таблиця в БД
3. Аналітична прошарка — порівняння з b_catalog_price свого магазину
4. Тригер дій — зміна ціни через CCatalogProduct::Update() або сповіщення менеджеру

Зберігати дані конкурентів безпосередньо в основному каталозі — погана практика: засмічує b_iblock_element, ламає індекси пошуку.

Технічні складнощі та як їх обходити

Захист від парсингу — головна перешкода. Великі магазини використовують Cloudflare, динамічне підвантаження через JS (React/Vue SPA) та капчі. Проти статичних сайтів працює простий curl з ротацією User-Agent. Проти JS-рендерингу потрібен headless-браузер: Puppeteer через Node.js або Playwright.

Стек для JS-сайтів:

Playwright → stdout JSON → PHP читає через exec() → CIBlockElement::Add()

Нестабільна структура HTML — конкурент змінив верстку, парсер впав. Рішення: CSS-селектори замість XPath там, де структура плоска, і обов'язковий моніторинг з алертом при нульовому результаті вибірки.

Блокування IP — ротація через проксі-пул (residential proxies). Мінімум 10–15 IP у пулі для каталогу 1000+ позицій. Частота запитів: не частіше 1 запиту на 3–5 секунд на домен.

Що збираємо

Типовий набір даних для парсингу конкурентів:

• Назва товару та артикул
• Поточна ціна (основна + знижкова)
• Наявність / кількість
• Посилання на товар-джерело
• Дата останнього оновлення

У 1С-Бітрікс це відображається на властивості інфоблоку. Рекомендую додати властивість COMPETITOR_URL типу «Рядок» і COMPETITOR_PRICE_DATE типу «Дата» — для відстеження актуальності даних.

Кейс: магазин електроніки, 3 конкуренти

Завдання: відстежувати ціни 2400 SKU у трьох конкурентів, оновлювати дані раз на 6 годин.

Реалізація:

• Парсер на PHP + Guzzle для двох конкурентів зі статичним HTML
• Puppeteer для третього (JS-SPA на Vue)
• Cron кожні 6 годин, почерговий запуск за конкурентами з паузою 2 години між ними
• Інфоблок COMPETITORS_PRICES з прив'язкою до основного каталогу через XML_ID
• Агент 1С-Бітрікс запускає порівняння і формує звіт у Highload-блок

Результат: час реакції на зміну ціни конкурента — 6 годин замість ручного моніторингу раз на тиждень. Менеджер отримує зведення відхилень > 5% на email через модуль \Bitrix\Main\Mail\Event.

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

Разом для 3 конкурентів з різними технологіями — 5–8 робочих днів. Підтримка парсера після запуску обов'язкова: верстка конкурентів змінюється.