Surf 
Тендеры и лиды
Информация
Без обещаний «запустим свой Ozon за три месяца»: чем маркетплейс отличается от агрегатора и обычного интернет-магазина, почему двусторонний рынок сложнее любой разработки, какие бывают бизнес-модели и как подступиться к запуску, чтобы не сжечь бюджет.
«Хотим свой маркетплейс» — запрос, который мы слышим регулярно, и за ним обычно стоит одна и та же картинка: витрина, много продавцов, покупатели идут, комиссия капает. Написать эту витрину способна любая грамотная команда, и стоит она понятных денег. Проблема в другом: маркетплейс — это не один магазин, а два рынка сразу. Без продавцов площадка бесполезна покупателям, без покупателей — неинтересна продавцам, и запустить обе стороны одновременно почти невозможно. Именно здесь, а не в коде, погибает большинство маркетплейсов. Разберём, что на самом деле определяет их судьбу, чем маркетплейс отличается от агрегатора и когда своя площадка вообще оправдана.
Мы в Surf строим маркетплейсы и платформы — например, IZZI, площадку автоуслуг, о которой ниже, — сочетая проектирование продукта, e-commerce-разработку и мобильную разработку, и смотрим на задачу с двух сторон: и как разработчики, и как люди, видевшие, где такие проекты буксуют. Если нужен детальный разбор этапов и архитектуры, у нас есть руководство по разработке маркетплейсов; эта статья — про смысл, модель и границы.
Прежде чем считать бюджет, стоит определиться, что именно вы задумали, потому что за похожими витринами скрываются три разные бизнес-модели. Ключевой вопрос — участвует ли платформа в сделке.
Кто продаёт
Интернет-магазин: вы сами
Агрегатор: много чужих продавцов
Маркетплейс: много чужих продавцов
Сделка проходит
Интернет-магазин: у вас
Агрегатор: на сайте продавца, вы только сводите
Маркетплейс: на вашей платформе
Оплата
Интернет-магазин: вам
Агрегатор: напрямую продавцу
Маркетплейс: через платформу, вы берёте комиссию
Как зарабатываете
Интернет-магазин: маржа с товара
Агрегатор: реклама, оплата за клик или заявку
Маркетплейс: комиссия со сделок
Пример
Интернет-магазин: фирменный магазин бренда
Агрегатор: Авиасейлс, Циан
Маркетплейс: Ozon, Wildberries
Разница принципиальна. Интернет-магазин продаёт свой товар и отвечает за него сам. Агрегатор собирает предложения из многих источников и зарабатывает на том, что приводит клиента продавцу, но в саму сделку не вмешивается — деньги идут мимо него. Маркетплейс берёт сделку на себя: оплата проходит через платформу, а значит, на нём висят и деньги продавцов, и споры, и возвраты, и ответственность. Чем глубже платформа влезает в сделку, тем больше пользы она даёт и тем сложнее её построить. Поэтому выбор между агрегатором и маркетплейсом — это не про дизайн, а про то, сколько ответственности и технической сложности вы готовы на себя взять.
Теперь о том, из-за чего маркетплейсы чаще всего не взлетают. Обычному магазину нужно привлечь покупателей — одна задача. Маркетплейсу нужно одновременно набрать и продавцов, и покупателей, и эти две задачи завязаны друг на друга намертво. Покупатель не придёт на площадку, где нет ассортимента. Продавец не будет тратить время на площадку, где нет покупателей. Классическая проблема курицы и яйца: чтобы появилось первое, нужно второе, и наоборот.
Ни одна платформа, даже идеально написанная, эту проблему сама не решает — это задача не разработки, а запуска. И решается она не техникой, а ручной работой: выбрать узкую нишу, где проще собрать критическую массу; вручную привести первых продавцов, часто уговорами и льготными условиями; на старте мириться с тем, что предложение придётся отчасти формировать самим. Пока на площадке нет ликвидности, то есть достаточно предложений, чтобы покупатель находил нужное, и достаточно спроса, чтобы продавец получал заказы, маркетплейса фактически нет, есть красивая пустая витрина. Поэтому первый вопрос при запуске не «на чём разрабатывать», а «как мы наберём обе стороны».
Ещё одна вещь, которую стоит решить до начала разработки, — как площадка зарабатывает. От этого зависит вся механика продукта, а не только строчка в финансовой модели. Основные варианты:
комиссия со сделок — площадка берёт процент с каждой продажи (обычно в диапазоне 3–30% в зависимости от ниши); основная модель классических маркетплейсов, но требует, чтобы оплата шла через платформу;
подписка или плата за размещение — продавец платит за доступ или за листинг товаров независимо от продаж; проще технически, но продавца надо сначала убедить платить;
оплата за клик или заявку (CPC/CPL) — типичная модель агрегатора: берёте деньги за приведённого клиента, а сделка идёт мимо вас;
реклама и платное продвижение — продавцы платят за место повыше в выдаче; работает только на объёме аудитории;
freemium — базовые функции бесплатно, расширенные за деньги.
Модель выбирают в самом начале, потому что комиссия требует встроенных платежей и работы с деньгами продавцов, а оплата за клик — нет; подписка меняет логику личного кабинета, а реклама — логику поиска и выдачи. Пытаться «сначала запустимся, потом придумаем, как монетизировать» на маркетплейсе особенно опасно: модель зашита в архитектуру.
Из проблемы ликвидности следует единственная работающая стратегия старта — начинать узко. Попытка сразу построить «второй Ozon» с миллионом товаров во всех категориях почти гарантированно проваливается: денег и на разработку такого масштаба, и на одновременный набор обеих сторон рынка не хватит. Гораздо надёжнее выбрать одну вертикаль, где вы понимаете и продавцов, и покупателей, и сделать MVP под неё.
Смысл MVP здесь не в том, чтобы урезать функции ради экономии, а в том, чтобы проверить главную гипотезу: сходится ли двусторонний рынок в этой нише. Поэтому первую версию часто запускают с минимумом автоматизации и максимумом ручной работы — модерацию, подбор, даже часть сделок ведут руками, лишь бы доказать, что спрос и предложение встречаются. Когда ликвидность в нише появилась и стало видно, что модель работает, платформу достраивают и масштабируют на соседние категории. По нашему опыту, MVP маркетплейса занимает порядка четырёх месяцев, а полноценная платформа — примерно шесть-десять, но эти сроки имеют смысл только тогда, когда за ними стоит проверенная гипотеза рынка, а не желание запуститься пошире.
Наша система сама подберет вам исполнителей на услуги, связанные с разработкой сайта или приложения, поисковой оптимизацией, контекстной рекламой, маркетингом, SMM и PR.
Заполнить заявку
13691 тендер
проведено за восемь лет работы нашего сайта.
Витрина и каталог — самая простая часть, хотя именно её обычно представляют, говоря «маркетплейс». Сложное начинается там, где платформа берёт на себя сделку. Первое — деньги: если оплата идёт через вас, нужны сплит-платежи и безопасная сделка, то есть механизм, который принимает деньги покупателя, придерживает их и выплачивает продавцу за вычетом комиссии. Это отдельная инженерная и юридическая задача, а не «прикрутить оплату».
Второе — право и налоги: маркетплейс становится по сути платёжным агентом, обязан пробивать чеки по 54-ФЗ, корректно работать с самозанятыми и юрлицами-продавцами, выстраивать агентскую схему расчётов. Третье — доверие и споры: рейтинги, отзывы, модерация продавцов и товаров, разрешение конфликтов и возвратов. Всё это не украшения, а то, без чего двусторонняя площадка не работает, и именно это отличает маркетплейс от интернет-магазина по сложности. Закладывать эти блоки нужно с самого начала, потому что задним числом встроить платёжную и правовую механику в готовую витрину заметно дороже, чем спроектировать её сразу.
Подход к разработке выбирают под задачу, и универсального ответа нет. Грубо есть три пути.
Коробочное решение — Что это: готовая платформа (например, на 1С-Битрикс) с базовым каталогом, оплатой, ЛК; Когда подходит: типовая ниша, надо быстро проверить идею, бюджет ограничен
Композитная сборка — Что это: платформа из готовых модулей плюс кастомная логика поверх; Когда подходит: нужен баланс скорости и гибкости, часть процессов нестандартна
Разработка с нуля — Что это: полностью своя платформа под ваш процесс; Когда подходит: нестандартная модель, расчёт на масштаб и уникальный UX
Логика выбора простая: чем типовее ваш маркетплейс, тем разумнее начинать с коробки или композита и не переплачивать за кастом на этапе, когда гипотеза рынка ещё не проверена. И наоборот, если модель нестандартная, а планы серьёзные, коробочные ограничения быстро упрутся в потолок, и кастом окупится. Частая ошибка в обе стороны: строить дорогую кастомную платформу под непроверенную идею или, наоборот, пытаться натянуть на коробку модель, в которую она не укладывается.
Стоит честно проверить саму идею, потому что маркетплейс — не универсальный ответ. Если товар или услугу поставляете по сути вы сами или один-два партнёра, вам нужен интернет-магазин, а не платформа с продавцами: двусторонний рынок вы городите там, где его нет. Если рынок не фрагментирован и покупатели уже знают, где купить, а продавцов наперечёт, маркетплейс не создаст ценности, ему нечего агрегировать. И если вы можете так же продавать напрямую, отдавать 15–30% комиссии чужой площадке или строить свою имеет смысл только при реальном объёме.
Маркетплейс оправдан там, где есть множество разрозненных продавцов и покупателей, которым трудно найти друг друга, и где платформа реально снимает эту боль — упрощает поиск, берёт на себя оплату и гарантии. Если этой боли нет, площадка станет дорогим способом усложнить себе жизнь.
Как это выглядит на практике, видно на проекте IZZI — площадке автоуслуг, которую мы развивали из внутреннего инструмента в полноценный маркетплейс. IZZI связывает три стороны: водителей, которым нужен шиномонтаж, сезонное хранение шин и обслуживание; сервисы-партнёров, которые эти услуги оказывают; и корпоративные автопарки. Уже не два, а три интереса, которые надо свести на одной платформе, и это хорошо показывает, что маркетплейс всегда про согласование сторон, а не про витрину.
Технически мы собрали B2C-приложение для водителей с поиском сервисов по карте, фильтрами и «цифровым гаражом», где по данным автомобиля считается стоимость обслуживания, и отдельный B2B-портал для партнёров и автопарков с личными кабинетами, ролями и фотоотчётами, всё на едином бэкенде с интеграциями в учётные системы. Запуск занял около семи месяцев, платформа вышла с тридцатью с лишним функциями и набрала более десяти тысяч активных пользователей, а кросс-платформенная разработка на Flutter позволила сократить затраты примерно на 40%. Но сработало это не потому, что мы написали красивую витрину, а потому, что попали в нишу, где обе — точнее, все три — стороны рынка реально сходятся.
Маркетплейс — это два рынка сразу, и главная сложность не в разработке витрины, а в том, чтобы одновременно набрать продавцов и покупателей; проблема курицы и яйца губит площадки чаще, чем код.
Сначала определитесь, что строите: интернет-магазин продаёт своё, агрегатор сводит и берёт за клик, маркетплейс проводит сделку и берёт комиссию — от этого зависит вся сложность.
Бизнес-модель выбирают до разработки: комиссия, подписка, оплата за клик и реклама требуют разной архитектуры, и задним числом её не поменять.
Стартовать надо узко: нишевый MVP и ручной запуск ликвидности, а не «второй Ozon» сразу; масштабирование — после того как рынок в нише сошёлся.
Сложное в маркетплейсе — не каталог, а сплит-платежи, 54-ФЗ и работа с продавцами, модерация и споры; и если у вас нет реального двустороннего рынка, вам нужен магазин, а не платформа.
Маркетплейс — это инструмент против разрозненности рынка, и он окупается там, где множеству продавцов и покупателей действительно трудно найти друг друга. Там, где эта боль реальна, площадка создаёт ценность и зарабатывает на каждой сделке. Там, где рынка на две стороны нет, самая дорогая разработка не поможет: витрина будет, а маркетплейса не будет. Поэтому начинать стоит не с вопроса «сколько стоит разработка», а с вопроса «сойдётся ли у нас двусторонний рынок» — ответ на него определяет всё остальное.
Владимир Макеев, генеральный директор Surf — компании по разработке и дизайну цифровых продуктов для крупного и среднего бизнеса.
