Уявіть: інтернет-магазин з 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 рази швидша за чернетку, але потребує повної довіри до джерела.
Процес роботи
- Аналітика — вивчаємо структуру парсера та полів CMS.
- Проектування — розробляємо схему мапінгу та черги.
- Реалізація — пишемо процесор на Python, валідатор за правилами, інтеграцію з CMS через API.
- Тестування — прогоняємо на історичних даних (10 000 записів), перевіряємо edge-кейси.
- Деплой — розгортаємо на продакшн, налаштовуємо моніторинг помилок.
Що входить в роботу
- Аналіз структури парсера та полів CMS
- Розробка схеми мапінгу
- Налаштування проміжної черги та валідації
- Інтеграція через API CMS
- Документація з конфігурації та підтримки
- Навчання редакторів роботі з чергою та модерацією
- Технічна підтримка на етапі запуску
- Також входить безкоштовна оцінка проекту та консультація
Строки
| Складність | Час |
|---|---|
| Одне джерело, базова валідація | 5–8 днів |
| Кілька джерел, UI мапінгу, модерація | 15–20 днів |
Пишіть нам для оцінки вашого проекту — ми підберемо оптимальну архітектуру інтеграції під ключ. Оцінка безкоштовна і займає 1 день.