Как создать маркетплейс: модель, модули, платежи и запуск

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

Собственный маркетплейс кажется естественным следующим шагом для многих компаний: у дистрибьютора есть сеть поставщиков, у сервиса — база исполнителей, у отраслевого медиа — аудитория, которой можно продавать чужие товары. Идея понятна: платформа зарабатывает на сделках между другими участниками, не держа товар на складе и не нанимая исполнителей. На практике маркетплейс — одна из самых сложных моделей цифрового бизнеса. Он должен одновременно привлечь две стороны, каждой из которых без другой платформа не нужна, провести через себя деньги так, чтобы это было законно, удобно и не превратило компанию в должника перед сотнями продавцов, и выстроить доверие между людьми, которые друг друга не знают. Ниже — как устроен маркетплейс, из каких модулей он состоит, какие решения принимаются до разработки и как запускать его так, чтобы не построить пустую витрину. Маркетплейс или интернет-магазин Различие не в интерфейсе — покупатель может не заметить разницы, — а в том, кто продаёт. Интернет-магазин продаёт свой товар. Компания закупает, хранит, устанавливает цену, отвечает перед покупателем как продавец. Маркетплейс соединяет продавцов и покупателей. Товар и цена принадлежат продавцу, платформа предоставляет витрину, инструменты, часто — платёжный и логистический сервис, и зарабатывает на комиссии, подписке продавцов или платных услугах. Между ними есть гибриды: магазин, который добавляет товары партнёров к своему ассортименту, или маркетплейс, который частично продаёт собственный товар. Для технической и юридической архитектуры важно определить модель заранее, потому что от неё зависят схема денежных потоков, ответственность перед покупателем и налоги. Когда маркетплейс оправдан Ассортимент или предложение настолько широкие, что собственная закупка невозможна или нерентабельна. У компании уже есть доступ к одной из сторон — поставщикам или покупателям — и понятный способ привлечь другую. Платформа добавляет ценность, которую участники не получают напрямую: доверие, удобство сравнения, гарантию сделки, логистику, финансирование. Рынок фрагментирован: много небольших продавцов и много покупателей, которым сложно найти друг друга. Если продавцов единицы, а покупатели и так знают, где их искать, маркетплейс часто оказывается дорогой надстройкой над обычными прямыми продажами. Главная проблема: две стороны одновременно Покупатели не приходят на платформу, где нет выбора. Продавцы не приходят на платформу, где нет покупателей. Это называют проблемой курицы и яйца, и её решение важнее любой функции в техническом задании. Начать с одной стороны Обычно проще сначала собрать предложение. Способы: вручную подключить первых продавцов и помочь им завести товары, добавить в каталог собственный ассортимент или ассортимент одного крупного партнёра, агрегировать публично доступное предложение с согласия продавцов. Сузить рынок Маркетплейс «всего для всех» на старте почти невозможен. Маркетплейс для одной категории, одного региона или одной профессиональной аудитории может набрать критическую массу на гораздо меньшем числе участников. Расширение — после того, как узкий рынок заработал. Дать одной стороне ценность без другой Инструмент, полезный продавцам сам по себе: учёт заказов, каталог, аналитика. Продавцы начинают пользоваться платформой как сервисом, а покупательская часть появляется, когда предложение уже собрано. Проверить модель до платформы Первые сделки можно провести почти вручную: каталог на простом сайте, заказы через форму, согласование с продавцом по телефону, оплата по счёту. Это покажет, возникают ли сделки и за что участники готовы платить, до вложений в полноценную разработку. Как определить объём такой первой версии, мы разбирали в статье о границах MVP . Из каких модулей состоит маркетплейс Кабинет продавца Регистрация и проверка продавца, загрузка и редактирование товаров, управление ценами и остатками, обработка заказов, финансовые отчёты, выплаты, коммуникация с покупателями и платформой. Для продавцов с большим ассортиментом обязательна массовая загрузка — из файла или через API, — иначе завести тысячи позиций вручную никто не будет. Каталог и модерация Разные продавцы описывают одинаковые товары по-разному. Без единой модели товара — категорий, обязательных характеристик, правил названий и изображений — каталог превращается в набор несопоставимых карточек, в которых невозможно фильтровать и сравнивать. Нужны: дерево категорий с набором характеристик для каждой; проверка карточек перед публикацией — автоматическая и, для спорных случаев, ручная; объединение одинаковых товаров разных продавцов в одну карточку с несколькими предложениями — или осознанный отказ от этого; правила для запрещённых и ограниченных товаров. Поиск и навигация На маркетплейсе с большим ассортиментом поиск — главный путь покупателя к товару. Полнотекстовый поиск с учётом морфологии и опечаток, фильтры по характеристикам категории, сортировка, подсказки. Отдельная задача — ранжирование: какие предложения показывать выше, как учитывать цену, рейтинг продавца, скорость доставки, наличие. Ранжирование — одновременно инструмент качества для покупателя и чувствительная для продавцов тема, поэтому его правила должны быть объяснимы. Корзина и оформление заказа Покупатель кладёт в корзину товары разных продавцов. Технически это несколько заказов с разными условиями доставки, сроками и, возможно, разными способами оплаты. Интерфейс должен оставаться простым для покупателя, а система — разделять заказ на части и отслеживать каждую отдельно. Платежи и расчёты с продавцами Самый сложный модуль с юридической точки зрения. Покупатель платит один раз, а деньги должны попасть нескольким продавцам за вычетом комиссии платформы, с учётом возвратов и в сроки, установленные договором. Подробнее ниже. Логистика Варианты: продавец доставляет сам, платформа интегрируется со службами доставки и продавец отгружает через них, платформа управляет собственной логистикой и складами. От выбора зависят сроки, стоимость, контроль качества и объём разработки. Для большинства новых маркетплейсов разумно начинать с интеграции служб доставки и расширять логистику по мере роста. Отзывы, рейтинги и доверие Покупатель доверяет незнакомому продавцу благодаря платформе. Инструменты: отзывы только от реальных покупателей, рейтинг продавца по объективным показателям — доле отмен, срокам отгрузки, возвратам, — проверка продавцов при регистрации, гарантия платформы на случай, если товар не пришёл. Споры и возвраты Товар не соответствует описанию, пришёл повреждённым, не пришёл вовсе. Нужен понятный процесс: как покупатель открывает спор, сколько времени у продавца на ответ, когда вмешивается платформа, как возвращаются деньги и кто несёт расходы. Антифрод Фиктивные продавцы, накрутка отзывов, мошеннические заказы, попытки увести сделку за пределы платформы. Правила и автоматические сигналы — от проверки реквизитов при регистрации до анализа аномалий в заказах и отзывах. Администрирование Панель для сотрудников платформы: модерация, управление категориями и комиссиями, работа со спорами, финансовая сверка, отчётность, поддержка продавцов и покупателей. Деньги: самая важная архитектурная развилка Схему денежных потоков нужно выбрать до начала разработки вместе с юристом и финансовым директором. Переделать её после запуска значит переписать платёжный контур, договоры и учёт. Платформа как продавец Платформа покупает товар у продавца и перепродаёт покупателю. Юридически проще для покупателя, но платформа несёт ответственность продавца, работает с полной суммой выручки в налоговом учёте и управляет возвратами как продавец. Агентская схема Платформа действует как агент продавца, принимает оплату от покупателя в его пользу и перечисляет деньги продавцу за вычетом вознаграждения. Требует корректного оформления агентских договоров и кассовых чеков с признаками агента и данными поставщика. Выручкой платформы является вознаграждение, а не полная сумма заказа. Расщепление платежа Платёжный провайдер или банк сам распределяет оплату покупателя между продавцами и платформой, и деньги продавцов не проходят через счёт платформы. Для этого используются специальные сервисы расщепления и номинальные счета. Схема снижает риски платформы, связанные с удержанием чужих денег, но зависит от возможностей выбранного банка или провайдера и накладывает требования к подключению и проверке продавцов. Независимо от схемы, система должна точно отвечать на вопросы: сколько платформа должна каждому продавцу на любой момент, из каких заказов складывается сумма, какие удержания сделаны и почему, что происходит с выплатой при возврате после перечисления денег продавцу. Правовые вопросы, которые нужно решить до запуска Роль платформы. Продавец, агент или информационный посредник — от этого зависит ответственность перед покупателем. Регулирование платформенной экономики. В России принят закон о платформенной экономике, устанавливающий обязанности владельцев посреднических платформ перед продавцами и покупателями. Стоит проверить с юристом, распространяется ли он на вашу платформу и какие требования к договорам, модерации, ранжированию и работе с продавцами из него следуют. Защита прав потребителей. Информация о продавце, условия возврата, дистанционная торговля. Кассовые чеки. Порядок формирования чеков при выбранной схеме расчётов. Маркировка. Для ряда категорий товаров действует обязательная маркировка, и платформа должна корректно работать с кодами маркировки при продаже и возврате. Персональные данные. Данные покупателей передаются продавцам для доставки — нужны основания и правила такой передачи. Оферта для продавцов и пользовательское соглашение для покупателей. Комиссии, сроки выплат, правила модерации и блокировки, порядок споров. Технологические решения Готовая платформа или разработка Существуют коробочные решения и конструкторы маркетплейсов. Они быстро запускаются и закрывают типовые сценарии. Собственная разработка оправдана, когда модель нестандартна — маркетплейс услуг с бронированием, B2B-площадка с тендерами и отсрочкой платежа, сложная логистика, — когда нужны глубокие интеграции с учётными системами продавцов или когда платформа сама является основным продуктом компании и её возможности — конкурентное преимущество. Архитектура Модули маркетплейса — каталог, заказы, платежи, выплаты, поиск — развиваются с разной скоростью и имеют разные требования к нагрузке и надёжности. Это аргумент за чёткие границы между модулями с первого дня. Но не обязательно за микросервисы: хорошо структурированное модульное приложение на старте проще в разработке и эксплуатации, а выделение отдельных сервисов делается по мере роста там, где это действительно нужно. Поиск Для каталога от нескольких тысяч позиций поиск строится на специализированном поисковом движке с поддержкой морфологии русского языка, а не на запросах к основной базе данных. Индекс обновляется при изменении товаров, цен и остатков. Мобильное приложение Для потребительских маркетплейсов приложение часто становится основным каналом повторных покупок: push-уведомления о статусе заказа, сохранённые способы оплаты, персональные подборки. Для B2B-площадок веб-версия обычно важнее. Кроссплатформенная разработка позволяет поддерживать iOS и Android одной командой без заметной потери качества для большинства сценариев маркетплейса. Пример из практики: мобильный маркетплейс детских товаров Мы разрабатывали мобильное приложение маркетплейса детских товаров. Задача: сделать покупку простой, безопасной и приятной для родителей, решив проблемы сложной навигации, отсутствия возрастных рекомендаций и неудобного подбора подарков. В приложении — навигация по возрасту ребёнка, AI-помощник подбора подарков, система проверки безопасности товаров и умные фильтры с рекомендациями на основе машинного обучения; мобильная часть написана на React Native. Проект занял 10 месяцев, команда — 15 человек. Показатели из опубликованного кейса : 500 тысяч и более активных родителей; 50 000 товаров в каталоге; более 2 миллионов выполненных заказов; оценк