Разработка маркетплейса или агрегатора: продавцы, каталог, комиссии, модерация и выплаты

Маркетплейс или агрегатор - это не просто сайт с каталогом. Это платформа, где есть минимум три стороны: пользователь, поставщик и владелец сервиса. Пользователь ищет товар, услугу, исполнителя, объект или предложение. Продавец размещает карточки, получает заявки или заказы, обновляет цены и статусы. Владелец платформы управляет правилами, качеством каталога, комиссиями, платежами, модерацией, спорами, аналитикой и развитием продукта. Именно поэтому разработка маркетплейса сложнее обычного интернет-магазина или корпоративного сайта. В интернет-магазине бизнес сам владеет товарами, ценами, остатками и доставкой. В маркетплейсе часть данных и действий приходит от внешних участников. Кто-то добавляет карточку, кто-то меняет цену, кто-то отвечает клиенту, кто-то отменяет заказ, кто-то получает выплату. Если архитектура не продумана, платформа быстро превращается в набор ручных таблиц: менеджеры проверяют карточки в чатах, продавцы спорят о комиссиях, клиенты не понимают статус заказа, а владелец продукта не видит реальную экономику. Хороший маркетплейс строится не вокруг красивой витрины, а вокруг доверия и управляемых процессов. Каталог должен быть понятным, данные - структурированными, продавцы - проверенными, комиссии - прозрачными, модерация - быстрой, платежи - надежными, выплаты - контролируемыми, а админ-панель - достаточно сильной, чтобы бизнес не зависел от разработчика при каждой операционной задаче.

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

Маркетплейс обычно не только показывает предложения, но и проводит сделку внутри платформы. Пользователь выбирает товар или услугу, оформляет заказ, оплачивает, получает подтверждение, отслеживает статус, оставляет отзыв. Продавец обрабатывает заказ, передает товар или оказывает услугу, а платформа получает комиссию или другую монетизацию. Агрегатор может быть легче по бизнес-логике. Он собирает предложения разных компаний, помогает пользователю сравнить варианты и отправляет заявку поставщику. Например, агрегатор клиник, курсов, сервисных центров, недвижимости, туров, специалистов или B2B-поставщиков. Деньги могут проходить не через платформу, а напрямую между клиентом и поставщиком. Но даже в этом варианте нужны карточки, фильтры, заявки, модерация, личные кабинеты, рейтинги, статусы и аналитика. На практике граница часто смешивается. Проект может стартовать как агрегатор заявок, а позже добавить оплату, бронирование, комиссии, документы и выплаты. Поэтому важно заранее понимать стратегию: платформа будет только передавать лиды или станет полноценным транзакционным маркетплейсом.

Когда бизнесу нужен маркетплейс или агрегатор

Маркетплейс имеет смысл, когда ценность продукта создается не одной компанией, а сетью участников. Чем больше качественных продавцов, исполнителей, объектов или предложений, тем полезнее платформа для клиента. Но это работает только если платформа умеет управлять качеством и процессами. Такой формат подходит, если:

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

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

Основные бизнес-модели маркетплейса

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

Комиссия со сделки

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

Оплата за лид

Агрегатор может брать деньги за заявку. Например, поставщик платит за контакт клиента, бронь, запрос цены или квалифицированный лид. Здесь важно определить, что считается качественной заявкой, как бороться с дублями, как обрабатывать жалобы продавцов и как не продавать один и тот же лид без правил.

Подписка продавца

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

Платное продвижение

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

Смешанная модель

Часто используется комбинация: бесплатное размещение, комиссия с заказа, платные опции, подписка для продавцов и дополнительные рекламные инструменты. Смешанная модель гибкая, но сложнее для разработки и учета. Нужно заранее описать, какие деньги откуда приходят и как они отражаются в отчетах.

Продавцы и поставщики: регистрация, проверка и роли

Продавец в маркетплейсе - это не обычный пользователь. У него есть профиль, юридические данные, документы, карточки, заказы, заявки, выплаты, сотрудники и ограничения. Если эту роль сделать слишком простой, операционная работа быстро уйдет в ручной режим. Для продавца нужно продумать:

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

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

Кабинет продавца

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

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

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

Каталог: структура данных важнее внешнего вида

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

Ошибка многих проектов - дать продавцам свободное текстовое поле и ждать порядка. Если один продавец пишет "Москва", второй "мск", третий "Московская область", а четвертый оставляет поле пустым, фильтры и аналитика начинают работать плохо. Поэтому часть полей должна быть справочниками, выпадающими списками, числовыми значениями и проверяемыми форматами. Если маркетплейс планирует развиваться по категориям, нельзя делать одну универсальную карточку на все случаи. У недвижимости одни параметры, у оборудования другие, у образовательных курсов третьи, у медицинских услуг четвертые. Нужна гибкая модель характеристик, но без хаоса, где каждый продавец придумывает свои поля.

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

[Поиск, фильтры и сортировка](articles/poisk-i-filtry-v-kataloge/)

Пользователь приходит на маркетплейс не ради базы данных, а ради быстрого выбора. Поэтому поиск, фильтры и сортировка напрямую влияют на конверсию. Нужно продумать:

Фильтры должны соответствовать реальным данным. Если продавцы заполняют карточки неполно, фильтр будет скрывать хорошие предложения или показывать мусор. Поэтому качество поиска начинается не с алгоритма, а с правил заполнения каталога и модерации.

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

Карточка товара, услуги или предложения

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

Для агрегатора услуг особенно важно не скрывать неопределенность. Если итоговая цена зависит от параметров, лучше честно показывать "от", диапазон или форму расчета, чем обещать точную стоимость без данных. Для B2B-каталога может быть уместна кнопка "Запросить цену", если цены индивидуальные.

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

Заявки, заказы и сделки

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

Для заказов добавляются сумма, состав, способ оплаты, доставка или оказание услуги, документы, возвраты, комиссии и финальный статус. Если проект строится как транзакционный маркетплейс, заказ становится центральной сущностью платформы.

• пользователя;
• продавца;
• карточку;
• категорию;
• дату;
• контактные данные;
• сообщение;
• источник;
• UTM-метки;
• статус;
• ответственного;
• историю коммуникации.

Комиссии: как считать честно и понятно

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

Например, комиссия может начисляться после успешной оплаты, но становиться доступной владельцу платформы только после завершения заказа и окончания периода возврата. Или агрегатор может списывать плату за лид сразу, но возвращать ее продавцу, если заявка признана дублем или некачественной. Это не технические детали, а правила экономики продукта.

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

Платежи и безопасная работа с деньгами

Платежная модель зависит от того, как платформа участвует в сделке. Есть несколько вариантов. Первый вариант - оплата напрямую продавцу. Платформа передает заявку, а деньги идут мимо нее. Это проще юридически и технически, но сложнее для контроля комиссии: нужно подтверждать сделку вручную, интегрироваться с CRM продавца или брать плату за лид/подписку. Второй вариант - платформа принимает оплату и потом перечисляет деньги продавцу. Это дает больше контроля, но требует продуманной юридической схемы, платежного провайдера, статусов, чеков, возвратов, выплат и финансовой отчетности. Третий вариант - холдирование или безопасная сделка. Деньги блокируются или принимаются платформой, а продавец получает выплату после выполнения условий. Такой сценарий полезен там, где важны доверие, качество исполнения и спорные ситуации, но он сложнее в разработке. Платежи нужно проектировать вместе со статусами заказов. Нельзя просто принять деньги и забыть. Нужно понимать, когда заказ считается оплаченным, когда комиссия начисляется, когда продавец получает выплату, что происходит при отмене и как обрабатывается возврат. Для глубокого раскрытия этой темы уместна внутренняя связь со статьей Платежи в веб-сервисе.

Выплаты продавцам

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

Не стоит смешивать "продавец заработал" и "деньги готовы к выплате". Между этими состояниями могут быть возврат, спор, проверка, комиссия, удержание или ожидание закрывающих документов. Поэтому лучше хранить отдельные состояния: начислено, ожидает подтверждения, доступно к выплате, выплачено, отменено, скорректировано.

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

Модерация продавцов и карточек

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

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

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

Рейтинги, отзывы и доверие

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

Если отзывы появляются до реальных сделок или без проверки, они быстро теряют ценность. Для молодых платформ иногда лучше начать с верификации продавца, статуса "проверен", портфолио и ручной модерации, а полноценные отзывы добавить после появления достаточного количества заказов.

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

Админ-панель маркетплейса

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

Главная ошибка - строить админку как прямой доступ к таблицам. Сотрудникам нужны не таблицы базы, а рабочие сценарии: проверить нового продавца, одобрить карточку, найти проблемный заказ, пересчитать комиссию, выгрузить выплаты, заблокировать нарушителя, посмотреть историю изменений. Подробнее логику такого интерфейса можно связать со статьей Админ-панель для веб-сервиса.

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

API и интеграции

Маркетплейс редко живет изолированно. Продавцам могут быть нужны интеграции с CRM, ERP, складом, 1С, системой доставки, телефонией, email-рассылками, платежным провайдером или аналитикой. Чем больше продавцов и категорий, тем важнее API. API может понадобиться для:

На первом релизе можно не делать публичный API для всех продавцов. Но внутреннюю архитектуру лучше строить так, чтобы данные были связаны через понятные сущности и события. Тогда позже будет проще добавить импорт, экспорт, интеграции и автоматизацию. Эта тема хорошо стыкуется со статьей Разработка платформы с API.

• загрузки товаров;
• обновления цен;
• обновления остатков;
• получения заказов;
• изменения статусов;
• передачи документов;
• синхронизации клиентов;
• обмена сообщениями;
• получения отчетов;
• подключения внешних сервисов.

SEO для маркетплейса и агрегатора

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

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

• какие страницы должны индексироваться;
• какие фильтры закрывать от индексации;
• как формировать Title и Description;
• как избегать дублей;
• как обрабатывать пустые категории;
• как делать человекопонятные URL;
• как обновлять sitemap;
• как использовать структурированные данные там, где они уместны;
• как не создавать тысячи тонких страниц без ценности.

Аналитика маркетплейса

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

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

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

Безопасность и защита данных

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

Особенно важно не смешивать данные продавцов. Один продавец не должен видеть заказы, клиентов, выплаты или документы другого продавца. Это базовое требование для доверия к платформе.

• разграничение ролей;
• проверку прав на backend;
• защиту персональных данных;
• безопасное хранение документов;
• контроль доступа к реквизитам;
• защищенную админ-панель;
• журнал действий сотрудников;
• защиту API;
• ограничение частоты запросов;
• проверку загружаемых файлов;
• безопасную работу с платежами;
• резервное копирование;
• мониторинг ошибок.

Юридические и финансовые вопросы

Разработка маркетплейса почти всегда затрагивает юридическую схему. Платформа может быть агентом, информационным посредником, продавцом, сервисом лидогенерации или SaaS-инструментом для продавцов. От этого зависят договоры, чеки, возвраты, ответственность, документы, налоги и выплаты. До разработки нужно согласовать:

Это не зона, где разработчик должен придумывать юридические ответы вместо бизнеса. Но разработка должна учитывать выбранную схему. Если сначала сделать платформу, а потом выяснить, что деньги должны идти иначе, придется переделывать платежи, документы, статусы и кабинет продавца.

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

MVP маркетплейса: что делать в первый релиз

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

Платежи, автоматические выплаты, отзывы, публичный API, сложный рейтинг и рекламные инструменты можно добавлять после проверки ядра продукта. Но если бизнес-модель сразу строится на комиссии со сделки, связь заказов, платежей и комиссии нужно проектировать с первого релиза, даже если часть операций пока выполняется вручную.

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

Типичные ошибки при разработке маркетплейса

Первая ошибка - начинать с витрины и забывать про продавцов. Если продавцам неудобно добавлять карточки и обрабатывать заявки, каталог быстро устареет. Вторая ошибка - не определить модель монетизации. Комиссия, лиды, подписка и продвижение требуют разной логики. Третья ошибка - дать продавцам слишком свободное заполнение карточек. Без структуры каталог становится неуправляемым. Четвертая ошибка - запускать каталог без модерации. На старте это может казаться ускорением, но потом бизнес тратит больше времени на исправление качества. Пятая ошибка - не разделять статусы заявки, заказа, платежа, комиссии и выплаты. Эти сущности связаны, но не равны друг другу. Шестая ошибка - обещать автоматические выплаты без понятной юридической и финансовой схемы. Седьмая ошибка - делать рейтинг до появления реальных заказов. Рейтинг без данных легко превращается в декоративный элемент. Восьмая ошибка - не тестировать роли. Покупатель, продавец, модератор, администратор и бухгалтер должны видеть только свои данные и действия.

Как подготовить [техническое задание](articles/tehnicheskoe-zadanie-na-razrabotku/) на маркетплейс

Для точной оценки сроков и бюджета нужно описать не "маркетплейс как у крупной платформы", а конкретный первый релиз. В ТЗ стоит указать:

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

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

Как Wcoders подходит к разработке маркетплейса

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

Такой подход помогает не раздувать первый релиз, но заложить правильную архитектуру. Маркетплейс можно запускать поэтапно: сначала каталог и заявки, затем кабинет продавца и модерация, потом платежи и комиссии, позже выплаты, рейтинги, API, продвижение и расширенная аналитика. Главное - не строить фундамент как обычный сайт, если бизнес уже планирует платформу.

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

FAQ

Можно ли сделать маркетплейс на конструкторе или CMS?

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

Что лучше для старта: маркетплейс или агрегатор заявок?

Если бизнес еще проверяет спрос и продавцов, агрегатор заявок часто проще. Он позволяет собрать каталог, принимать обращения и вручную проверять экономику. Если же ценность продукта зависит от оплаты, заказов, комиссий и контролируемой сделки внутри платформы, нужно проектировать маркетплейс.

Нужно ли делать автоматические выплаты продавцам в MVP?

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

Как понять, какие поля нужны в каталоге?

Нужно идти от выбора пользователя. Какие параметры реально помогают сравнивать предложения? Цена, регион, наличие, сроки, характеристики, рейтинг, документы, опыт, бренд, формат услуги. Все важные параметры лучше делать структурированными полями, а не свободным текстом.

Нужна ли модерация всех карточек?

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

Как считать комиссию маркетплейса?

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

Чем B2B-маркетплейс отличается от B2C?

В B2B чаще нужны компании, реквизиты, роли сотрудников, индивидуальные цены, счета, документы, согласования, лимиты, интеграции с 1С или ERP и длинный цикл сделки. Поэтому B2B-маркетплейс ближе к платформе и порталу, чем к обычной витрине. Часть логики пересекается с темой разработки B2B-портала.

Что сложнее всего в маркетплейсе?

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

Итог

Разработка маркетплейса или агрегатора - это создание платформы, где нужно управлять не только витриной, но и участниками, данными, правилами, деньгами и доверием. Продавцы, каталог, заявки, заказы, комиссии, модерация и выплаты должны быть связаны в единую систему. Чтобы проект не превратился в дорогой хаос, нужно начинать с бизнес-модели и первого релиза. Кто продавцы? Что пользователь выбирает? Где проходит сделка? Как платформа зарабатывает? Какие данные обязательны? Когда начисляется комиссия? Кто модерирует карточки? Когда продавец получает выплату? Ответы на эти вопросы важнее, чем попытка сразу повторить крупный маркетплейс. Сильный маркетплейс растет поэтапно: сначала проверяет ценность, затем усиливает кабинет продавца, модерацию, платежи, комиссии, выплаты, аналитику и интеграции. Если архитектура заложена правильно, платформа может масштабироваться по категориям, регионам, продавцам и сценариям без постоянной переделки ядра.