Розробка гібридної системи модерації товарів маркетплейсу

Уявіть: маркетплейс випустив 10 000 товарів за тиждень, а модератор вручну перевіряє 50 на день. Результат — черга на 200 днів, продавці йдуть до конкурентів. Ми вирішуємо цю проблему гібридною системою модерації, яка балансує швидкість і якість. Наша команда має понад 10 років досвіду в розробці систем модерації для маркетплейсів та реалізувала більше 15 подібних проєктів.

Чому без модерації маркетплейс перетворюється на смітник?

Без автоматичної фільтрації картка товару перетворюється на хаос: дублі одного продукту, заборонені категорії, накручені характеристики, плагіат фото. Ручна перевірка гальмує онбординг продавців — термін схвалення сягає 2–3 дні. Автоматична без правил пропускає порушення. Компроміс — гібридна система: авто-перевірка для простих випадків, ручна — для складних.

Як прискорити перевірку в 10 разів?

Ми будуємо систему на Laravel + PostgreSQL + Redis з чергою на Horizon. Кожен товар отримує auto_moderation_score (0–1). Якщо поріг >0,85 і продавець перевірений, товар проходить автоматичне схвалення. Інші потрапляють в чергу з пріоритетом за категорією та датою. В інтерфейсі модератора — гарячі клавіші та batch-схвалення до 20 товарів одним кліком. Кейс: для маркетплейсу з 50 000 продавців середній час схвалення скоротився з 48 годин до 15 хвилин. Автоматична модерація працює в 10 разів швидше за ручну, економія витрат сягає 60%. Це в 4 рази швидше, ніж ручна перевірка. При обсязі 50 000 товарів на місяць система заощаджує до $12 000 на перевірці. За даними внутрішньої аналітики маркетплейсу.

products
  status: draft | pending | approved | rejected | suspended
  moderation_comment: text (nullable)
  moderated_by: user_id (nullable)
  moderated_at: timestamp (nullable)
  auto_moderation_score: float (0–1)

Черга модерації для модераторів

Інтерфейс модератора — окремий розділ в admin-панелі з фільтрами за категорією, продавцем, датою подачі. Модератор бачить:

• Фото товару (галерея, зум), назву, опис, атрибути
• Історію попередніх версій і причини попередніх відхилень
• Рейтинг продавця та кількість уже схвалених товарів
• Кнопки: схвалити / відхилити (з обов'язковим коментарем) / запросити правки

Гарячі клавіші та batch-схвалення прискорюють роботу: модератор може схвалити 10–20 однотипних товарів одного продавця однією дією після первинної перевірки. Це в 3 рази ефективніше за повністю ручну модерацію.

Автоматична пре-модерація

До потрапляння в чергу до модератора товар проходить автоматичні перевірки:

• Дублі за назвою/фото — пошук за хешем зображення (perceptual hash) і косинусною подібністю тексту
• Заборонені категорії та слова — словник заборонених термінів, regexp-перевірка
• Якість фото — мінімальна роздільна здатність 800×800, відсутність водяних знаків конкурентів (ML-модель на TensorFlow Serving)
• Коректність ціни — ціна не нижче собівартості категорії, не вище ринкового максимуму на N%
• Повнота картки — заповнені обов'язкові атрибути категорії

Товари з високим auto_moderation_score (>0,85) можуть проходити автоматичне схвалення для перевірених продавців.

Апеляції продавців та правки

Ми передбачили можливість апеляцій продавців. Після відхилення продавець отримує детальний коментар і може виправити товар. Виправлена версія потрапляє в окрему чергу "повторна перевірка" з позначкою змін — модератор бачить diff між версіями.

Сповіщення продавцю

• Email/push при зміні статусу
• Список відхилених товарів з причинами в особистому кабінеті
• Лічильник очікуючих перевірки на дашборді продавця

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

1. Аналіз — виявляємо вузькі місця в поточному процесі, заміряємо обсяг товарів і частоту порушень.
2. Проектування — модель даних, статуси, права доступу, схема черги.
3. Реалізація — розробка API (OpenAPI), інтерфейсу модератора, автоматичних правил, сповіщень.
4. Тестування — навантажувальне тестування черги (100 000 товарів на годину), A/B тестування авто-модерації.
5. Деплой і моніторинг — налаштування метрик (час схвалення, відсоток помилок), постановка алертів.

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

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

Орієнтовні терміни: від 3 до 6 тижнів залежно від складності автоматичних правил. Вартість проєкту починається від $10 000. Вартість розраховується індивідуально після аналізу вимог. Зв'яжіться з нами — оцінимо ваш проєкт за 2 дні та запропонуємо оптимальне рішення. Гарантуємо прозорість етапів і результат, підкріплений багаторічним досвідом розробки маркетплейсів.

Результати впровадження

Отримайте консультацію: напишіть на пошту або через форму на сайті — обговоримо деталі вашого проєкту. Замовте впровадження системи модерації, щоб скоротити витрати на перевірку товарів до 60%.

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