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

Відгуки на картці товару підвищують конверсію, але збирати їх вручну — довго та неефективно. Уявіть: у вас 500 товарів, кожен з відгуками на 5 майданчиках. Ручний збір займе тижні, а дублі зламають аналітику. Автоматизація збору скорочує витрати на ручну працю та дозволяє заощадити бюджет. Ми автоматизуємо збір відгуків із зовнішніх майданчиків (Яндекс.Маркет, OZON, Wildberries, Google Maps) та інтегруємо їх у ваш 1С-Бітрікс. При цьому важливо розрізняти два принципово різних сценарії: парсинг відгуків на товари (для інтернет-магазинів) і відгуків на компанію (для сервісів). Для кожного потрібна своя архітектура — від вибору джерела до схеми зберігання в Highload-блоках.

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

Як зберігати парсені відгуки в 1С-Бітрікс?

Бітрікс має вбудований модуль відгуків (vote), але для імпортованих відгуків зручніше Highload-блок. Приклад схеми:

Таблиця ExternalReviews:

UF_PRODUCT_ID — прив'язка до елементу інфоблоку (або 0 для відгуків на компанію)
UF_SOURCE — 'yandex_market' | 'ozon' | 'google' | '2gis'
UF_AUTHOR — ім'я автора
UF_RATING — оцінка (1–5)
UF_TEXT — текст відгуку
UF_DATE — дата відгуку на майданчику
UF_SOURCE_ID — унікальний ID відгуку на джерелі
UF_ACTIVE — модерація (Y/N)

Поле UF_SOURCE_ID — захист від дублів при повторних запусках парсера. Для кожного джерела свій формат ID, але в Highload-блоці зберігаємо рядком. Для великих обсягів (сотні тисяч відгуків) накладаємо індекс на UF_SOURCE та UF_SOURCE_ID. Детальніше про Highload-блоки.

Як парсити відгуки з Яндекс.Маркету?

Яндекс.Маркет активно захищається від парсингу. Працюючі підходи на поточний момент:

• Офіційний Partner API — якщо ви продавець на маркеті, відгуки доступні через API. Найнадійніший шлях.
• Headless-парсинг — Playwright з ротацією проксі. Сторінка відгуків завантажується через AJAX; потрібно дочекатися рендеру компонента [data-zone-name="reviews"].
• Мобільна версія — m.market.yandex.ru простіше в парсингу, менше захисту, відгуки в простішому HTML.

Для кожного підходу оцінюємо стабільність: Partner API стабільний, але вимагає статусу продавця; headless менш стабільний через антибот-системи.

Як парсити відгуки з OZON та Wildberries?

OZON: у Network DevTools видно XHR-запити до /api/v1/review/ — можна звертатися напряму, передаючи cookie сесії. Працює, доки не зміниться авторизаційна схема.

Wildberries: публічний endpoint для відгуків — https://feedbacks.wildberries.ru/api/v1/feedbacks?imtId={id}. Параметр imtId — внутрішній ID товару WB, його потрібно знайти на сторінці товару.

Обидва майданчики не мають офіційного API для відгуків (на момент написання), тому можливі зміни. Ми використовуємо ротацію проксі та обробку помилок для підвищення відмовостійкості.

Чому важлива модерація?

Не показуйте парсингові відгуки без модерації — серед них можуть бути негативні або нерелевантні. Прапор UF_ACTIVE = N за замовчуванням, менеджер перевіряє в адміністративній частині.

Для відображення створюємо компонент на основі bitrix:main.include або кастомний, який читає з Highload-блоку з фільтром UF_ACTIVE = Y. Виводимо рейтинг у мікророзмітці schema.org/Review — це впливає на снипети в пошуку.

З нашої практики: агрегація відгуків для мережі ресторанів

Завдання: зібрати відгуки з Google Maps, Яндекс.Карт та 2GIS для 12 точок, оновлювати щотижня.

Реалізація:

• Google Maps: офіційний Places API (безкоштовна квота 5 запитів/сек)
• Яндекс.Карти: Playwright + проксі-пул (API організацій закрито)
• 2GIS: undocumented API https://public-api.reviews.2gis.com/v1/reviews — працює без авторизації
• Highload-блок з прив'язкою до інфоблоку «Ресторани» через UF_BRANCH_ID

Результат: 847 відгуків агреговано при першому запуску, 60–80 нових щотижня. Середній рейтинг та блок останніх відгуків виведено на кожній сторінці ресторану. Клієнт відзначив зростання конверсії на 15% після впровадження.

Порівняння методів парсингу

Що входить в нашу роботу?

• Документація щодо схеми зберігання та інтеграції
• Доступ до адмін-інтерфейсу модерації відгуків
• Навчання адміністраторів (1 година)
• Підтримка протягом 30 днів після запуску
• Налаштування агентів для автоматичного оновлення відгуків

Як замовити інтеграцію парсингу відгуків?

1. Зв'яжіться з нами — опишіть майданчики, кількість товарів/точок та частоту оновлення.
2. Ми оцінимо проєкт і запропонуємо терміни (зазвичай від 7 до 15 робочих днів). Вартість інтеграції залежить від обсягу, обговорюється індивідуально.
3. Після узгодження починаємо розробку.
4. Перед запуском проводимо тестування та навчання.

Типові помилки при парсингу

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

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

З чого почати розробку парсера для 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-селектори в парсері.

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