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

У нашій практиці інтернет-магазин на 1С-Бітрікс без даних про конкурентів швидко втрачає позиції за ціною та асортиментом. Уявіть: 3000 SKU в каталозі, три прямі конкуренти, ручний моніторинг забирає 20 годин на тиждень. Один конкурент знизив ціну на топову модель — ви дізнаєтеся про це через тиждень, втративши до 15% продажів. Ручний моніторинг 500+ товарів нерентабельний — потрібна автоматизація. Ми маємо 10+ років досвіду в розробці парсерів та інтеграції з 1С-Бітрікс, реалізували понад 50 проєктів. Ми пропонуємо парсер, який збирає товарні дані з сайтів конкурентів і завантажує їх в окремий інфоблок Бітрікса для аналізу та автоматичних дій. Середня економія бюджету на аналітиці становить до 30%, що може становити до 15 000 грн на місяць. Оцінимо ваш проєкт за 1 день — пишіть.

Критичність парсингу конкурентів для інтернет-магазину на Бітріксі

Без актуальної інформації ви ризикуєте програти в ціні або упустити новинки. Автоматизований парсинг конкурентів забезпечує моніторинг цін у реальному часі, відстежуючи зміни у 3–5 конкурентів і формуючи зведення відхилень. Це дозволяє реагувати швидше, ніж конкуренти — автоматизація парсингу в 5 разів скорочує час моніторингу порівняно з ручним збором. Швидкість реакції безпосередньо впливає на конверсію.

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

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

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

Зберігати дані конкурентів прямо в основному каталозі — погана практика: засмічує b_iblock_element, ламає індекси пошуку. Краще використовувати окремий інфоблок з прив'язкою через XML_ID. Як зазначається в документації 1С-Бітрікс: зберігання зовнішніх даних в окремому інфоблоці забезпечує продуктивність основного каталогу.

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

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

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

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

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

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

Вплив автоматизації парсингу на конверсію

Швидке реагування на зміну цін конкурента дозволяє утримувати позиції у видачі та не втрачати клієнтів. Парсер завантажує оновлення в інфоблок, і агент Бітрікса формує зведення відхилень >5% для менеджера. Зниження витрат на ручний збір даних — до 80%.

Що збираємо

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

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

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

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

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

Реалізація:

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

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

{ "competitor": "rozetka.com.ua", "type": "static", "selector": ".price-current", "interval_hours": 6, "proxy_pool": ["proxy1", "proxy2"] } 

Уникнення засмічення основного каталогу даними конкурентів

Використовуйте окремий інфоблок COMPETITORS_CATALOG без дублювання елементів у b_iblock_element. Зв'язуйте через XML_ID — це чисте рішення без втрати продуктивності. Ми застосовуємо такий підхід у всіх проєктах — він гарантує цілісність основного каталогу.

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

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

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