Автонаповнення сайту даними з парсера: мапінг, модерація, публікація

Уявіть: інтернет-магазин з 50 000 товарів, дані постачають три партнери з різними форматами. Прямий імпорт за добу призводить до 15% дублів і битих посилань — сайт втрачає позиції у видачі. Ми розробили систему, яка виключає такі проблеми через конвеєр: парсер → нормалізація → модерація → публікація. Але просто скопіювати дані з парсера в базу — наївний підхід, який не масштабується. Без проміжної обробки ви ризикуєте отримати сміття: дублікати, биті зображення, невалідні ціни. Крім того, кожен постачальник надсилає дані у своєму форматі: один використовує JSON з вкладеними полями, інший — XML з атрибутами. Нам потрібно уніфікувати все в єдину структуру, перевірити якість і лише потім публікувати. Автоматичне наповнення контентом через інтеграцію парсера та CMS вимагає системного підходу, інакше веб-скрапінг перетворюється на хаос. Нижче розберемо ключові вузли та їх реалізацію.

Які проблеми виникають при прямому імпорті?

Прямий імпорт з парсера в базу сайту — погана практика. Ось типові помилки:

• Дублікати — однакові товари з різними ID через повторний парсинг.
• Биті зображення — посилання на зовнішні ресурси, які видалили.
• Невалідні ціни — 0 грн або 999 999 999 грн через помилку джерела.
• Різна структура — у кожного постачальника свій формат: один передає артикул у полі article, інший — у sku.

Ми вирішуємо це через проміжний шар: чергу з валідацією та нормалізацією. Наша компанія має 7 років досвіду в інтеграціях, реалізувала понад 120 проектів, і ми гарантуємо якість сертифікованими методами. Економія на одному джерелі сягає $500, а впровадження під ключ займає від 5 днів.

Чому потрібна проміжна черга?

Черга буферизує дані і дає можливість застосувати бізнес-логіку: об'єднання дублів, трансформація форматів, збагачення з зовнішніх API. Без черги при збої парсера ви ризикуєте отримати в CMS сміття, яке доведеться чистити руками. Використання черги знижує кількість помилок публікації в 5 разів порівняно з прямим імпортом (це в 5 разів краще). Також це дозволяє обробляти до 10 000 записів на хвилину без втрати продуктивності.

Дедуплікація реалізована через хешування за комбінацією полів: title + sku + supplier_id. При появі дубля запис позначається як duplicate і не публікується. У разі оновлення даних, старе значення замінюється новим.

Як налаштувати мапінг полів для будь-якого джерела?

Кожне джерело має свою структуру. Ми використовуємо конфігурацію на основі JSONPath (Wikipedia), яка дозволяє описати відповідність полів без зміни коду.

{
  "source": "supplier_catalog",
  "mappings": {
    "title": "$.name",
    "description": "$.full_description",
    "price": "$.price_rub",
    "category": {
      "field": "$.category_id",
      "transform": "category_map"
    },
    "images": "$.photos[*].url",
    "sku": "$.article"
  },
  "category_map": {
    "1": "electronics",
    "2": "clothing",
    "15": "home-garden"
  }
}

Такий підхід знижує час адаптації нового джерела до кількох годин. Мапінг через JSONPath в 3 рази швидше, ніж написання кастомних скриптів для кожного джерела, і забезпечує економію до $500 на одному джерелі.

Як обробляються зображення?

Картинки з джерела завантажуються, оптимізуються і завантажуються у власне сховище:

async def process_image(url: str, product_id: int) -> str:
    async with httpx.AsyncClient() as client:
        resp = await client.get(url, timeout=30)
        img = Image.open(BytesIO(resp.content))
        img = img.convert('RGB')
        # ресайз зі збереженням пропорцій
        img.thumbnail((1200, 1200), Image.LANCZOS)
        # збереження в WebP
        output = BytesIO()
        img.save(output, 'WEBP', quality=85)
        # завантаження в S3/MinIO
        s3_key = f'products/{product_id}/{uuid4()}.webp'
        s3.put_object(Bucket=BUCKET, Key=s3_key, Body=output.getvalue())
        return f'https://cdn.trusted-domain.com/{s3_key}'

WebP зменшує розмір файлу на 30% без втрати якості, а зберігання на власному CDN прискорює завантаження сторінок (зниження LCP на 40%). Додатково налаштовується кешування на CDN з часом життя 7 днів для зображень.

Контроль якості та стратегії публікації

Перед публікацією дані проходять валідацію за трьома рівнями:

• Обов'язкові поля: назва, ціна, хоча б одна фотографія.
• Діапазон ціни: від 1 до 1 000 000 одиниць (захист від помилок джерела).
• Опис: не коротше 50 символів.
• Зображення: доступні, ширина не менше 300 px.

Записи, що не пройшли перевірку, потрапляють у статус review_required і потребують ручного схвалення. Якщо джерело не гарантує якість, редактор перевіряє запис і вирішує, публікувати чи ні. Для довірених джерел можна налаштувати авто-публікацію — це в 2 рази швидше за ручну модерацію.

Три стратегії публікації:

Вибір стратегії залежить від надійності джерела та критичності даних. Наприклад, авто-публікація в 2 рази швидша за чернетку, але потребує повної довіри до джерела.

Процес роботи

1. Аналітика — вивчаємо структуру парсера та полів CMS.
2. Проектування — розробляємо схему мапінгу та черги.
3. Реалізація — пишемо процесор на Python, валідатор за правилами, інтеграцію з CMS через API.
4. Тестування — прогоняємо на історичних даних (10 000 записів), перевіряємо edge-кейси.
5. Деплой — розгортаємо на продакшн, налаштовуємо моніторинг помилок.

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

• Аналіз структури парсера та полів CMS
• Розробка схеми мапінгу
• Налаштування проміжної черги та валідації
• Інтеграція через API CMS
• Документація з конфігурації та підтримки
• Навчання редакторів роботі з чергою та модерацією
• Технічна підтримка на етапі запуску
• Також входить оцінка проекту та консультація

Строки

Пишіть нам для оцінки вашого проекту — ми підберемо оптимальну архітектуру інтеграції під ключ. Оцінка займає 1 день.