Разработка маркетплейса товаров - делаем готовое решение

Денис Гордиенко, генеральный директор Bright Mobile, о коробочном решении для маркетплейсов.

Наконец-то дошли руки сделать корпоративный акк на VC вместо личного. Предыдущие мои статьи можно почитать здесь.

Сегодня я расскажу вам о готовом решении для товарных маркетплейсов с некоторыми особенностями, к которому мы пришли под конец года и пример первого проекта, который переходит к активному развитию, а не ушёл в «стол».

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

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

А вот с товарными маркетплейсами ситуация сложилась иная: их на рынке и так много достаточно раскрученных (вспомните хотя бы Ozon, Wildberries, Aliexpress), и новые успешные появляются крайне редко. Для меня всегда было загадкой, зачем люди пытаются запустить аналоги.

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

За последние 4 года мы запустили несколько маркетплейсов с нюансами и пришли таким образом к некой альфа-версии готового решения, которое отличается от CS-Cart multi-vendor и аналогов.

Сначала – всё то, что входит в разряд «и так понятно», но перечислить стоит.

Со стороны покупателя:

Продавцу:

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

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

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

В одном из самых первых запускаемых нами приложений товарных маркетплейсов оформление заказа осуществлялось не классическим способом (добавление в корзину → оформление → общение в чате), поскольку последний пункт по оплате отсутствовал.

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

Клиенту важно не просто оформить покупку, а найти того фермера, который предложит ему нужный товар: особый сорт коров или какие-то товары люксового сегмента и пр. А маркетплейс ему в этом помогает.

Подробнее про первый такой проект можно посмотреть на видео:

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

Затем у нас запустили проект по аренде вещей. Архитектура очень похожа на товарный маркетплейс, единственное отличие в том, что вещь спустя какое-то время нужно отдать. На заказе срабатывает определённый счётчик, определяющий длительность пользования товаром, в момент его возврата он останавливается, и идёт списание средств с карты. Баланс привязывается и к продавцу (чтобы он мог посмотреть, сколько он заработал, и вывести деньги, причём сразу), и к покупателю (чтобы он мог видеть его в своих заказах и отслеживать свою задолженность).

Когда делали описанные выше проекты я хотел использовать cs-cart или аналог. Но пришёл к банальным выводам и проблемам таких CMS для маркетплейсов для разработчика:

Вот к какому результату пришёл:

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

Жизнь показала, что это не так, и сайт нужен хотя бы для SEO-продвижения: продвигать приложение – удовольствие дорогое. Гораздо выгоднее пригнать трафик на сайт и уже там убедить клиента скачать приложение на телефон. А для MVP-версии нужно и то, и другое.

Серверная часть

Как и писал, много предложений сделать классический маркетплейс на Битриксе, есть CS-Cart с отдельным модулем. В нашем случае php-решение не подходит, т. к. нам хочется делать решения, работающие в режиме реального времени (подробно я расскажу в статье про уход от Битрикса). В итоге мы пришли к двум вариантам реализации серверной части.

1. Firebase. Подойдёт в случаях, если сервис запускается за рубежом или полностью устраивает облако. Например, если ваш проект будет работать где-то в Турции, вы просто привязываете карту и ни о чём не думаете. Ни о хостинге и о том, что его нужно продлить, ни о мощностях, т. к. Firebase выделяет ту мощность, которая необходима сервису, пусть даже в нём 250 тысяч человек, как в одном из наших проектов. Тарификация идёт за трафик, и самое важное – правильно настроить запросы, чтобы не было флуда. Цена владения даже ниже, чем покупка обычного VDS у классического провайдера.

2. Node. JS + MongoDB. Решение для запуска в России, где по закону персональные данные можно хранить только внутри страны, или при нежелании пользоваться облачными решениями.

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

Кстати, о скорости: напишите в комментариях, насколько для вас в запуске MVP критична скорость его работы – некоторых устраивает задержка отображения в 5 секунд (само собой, для теста, а не для конечного продукта), но кому-то быстрый отклик может быть критичен уже на первых порах. буду рад прочесть ваше мнение и касательно двух вариантов серверной части – напишите, считаете ли вы более удобной облачную или клиент-серверную инфраструктуру.

Если есть основатели, планирующие запуск товарного маркетплейса, буду рад пообщаться. Сейчас задача даже не продать заготовку, а узнать про ключевой функционал, который планируете в MVP, чтобы я учёл его в следующей версии продукта. Мои контакты d@brightmobile. ru, whatsapp +79178232748

Ну и в завершение, несколько скринов проекта, который сейчас готовим к релизу на текущей версии готового решения: