Автоматична синхронізація каталогу з Ozon, WB, Яндекс.Маркет

Автоматична синхронізація каталогу з Ozon, WB, Яндекс.Маркет

Автоматична синхронізація каталогу з Ozon, Wildberries та Яндекс.Маркет вирішує проблему розсинхронізації товарів. Уявіть: у вас 5000 SKU, три маркетплейси, а менеджери вручну правлять описи та ціну. Через місяць розсинхронізація: на Ozon товару немає, на Wildberries ціна застаріла, на Яндекс.Маркеті фото не те. Щодня менеджери витрачають години на перевірку карток, а клієнти скаржаться на дублікати та невірні залишки. Ця ситуація знайома багатьом: за нашою статистикою, ручне управління каталогом на трьох майданчиках займає до 20 годин на тиждень і дає 15–20% помилкових карток. Наша команда інженерів з досвідом в e-commerce понад 7 років реалізувала понад 50 проектів з інтеграції каталогів з маркетплейсами. Система автоматично передає нові товари, оновлює зміни та знімає з продажу видалені позиції — без ручної праці. Ми використовуємо детектор змін на основі хешування, що дозволяє обробляти 10 000 товарів за 15 хвилин — у 5 разів швидше, ніж повний перебір.

Згідно документації Ozon

Чому ручна синхронізація не працює?

Кожен маркетплейс має свій формат даних: Ozon вимагає унікальний ідентифікатор у полі offer_id, Wildberries використовує артикул, Яндекс.Маркет — свій SKU. Категорії та атрибути відрізняються: на Ozon потрібно вказати тип товару (наприклад, 'Взуття' в категорії 17032750), а на Wildberries — прив'язатися до предмета. Ручний маппінг 5000 товарів займає тиждень і дає 20% помилок. Автоматизація з нашим маппером скорочує час до 3 годин і знижує помилки до 1%.

Як працює детектування змін?

Використовуємо хешування полів: назва, опис, бренд, ціна, зображення, розміри. При кожному оновленні продукту у вашій CMS або ERP обчислюється SHA-256 хеш і порівнюється зі збереженим у таблиці marketplace_product_mappings. Якщо хеш відрізняється — товар потрапляє в чергу на синхронізацію. Це дозволяє знизити навантаження на API маркетплейсів: типовий магазин з 10 000 товарів і 100 змінами на день робить лише 100 запитів замість 10 000. Для прискорення ми використовуємо черги Laravel Horizon із затримками між запитами, щоб не перевищувати ліміти (наприклад, у Wildberries — 1 запит/сек).

Чому маппінг категорій — вузьке місце?

Без маппінгу категорій вивантажити товар неможливо: у кожного майданчика своє дерево. Ми зберігаємо відповідність у БД і даємо UI для зв'язування. Для Ozon використовуємо пошук категорій за назвою через API. Для Wildberries — ручний маппінг з автодоповненням. Приклад:

class CategoryMapper
{
    public function getMarketplaceCategory(int $siteCategoryId, string $marketplace): ?int
    {
        return DB::table('category_mappings')
            ->where('site_category_id', $siteCategoryId)
            ->where('marketplace', $marketplace)
            ->value('marketplace_category_id');
    }

    public function suggestOzonCategory(string $categoryName): array
    {
        return Http::withHeaders($this->ozonHeaders)
            ->post('https://api-seller.ozon.ru/v1/description-category/search', [
                'language' => 'DEFAULT',
                'query'    => $categoryName,
            ])
            ->json('result');
    }
}

Процес роботи: від аудиту до деплою

1. Аналітика — розбираємо поточні інтеграції (CMS, ERP, API маркетплейсів).
2. Проектування — схема даних, маппінг, черги завдань (Laravel Horizon + Redis).
3. Реалізація — пишемо адаптери для кожного маркетплейсу з використанням REST API.
4. Тест — перевіряємо на копії каталогу: детектування змін, обробка помилок, навантаження.
5. Деплой — розгортаємо на вашому сервері або хмарі (AWS, Vercel).

Що входить в підсумкове рішення?

Крім адаптерів, ми поставляємо дашборд моніторингу на основі Laravel Telescope. Він відображає кількість активних, очікуваних та помилкових товарів по кожному маркетплейсу. Якщо кількість помилок перевищує 5% від загальної кількості товарів, система надсилає сповіщення в Telegram або Slack. Також ми налаштовуємо логування всіх операцій в таблиці sync_logs для аудиту.

-- Поточний стан каталогу по маркетплейсах
SELECT
    marketplace,
    COUNT(*) FILTER (WHERE status = 'active')  AS active,
    COUNT(*) FILTER (WHERE status = 'pending') AS pending,
    COUNT(*) FILTER (WHERE status = 'error')   AS errors,
    MAX(last_synced_at) AS last_sync
FROM marketplace_product_mappings
GROUP BY marketplace;

Терміни та що входить в роботу

Разом: 18–24 робочих дні. Гарантія на підтримку — 1 місяць після здачі. У вартість входить документація, налаштування дашборду та навчання співробітників. Така автоматизація дозволяє заощадити від 30 000 до 50 000 рублів щомісячно на ручному управлінні.

Порівняння вимог маркетплейсів

Типові помилки при синхронізації

Невірний маппінг категорій — товар йде не туди. Рішення: завантажити пробну партію та перевірити вручну.

Перевищення лімітів API — маркетплейси блокують. Рішення: queue із затримками та retry через 5 хвилин.

Різні формати зображень — майданчики вимагають певні розміри. Рішення: налаштувати пресети стиснення.

Отримайте консультацію з автоматизації каталогу вже сьогодні. Зв'яжіться з нами, і ми підготуємо індивідуальне рішення.

Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 1000 замовлень на день — це фінансові розбіжності, які неможливо розібрати без окремого reconciliation-процесу. Навіть при середньому навантаженні 500 замовлень на добу неправильна модель виплат призводить до втрати до 15% виручки платформи. Ми вирішили цю проблему для 50+ проектів — від нішевих B2B до горизонтальних retail-маркетплейсів. Процес розробки маркетплейсів вимагає детального опрацювання архітектури розрахунків та ізоляції даних.

Як побудувати надійну мультивендорну платформу?

Як уникнути розбіжностей у розрахунках комісій

Розрахунок комісії — найкритичніша частина, де помилки коштують грошей. Правило перше: ніколи не зберігати комісію як похідну, завжди як факт. У момент створення замовлення фіксуємо: суму замовлення, відсоток комісії платформи в цей момент, абсолютне значення комісії, суму до виплати продавцю. Якщо ви зміните ставку — історичні замовлення залишаться з колишніми цифрами.

Моделі комісій (використовуємо одну з або комбінуємо):

Ми використовуємо Stripe Connect як базовий стандарт. Режим Destination charges дає платформі контроль над виплатами, включаючи утримання при спорах. Onboarding продавця проходить через Stripe Identity: KYC/AML перевірка обов'язкова, поки продавець не верифікований — виплати заморожені. Продуманий UX цього процесу критичний для конверсії продавців — у наших проектах ми досягли конверсії 80% при реєстрації.

Чому архітектура мультиарендності критична для ізоляції даних

Перший крок — вибір архітектури мультиарендності. У shared-schema режимі всі продавці в одних таблицях з vendor_id. Ми обов'язково впроваджуємо Row Level Security на рівні PostgreSQL та глобальні scopes в ORM (Laravel, Rails, Django). Це гарантує, що продавець не побачить чужих замовлень навіть при помилці розробника. Для enterprise-проектів з жорсткими вимогами GDPR використовуємо окремі схеми PostgreSQL — ізоляція строгіша, але cross-vendor аналітика складніша.

Як реалізувати складські залишки без race condition

Два покупці одночасно додають останній товар у кошик. Хто його купить? Застосовуємо optimistic locking при створенні замовлення:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Атомарна операція — другий запит поверне 0 зачеплених рядків та отримає помилку «товар закінчився». Типова схема для високонавантажених маркетплейсів.

Який підхід до каталогу товарів обрати: unified чи per-vendor?

Порівняння підходів до каталогу товарів:

Для нішевого B2B маркетплейсу ми частіше обираємо per-vendor — швидше запускається. Для горизонтального retail з сотнями продавців — unified-каталог дає кращий UX.

Пайплайн модерації: автоматика та ручна верифікація

Маркетплейс несе відповідальність за контент продавців. Типові проблеми: підроблені товари, заборонені категорії, маніпуляція цінами, фейкові відгуки. Вибудовуємо трирівневий пайплайн:

1. Автоматичні перевірки при публікації: обов'язкові поля, відповідність категорії, стоп-лист слів, дублікати через хеш зображення.
2. AI-класифікація (Amazon Rekognition або Vertex AI Vision) — детекція забороненого контенту та визначення категорії.
3. Черга ручної перевірки для flagged товарів.

Статусна машина: draft → pending_review → active / rejected → suspended. Кожен перехід — подія з причиною та модератором. Продавець отримує сповіщення з конкретною причиною відмови, а не «порушення правил». Верифікація відгуків обов'язкова — тільки після підтвердженого замовлення. Автоматичний детектор флагує різке зростання відгуків від акаунтів з нульовою історією.

Пошук та рекомендації

Пошук по маркетплейсу з різними продавцями та сотнями тисяч товарів — це Elasticsearch або OpenSearch, не SQL LIKE. Векторний пошук для семантики, фасетна фільтрація через агрегації. Персоналізована стрічка на основі колаборативної фільтрації. A/B тестування алгоритмів ранжування обов'язкове — інтуїція тут поганий порадник.

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

Маркетплейс — ітеративна розробка. MVP: реєстрація продавців, каталог товарів, кошик та checkout через Stripe Connect, базова модерація. Після запуску — дані про реальне використання визначають пріоритети наступних ітерацій.

Типовий порядок:

• MVP (3–4 місяці)
• Аналітика та зворотний зв'язок
• Перший розширений реліз (2–3 місяці)
• Масштабування та оптимізація

Терміни та вартість

• MVP маркетплейсу (каталог, checkout, базові профілі продавців): 3–5 місяців.
• Повнофункціональний маркетплейс з модерацією, розширеною аналітикою, мобільним додатком: 8–18 місяців.
• Додавання маркетплейс-функціональності до існуючого e-commerce: 2–5 місяців.

Вартість розробки розраховується індивідуально після аудиту вимог. Точну оцінку надамо на безкоштовному передпроектному обстеженні.

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

• Проектна документація: архітектура, схеми даних, API-специфікації (OpenAPI).
• Доступи до репозиторію, CI/CD, документації з розгортання.
• Навчання команди замовника роботі з платформою.
• Технічна підтримка протягом першого місяця після запуску.

Ми гарантуємо коректність фінансових розрахунків та конфіденційність даних. Архітектурні принципи, на яких ми ґрунтуємося, підтверджені досвідом 10+ років та 50+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.