Розробка маркетплейсу: мультивендорна торгівля, комісії, модерація
Маркетплейс — це не інтернет-магазин з кількома продавцями. Це платформа, де бізнес-логіка будується навколо трьох сторін: покупець, продавець, платформа. Кожна транзакція торкається всіх троїх. Помилка в розрахунку комісії на 1000 замовлень у день — це фінансові розбіжності, які неможливо розгребти без окремого reconciliation процесу.
Мультиарендність: як розділяються дані
Дві основні моделі ізоляції даних продавців:
Shared database, shared schema — всі продавці в одних таблицях, кожна запис має vendor_id. Дешевше в інфраструктурі, простіше у розробці. Ризик: помилка у WHERE-умові — продавець бачить чужі замовлення. Обов'язково Row Level Security (RLS) на рівні PostgreSQL або глобальні scopes в ORM на всіх запитах.
Shared database, separate schema (PostgreSQL schemas) — у кожного продавця своя схема в одній базі. Ізоляція суворіша, але складніше cross-vendor операції (статистика платформи, пошук по всім товарам).
Для більшості маркетплейсів до 10 000 продавців — shared schema з RLS. Separate schema — для enterprise B2B з вимогами GDPR по ізоляції даних.
Фінансова механіка: комісії та виплати
Розрахунок комісії — найкритичніша частина, де помилки коштують грошей.
Правило перше: ніколи не зберігати комісію як похідну, завжди як факт. У момент створення замовлення фіксуємо: суму замовлення, відсоток комісії платформи у цей момент, абсолютне значення комісії, суму до виплати продавцю. Якщо завтра ви змінили ставку комісії — історичні замовлення повинні залишатися зі старими цифрами.
Моделі комісій:
- Фіксований відсоток (5% з кожної продажі)
- Диференційований по категоріям (електроніка 3%, одяг 8%)
- Tiered по обороту (до 100k — 10%, від 100k — 7%)
- Змішаний: % + фіксована сума за транзакцію
Stripe Connect — стандарт для маркетплейсів. Два режими: Destination charges (платформа приймає платіж, переводить продавцю) та Direct charges (платіж йде напрямку до продавця, платформа забирає комісію через application fee). Destination charges дає платформі більше контролю, включаючи утримання при спорах.
Onboarding продавця у Stripe Connect: KYC/AML перевірка через Stripe Identity або вбудований Stripe onboarding. Поки продавець не пройшов верифікацію — виплати заморожені. Продуманий UX цього процесу критичний для конверсії продавців.
Escrow та холдирування. Гроші з покупця списуються одразу, продавцю переводяться з затримкою (7–14 днів) після підтвердження отримання. Це захист від шахрайства та можливість утримання при спорах. Реалізується через capture_method: manual у Stripe та ручна capture після завершення угоди.
Каталог з мультивендорними товарами
Одна зі складних задач: один і той же товар може продаватися кількома продавцями. Два підходи:
Unified catalog (як Amazon): є єдина карточка товару (product), до якої прив'язані пропозиції різних продавців (offers) з різними цінами та залишками. Пошук та SEO по карточці, не по офферу. Складність: хто створює карточку, хто за неї відповідає, як резолвити конфлікти атрибутів від різних продавців.
Per-vendor catalog (як Avito): кожен продавець веде власні карточки незалежно. Дублікати — норма. Простіше у розробці та стосунках з продавцями, складніше для покупця (порівняння пропозицій).
Для нішевого B2B маркетплейсу — per-vendor простіше та швидше запускається. Для горизонтального retail з великою кількістю продавців — unified catalog дає кращий UX.
Складські залишки в реальному часі. Два покупці одночасно додають останній товар у корзину. Хто його купить? Optimistic locking при створенні замовлення: UPDATE inventory SET reserved = reserved + 1 WHERE product_id = ? AND (quantity - reserved) >= 1 — атомарна операція, другий запит повертає 0 затронутих рядків та отримує помилку «товар закінчився».
Модерація контенту
Маркетплейс несе відповідальність за контент продавців. Типові проблеми: поддільні товари, заборонені категорії, маніпуляція цінами, фейкові відзиви.
Moderation pipeline:
- Автоматичні перевірки при публікації: обов'язкові поля, відповідність категорії, обмеження за словами (стоп-ліст), дублікати через хеш зображення
- AI-класифікація: визначення категорії за текстом та зображенням, детекція забороненого контенту (Rekognition або Vertex AI Vision)
- Очередь ручної перевірки для flagged товарів
Статусна машина для товару: draft → pending_review → active / rejected → suspended. Кожен перехід — подія з причиною та модератором. Продавець отримує сповіщення з конкретною причиною відмови, а не «порушення правил».
Відзивив: верифікація покупки обов'язкова (відзив тільки від користувача з підтвердженим замовленням цього товару). Автоматичний детектор підозрілої активності: різкий ріст відзивів від аккаунтів з нульовою історією — флаг для ручної перевірки.
Dispute resolution: продавець та покупець не можуть самостійно урегулювати — арбітраж платформи. Часові обмеження на кожен етап (покупець відкриває спір протягом N днів, продавець відповідає протягом M днів). Інтеграція зі Stripe Disputes для автоматичної відповіді на chargeback.
Пошук та рекомендації
Пошук по маркетплейсу з різними продавцями та сотнями тисяч товарів — це Elasticsearch або OpenSearch, не SQL LIKE. Векторний пошук для семантики (див. AI категорія), фасетна фільтрація через агрегації Elasticsearch.
Персоналізована стрічка: клік, покупки, перегляди → колаборативна фільтрація або content-based рекомендації. A/B тестування алгоритмів ранжування обов'язкове — інтуїція тут поганий порадник.
Процес роботи
Маркетплейс — ітеративна розробка. MVP: реєстрація продавців, каталог товарів, корзина та checkout через Stripe Connect, базова модерація. Після запуску — дані про реальне використання визначають пріоритети наступних ітерацій.
Типовий порядок: MVP (3–4 місяці) → аналітика та зворотний зв'язок → перший розширений релізу (2–3 місяці) → масштабування та оптимізація.
Строки
MVP маркетплейсу (каталог, checkout, базові профілі продавців): 3–5 місяців. Повнофункціональний маркетплейс з модерацією, розширеною аналітикою, мобільним застосунком: 8–18 місяців. Додавання маркетплейс-функціональності до існуючого e-commerce: 2–5 місяців.