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

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

Ми розробляємо вітрину та кабінет продавця для маркетплейса. Поганий інтерфейс — це тижневий онбординг, потік звернень у підтримку та відтік постачальників. Наша команда створює модулі, які скорочують час внесення товарів до 2 годин, а обробку замовлень — до хвилин. Типові болі: продавці витрачають години на заповнення карток, не бачать актуальні залишки, втрачають замовлення в статусах. Наше рішення — модуль із динамічними формами, матеріалізованими метриками та API для інтеграції служб доставки. Наприклад, для замовника із сегменту DIY ми розробили кабінет, де продавець завантажує 500+ товарів за 15 хвилин через Excel-шаблон з валідацією. Це дозволило скоротити time-to-listing на 70%. У цій статті розберемо архітектуру, ключові розділи, масовий імпорт, дашборд із живими метриками, обробку замовлень, права доступу та строки розробки. Ви отримаєте готову roadmap для реалізації модуля. Замовте консультацію — оцінимо проєкт безкоштовно.

Як влаштована архітектура кабінету продавця?

Кабінет продавця — окреме SPA або набір сторінок, ізольованих від покупецької частини. Він працює в рамках тієї ж кодової бази (Laravel/Node.js), але через окремий middleware-стек із перевіркою ролі seller та прив'язкою до shop_id. Розділи: дашборд із метриками (виручка, замовлення, конверсія, рейтинг), управління товарами (створення, редагування, масовий імпорт через Excel/CSV), управління замовленнями (статуси, трекінг, етикетки), фінанси (баланс, історія виплат), налаштування магазину (опис, логотип, політики повернення).

Вітрина продавця (публічна сторінка)

Публічна вітрина — /shop/{slug} із добіркою товарів, інформацією про продавця та блоком рейтингу. Генерується на сервері для SEO. Включає агреговані дані: середній рейтинг, кількість відгуків, відсоток викупу. Фільтрацію та пошук всередині магазину, кнопку підписки на магазин, блок останніх відгуків із відповідями продавця.

Як реалізувати масовий імпорт товарів без downtime?

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

category_attributes (category_id, attribute_name, type, required, options)
product_attribute_values (product_id, attribute_id, value)

Масовий імпорт через чергу: файл завантажується на S3, задача розбирає його рядок за рядком, створює товари та фото. Звіт про помилки повертається продавцю по email або в UI. Такий підхід гарантує відсутність блокувань і можливість обробляти сотні товарів за хвилини.

Дашборд — метрики в реальному часі

Дані дашборда не будуються за запитом — занадто дорого. Використовуємо матеріалізацію: таблиця seller_stats оновлюється раз на годину через scheduled job. Дані за поточний день вважаються live через Redis-лічильники. Графіки будуються на основі order_daily_aggregates — таблиці з преагрегованими даними по днях. Для візуалізації використовуємо Recharts або Chart.js. Компонент дашборда отримує дані через окремий API-endpoint, не змішуючи їх з основним CRUD.

Обробка замовлень продавцем

Продавець бачить тільки замовлення, що містять його товари. Інтерфейс обробки:

1. Підтвердження замовлення (перехід у статус confirmed, повідомлення покупцю).
2. Передача в доставку: введення трек-номера або виклик API служби доставки.
3. Позначка відправки: статус shipped, автоматичний email покупцю.
4. Обробка повернень: запит повернення від покупця → рішення продавця → фінансова операція.

Кожен перехід статусу логується в order_status_history з timestamps та actor_id.

Права доступу всередині кабінету

У великого продавця може бути команда. Потрібна система ролей всередині магазину:

Реалізується через Laravel Authorization з tenant-scope: shop_id прив'язується до кожної ролі.

Технічний стек та строки

Backend: Laravel з Eloquent, політики Gate/Policy, черги на Redis/Horizon. Frontend: React з React Hook Form, TanStack Query, компоненти Shadcn/ui. Зберігання файлів: S3 (MinIO для self-hosted), генерація presigned URL для завантаження напряму з браузера.

Базовий кабінет (товари + замовлення + дашборд без складної аналітики) — 3–4 тижні. Повний модуль з масовим імпортом, ролями в команді та фінансовим розділом — 6–8 тижнів.

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

• Аналітика та проектування архітектури.
• Реалізація всіх розділів кабінету.
• Масовий імпорт товарів.
• Система ролей та прав доступу.
• Інтеграція зі службами доставки.
• Тестування (unit, integration, e2e).
• Деплой та налаштування інфраструктури.
• Документація та навчання команди.
• Підтримка після запуску.

Наша команда має понад 10 років досвіду в розробці маркетплейсів і більше 40 успішних проєктів. Наше рішення на 30% швидше за типові шаблони завдяки Server Components та кешуванню. Зв'яжіться з нами — отримайте консультацію та оцінку вашого проєкту.

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