Разработка маркетплейса: архитектура, сроки и подводные камни

Маркетплейс регулярно заказывают как «интернет-магазин, только с несколькими поставщиками». Это самое дорогое заблуждение в теме: разница между ними не количественная, а структурная, и проявляется она примерно на третьем месяце разработки, когда бюджет уже потрачен.

Разберём, из чего маркетплейс состоит на самом деле.

Что отличает маркетплейс от магазина

В магазине один продавец — вы. Вы владеете товаром, назначаете цену, отвечаете за доставку и принимаете деньги.

В маркетплейсе вы владеете площадкой. Появляются вещи, которых в магазине нет вообще:

• кабинет продавца — регистрация, загрузка товаров, свои заказы, своя статистика;
• модерация — кто-то должен проверять товары и продавцов до публикации;
• разделение заказа — корзина с товарами трёх продавцов превращается в три отправления с разными сроками;
• расчёты и выплаты — деньги приходят вам, но принадлежат продавцам за вычетом комиссии;
• споры и возвраты — с тремя сторонами вместо двух;
• рейтинги и отзывы — по продавцам, а не только по товарам.

Каждый пункт — отдельный кусок работы. В сумме это в 3–5 раз больше, чем интернет-магазин сопоставимого масштаба.

Три роли вместо одной

Архитектурно маркетплейс — это три разных продукта в одном:

Витрина для покупателя. Каталог, поиск, корзина, оформление, отслеживание. Здесь всё как в магазине, плюс сложность: товары одинаковые у разных продавцов, и надо решить, показывать их отдельными карточками или объединять с выбором предложения.

Кабинет продавца. Загрузка товаров пачкой, остатки, цены, заказы, отчёты, вывод денег. Это полноценная система, и от её удобства зависит, останутся ли у вас продавцы.

Админка площадки. Модерация, комиссии, споры, аналитика, управление категориями. Обычно её проектируют последней и потом жалеют.

Ошибка планирования номер один — заложить бюджет на первую часть и считать две другие «мелочью».

Самая недооценённая часть: деньги

Здесь проекты застревают чаще всего.

Деньги покупателя приходят на площадку, но принадлежат продавцу за вычетом комиссии. Это не обычный приём платежей, а расчёты с третьими лицами, и они требуют отдельного механизма: разделение платежа, удержание до подтверждения получения, выплаты по расписанию, возвраты, чеки.

К этому добавляется вопрос статуса продавцов: юрлица, ИП, самозанятые — у каждого свой порядок документов. И вопрос, кто чей налоговый агент. Это территория бухгалтера и юриста, а не только разработчика.

Практический совет: в первой версии выплаты можно делать вручную по реестру. Это некрасиво, зато позволяет запуститься на несколько месяцев раньше и понять реальные потоки, прежде чем автоматизировать.

Что делать в MVP, а что откладывать

Делать сразу:

• одна товарная категория, а не «всё для всех»;
• кабинет продавца с загрузкой товаров и просмотром заказов;
• ручная модерация — первые сто продавцов проверяются человеком;
• корзина с разделением заказа по продавцам;
• приём оплаты, выплаты вручную по реестру;
• базовый поиск с фильтрами по категории.

Откладывать:

• рекомендации и персонализация;
• автоматическая модерация;
• мобильные приложения;
• программа лояльности;
• сложная логистика и свои пункты выдачи;
• аналитика для продавцов сверх «сколько заказов и на какую сумму».

Правило простое: всё, что первое время можно делать руками, делается руками. Автоматизируют процесс, который уже работает и понятен, а не тот, который представили на этапе проектирования.

Поиск: недооценённая сложность

В магазине с двумя сотнями товаров поиск можно сделать обычным запросом к базе. В маркетплейсе с десятками тысяч позиций от разных продавцов, где одно и то же называется по-разному, поиск становится отдельным проектом: нормализация названий, синонимы, опечатки, фильтры по характеристикам, ранжирование предложений одного товара.

Плохой поиск — самая частая причина, по которой покупатели не возвращаются на молодую площадку. Закладывайте на него отдельный бюджет и отдельное время, а не строчку в смете.

Сроки

MVP — от 4 месяцев. Одна категория, ручные процессы, базовый функционал всех трёх ролей.

Рабочая платформа — 8–14 месяцев. Автоматические выплаты, споры, нормальный поиск, аналитика.

Сроки в 2–3 месяца, которые иногда обещают, обычно означают, что кабинет продавца или расчёты не посчитаны. Что входит в нормальный процесс разработки — в статье про этапы разработки сайта.

Раскладка бюджета по блокам — в отдельной статье сколько стоит создать маркетплейс.

Главный риск — не технический

Маркетплейс не работает наполовину. Покупателю нужен выбор, продавцу — покупатели. Пустая площадка бесполезна обеим сторонам, а наполняются они только последовательно.

Поэтому до начала разработки должен существовать ответ на вопрос: откуда придут первые сто продавцов и почему они пойдут к вам, а не останутся на Wildberries и Ozon. Обычно работающие ответы такие: узкая ниша, где крупные площадки неудобны; уже существующее сообщество продавцов; более выгодные условия на старте.

Если ответа нет, деньги на разработку тратить рано. Технически безупречная площадка без продавцов стоит ровно ноль. По той же причине не стоит рассчитывать, что маркетплейс заменит собственные продажи: как соотносятся свой сайт и площадки, разбираем в статье свой сайт или маркетплейс.

Частые ошибки

Считать по образцу крупных площадок. Wildberries строился годами и сотнями разработчиков. Копировать надо не функции, а принцип: минимум, который работает.

Много категорий сразу. Каждая категория — свои характеристики, свои правила модерации, свои продавцы. Одна ниша до первой тысячи заказов.

Отсутствие кабинета продавца в смете. Обнаруживается на середине проекта и удваивает бюджет.

Разработка до юридической проработки. Порядок расчётов, договор оферты с продавцами, ответственность за товар — это надо решить до кода, а не после.

Итог

Маркетплейс — это три продукта в одном: витрина, кабинет продавца и админка. Самые тяжёлые части — расчёты с продавцами и поиск, и обе обычно недооценивают.

Реалистичные сроки: от 4 месяцев на MVP с ручными процессами, 8–14 месяцев на полноценную платформу.

И главное решение принимается до разработки: у вас должен быть план, откуда придут первые продавцы. Без него самый качественный код останется пустой витриной.