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

З чого почати розробку парсера для 1С-Бітрікс?

XMLReader, а не SimpleXML — вибір інструмента визначає долю проекту. SimpleXML завантажує весь XML у пам’ять, і при файлі постачальника на 800 МБ PHP впаде з fatal error на ліміті 512 МБ. XMLReader обробляє потоково, node за node, споживаючи 20–30 МБ — в 30 разів ефективніше. З цієї деталі стартує будь-яка розробка парсерів під Бітрікс. Ми робимо такі системи вже понад 10 років, реалізували 50+ проектів, і жоден не обходиться без правильного вибору парсера.

Проблеми, які вирішує парсинг

• Первинне наповнення каталогу — 15 000 карток з описами, характеристиками, фото. Вручну це три місяці контент-менеджера; парсер — тиждень з налагодженням. Економія часу — до 90%.
• Моніторинг цін конкурентів — збір даних з Ozon, Wildberries, сайтів конкурентів. Конкурент знизив ціну на ходову позицію — дізнаєтеся через дві години, а не через два тижні. Окупається за 2–3 місяці.
• Агрегація постачальників — п’ять прайсів у різних форматах (CSV з CP1251, XML у CommerceML, Excel з об’єднаними комірками) перетворюються на єдиний каталог із загальною системою властивостей інфоблоку.
• Збагачення карток — підтягуємо характеристики, інструкції, 3D-моделі з сайтів виробників. Без цього картка товару — пустушка для SEO.
• Оновлення асортименту — товари, які зникли з фіду постачальника, деактивуються через CIBlockElement::Update($ID, ['ACTIVE' => 'N']). Нові — створюються. Каталог синхронізовано.

Інструменти для розробки парсерів

Статичні сайти — PHP (Goutte, Symfony DomCrawler) або Python (Scrapy, lxml). Швидкість: 50–100 сторінок/сек. Вистачає для каталогів без JS-рендерингу.

SPA та динамічні сайти — Puppeteer або Playwright. Нескінченний скрол, AJAX-фільтри, lazy-load картинок — headless-браузер все це обробить. Швидкість падає до 1–10 сторінок/сек, але альтернативи немає: дані існують лише після виконання JavaScript.

Файли постачальників:

• Excel (XLS, XLSX) — PhpSpreadsheet. Обережно з об’єднаними комірками та формулами — вони ламають автоматичний мапінг.
• CSV — fgetcsv() з правильною кодуванням. Постачальники люблять CP1251, BOM у UTF-8 та крапку з комою замість коми. Все це потрібно детектувати та обробляти.
• XML/YML — XMLReader для великих файлів, SimpleXML для фідів до 50 МБ.
• CommerceML — стандартний формат обміну з 1С. Розбираємо import.xml та offers.xml, мапимо на структуру інфоблоків.

API — REST-ендпоінти постачальників, API маркетплейсів (Ozon Seller API, Wildberries API). Працюємо в рамках rate limits, обробляємо пагінацію.

Як влаштований пайплайн автонаповнення?

Чотири етапи. Кожен може зламатися по-своєму.

1. Збір. Парсер обходить джерела по cron-розкладу. Сирі дані пишемо в проміжну таблицю — не одразу в b_iblock_element. Логуємо все: скільки сторінок обійшли, скільки елементів розпарсили, де отримали 403 або timeout. Без логів налагодження парсера — ворожіння на кавовій гущі.

2. Нормалізація. Тут основна робота:

   • Очищення HTML-тегів, зайвих пробілів, Unicode-сміття
   • Одиниці виміру: «мм» → «мм», «millimeters» → «мм», «миллиметр» → «мм»
   • Мапінг категорій постачальника → розділи інфоблоку Бітрікс. В одного постачальника «Ноутбуки», в іншого «Ноутбуки та планшети», у третього «Laptops» — все в одну секцію
   • Дедуплікація за артикулом, EAN/GTIN. Один товар від трьох постачальників не повинен з’явитися тричі

3. Завантаження в Бітрікс. Через CIBlockElement::Add() для нових елементів, CIBlockElement::Update() для існуючих. Зображення: завантажуємо, ресайзимо через CFile::ResizeImageGet(), конвертуємо в WebP. Властивості — через CIBlockElement::SetPropertyValuesEx(). SEO-мета через \Bitrix\Iblock\InheritedProperty\ElementValues. ЧПУ генеруємо з транслітерації назви.

4. Оновлення. Ключовий момент — не затерти ручні правки контент-менеджера. Оновлюємо лише ціну, залишки, активність. Опис та фото, доопрацьовані вручну, позначаємо прапорцем UF_MANUAL_EDIT у властивостях елемента і пропускаємо при імпорті. Товари, що зникли з фіду — деактивуємо, але не видаляємо.

Моніторинг цін конкурентів: необхідність та реалізація

Окрема підсистема зі своєю специфікою:

Результат — дашборд: ваш товар vs конкуренти, історія цін, тренди. Менеджер бачить, де можна підняти ціну без втрати позиції, а де потрібно реагувати.

Модуль імпорту CSV/XML: налаштування під ваш формат

Для файлів від постачальників — кастомний модуль з адмінкою:

• Налаштовуваний мапінг: «колонка B у файлі → властивість BRAND інфоблоку»
• Автодетект кодування (CP1251, UTF-8, UTF-16) через mb_detect_encoding() з перевіркою
• Завантаження зображень за URL з чергою агентів Bitrix — щоб не забити канал
• Інкрементальне оновлення за хешем рядка: змінився рядок — оновлюємо, ні — пропускаємо
• Cron-розклад, звіт: створено 145, оновлено 892, помилок 3 (з деталями)

Великі файли: CSV обробляємо батчами по 1000 рядків через fgetcsv(), XML потоково через XMLReader, фонове виконання через чергу агентів Бітрікс — ніяких PHP-таймаутів.

Правова сторона — що важливо врахувати

• robots.txt — поважаємо. Crawl-delay — дотримуємося.
• Частота запитів — 1–2 в секунду, не більше. Не потрібно DDoS-ити чужий сайт.
• Контент виробників — використовуємо. Унікальні авторські тексти — не копіюємо.
• Персональні дані — не збираємо.

Що входить в розробку парсера під ключ?

Скільки часу займає розробка парсера?

Процес і терміни:

1. Прототип — парсер для 1–2 джерел за 2–3 дні. Оцінюємо якість даних, підводні камені (захист Cloudflare, капча, динамічне підвантаження).
2. Розробка — повний пайплайн: парсер → нормалізація → імпорт в Бітрікс → адмінка для управління.
3. Тестування — проганяємо на повному обсязі каталогу, перевіряємо edge-кейси (порожні поля, кривий HTML, биті картинки).
4. Запуск — налаштовуємо cron, моніторинг помилок через Telegram-бот.
5. Підтримка — конкурент переробив верстку? Оновлюємо CSS-селектори в парсері.

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