Маркетплейс. Архитектура и организация

— А у вас нет такого же, но с перла… с перламутровыми пуговицами? 
— К сожалению, нет. 
— Нет? Будем искать. 
Из к/ф «Бриллиантовая рука»

Что такое маркетплейс?

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

Карточка товара на сайте-маркетплейсе. Количество цен и кнопок “В корзину” может поставить в тупик.

Вот такой он, маркетплейс. Неприметный на первый взгляд, но дьявольски сложный внутри.

Принципы маркетплейса:

• собирает на одной площадке нескольких продавцов (обычно их называют партнерами);

• с каждой продажи оставляет себе процент;

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

Покупатели и интернет-магазины до и после прихода маркетплейсов

Из этих принципов вытекают приятные «побочные эффекты»: бешеный трафик и высокие позиции в поисковиках. Оказаться в выдаче выше чем производитель — норма для маркетплейса.

Примеров много. Свой “Amazon” сделали Wildberries, Яндекс (сначала Маркет, потом «Беру!», потом снова Маркет), goods.ru. Примеры поменьше, но верные той же идее: Ozon, Delivery Club, АСНА.

Почему идея маркетплейсов так популярна?

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

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

Выживут только бутиковые компании – у них узкая, но супер-лояльная аудитория. Впрочем, в пандемию даже нишевые товары от условно-массового ecco до сумок Karl Lagerfeld доступны в Wildberries.

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

Эта статья — об архитектуре таких проектов и задачах, которые предстоит решить для его запуска, основанная на нашем опыте работы с маркетплейсами ( ЕВРАЗ Маркетплейс , маркетплейс лекарств , развитие сайта АСНА ).

Организация данных

Партнеры

Маркетплейс невозможен без партнеров. Это отправная точка для круговорота Партнеры -> Товары -> Пользователи -> Заказы -> Новые Партнеры.

Идеальный круговорот маркетплейса

Чтобы партнеров было много, им нужны:

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

2. Понятная отчетность. И маркетплейс, и партнер должны отлично — и одинаково — понимать, кому что причитается. Стандартный отчет по продажам интернет-магазина для такого не годится, нужно разрабатывать собственный. И, разумеется, партнерам нужен способ самостоятельно сформировать такой отчет в личном кабинете маркетплейса.

3. Простое подключение. У маркетплейса должны быть два-три типовых механизма подключения (например, интерфейс в личном кабинете для ручной загрузки товаров и поддержка фида YML). И должна быть IT-команда (инхаус или проверенный подрядчик), чтобы разработать интеграцию с нуля (если сразу понятно, что выгода от подключения партнера покрывает затраты на разработку).

Юнит-экономика и монетизация

Кто будет обрабатывать платежи?

Схема монетизации 1

Вариант 1. Платежи принимает маркетплейс, а потом переводит деньги партнерам за вычетом комиссии и налогов. Выплаты могут быть в установленные даты (как у Ozon — 2 раза в месяц) или после доставки заказа.

Схема монетизации 2

Вариант 2. Платежи принимают партнеры, а потом сами оплачивают комиссию маркетплейсу.

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

Плюсы первой схемы:

• полный контроль маркетплейса над платежами;

• выгоднее в реализации — один раз настроить интеграцию с банком для приема оплаты в обход агрегаторов и пользоваться годами.

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

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

Доставка

Как и в случае с оплатой, есть две противоположных схемы оплаты:

1. Доставкой занимается маркетплейс (сам или через службу доставки). Если у маркетплейса нет собственного склада, то реализуется классическая схема дропшиппинга — прямая поставка покупателю без хранения товаров на промежуточных складах.

2. Доставкой занимается партнер (сам или через службу доставки)

Доставкой занимается маркетплейс

Доставкой занимается партнер

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

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

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

Каталог

Каталог состоит из трех частей: дерева каталога, перечня свойств и списка товаров.

1. Дерево каталога поможет составить SEO-специалист. Взять готовое дерево вряд ли получится — ассортимент маркетплейса шире, чем у партнеров, да и SEO-шники у каждого свои. Удачный пример универсального классификатора публикует Яндекс.Маркет (файл категорий  market_categories.xls обновляется ежедневно): в нем ~3700 категорий, при этом корневых разделов всего 18 (немного для маркетплейса, торгующего всем на свете).

2. Перечень свойств основан на перечнях партнеров. Основан, но не равен их «логической сумме». Дьявол кроется в различии названий свойств партнеров и «блуждающими» единицами измерения. Можно ли объединить под «одной крышей» свойства разных продавцов «Вес», «Вес, кг» и «Масса»? Решать должен эксперт, а не софт.

3. Список товаров. У каждого производителя своя номенклатура и свои артикулы. Отыскать у двух разных партнеров один и тот же товар — задача нетривиальная. Потребуется инструмент для сопоставления товаров (и он должен быть рассчитан на десятки партнеров).

• Бонус. После сопоставления товаров и свойств требуется получить корректные значения свойств. «0.5 кг», «0,5» и «500 гр» — одно и тоже для человека, но не для софта.

Сопоставляются не каталоги, а товары. Группы каталога у маркетплейса должны быть свои

Сопоставление свойств и товаров — работа, которую нельзя полностью автоматизировать. Но можно ускорить, разработав инструмент в помощь самому незаменимому для маркетплейса сотруднику — категорийному менеджеру.

Архитектура

Общее устройство маркетплейса

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

В предложенной «типовой архитектуре маркетплейса» система распределена по трем серверам.

• Учет товаров, сопоставление аналогов и управление деревом каталога происходит в учетной системе маркетплейса.

• Точкой входа для партнеров является ESB (enterprise service bus — сервисная шина предприятия). О предпосылках использования сервисной шины для тяжелых веб-проектов мы уже писали в нашем блоге. Она отлично подходит для такого вида проектов, разгружая учетную систему и сайт.

• Сайт выводит каталог, оформляет заказы, взаимодействует с платежными шлюзами и службами доставки (как в схеме с обычным ИМ) и также взаимодействует с ESB.

Важно: Сервер «FRONT» в любой момент может превратиться в кластер серверов.

В отдельных случаях роль ESB может заменить учетная система (но сайт — никогда). От ESB можно отказаться при смягчающих условиях, например:

• товары не надо стандартизировать (если вы уговорили партнера использовать ваш фид);

• товары не надо сопоставлять (если ваши партнеры не пересекаются (и не пересекутся) по ассортименту. Такой проект можно назвать light-маркетплейсом, потому что это снимает огромный пласт задач с учетной системы и/или ESB).

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

Интеграция с партнерами

1. Редко:

• Получать товары партнера

• Получать цены товаров партнера
• Получать остатки товаров партнера
• Передавать заказы партнерам
• Получать статусы заказов партнера

Большие маркетплейсы требуют от партнеров файлы фидов или предоставляют личный кабинет на сайте (удобно, если у партнера ассортимент небольшой). 

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

Для каждого варианта интеграции мы предложили по три способа: 

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

2. Золотая середина — несколько недель разработки и достаточно удобный интерфейс. Самые сложные задачи выполняются без участия человека.

3. Как в лучших домах Европы — после нескольких месяцев разработки все работает само, необходимо только мониторить процессы.

Сопоставление данных

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

Товары в маркетплейс дают партнеры. Иногда разные партнеры продают один и тот же товар.

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

Выбирать свойства для сопоставления, управлять правилами преобразования — очень кропотливая работа

Можно внедрить сколько угодно инструментов поиска дублей в каталоге, но он либо будет находить совсем очевидные клоны, либо начнет сливать воедино «iPhone X» и «iPhone XR». Так что от ручной работы тут никак не уйти. 

Хотя некоторые маркетплейсы (в том числе и гиганты) сдались на этой задаче и просто выдают пользователям многочисленные копии товаров от разных поставщиков без какого-либо сопоставления.

Пример поисковой выдачи на OZON. Найдено 433 экземпляра одного и того же светильника.

Фрагмент ER-диаграммы маркетплейса

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

Список партнеров с возможностью быстро отключать их от маркетплейса

Сводный список всех товаров маркетплейса с быстрым обзором всех аналогов в разрезе по партнерам

Список товаров каждого партнера, с фильтром «сопоставлен-не сопоставлен»

Карточка товара маркетплейса с возможностью сопоставления с товаром каждого партнера

Карточка товара маркетплейса (цены и остатки)

Как все это организовать

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

В процесс разработки и эксплуатации маркетплейса также должны быть вовлечены:

• IT-команда от бизнеса. Она обязана быть, если вы созрели до разработки маркетплейса.

• Подрядчик по WEB и по учетной системе

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

Распределение остальных обязанностей по ролям приведено в таблице ниже.

Актуальность данных

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

Но и трагедии в этом нет, если к этому подготовиться. Например, в момент добавления в корзину (или открытия карточки товара) маркетплейс сам проверит у партнера актуальный срок поставки, наличие и цену. И честно предупредит пользователя: «мы уточнили у партнера, вместо 100 рублей и доставки завтра это будет 200 и послезавтра». 

Геозависимость

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

Мобильное приложение

При удачной архитектуре (такой, как наша) новые участники экосистемы маркетплейса встроятся без проблем. 

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

1. Шина ESB

2. REST API сайта

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

На первом этапе работы маркетплейса ему может быть достаточно и mobile-версии сайта, без нативных приложений для всех мобильных платформ. Стоит задуматься о прогрессивном веб-приложении (progressive web app, PWA): эта технология набирает хорошие обороты и все меньше сайтов чураются этого решения.

Внутренние интеграции

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

Типовые решения (например, интеграция сайта на 1С-Битрикс и 1С) хорошо справляются с передачей товаров и заказов до какого-то объема. Но если в вашем маркетплейсе больше 300 000 товаров, то вам придется ждать несколько дней(!) прежде чем последний товар загрузится на сайт. Все это время сервер с сайтом будет дымиться, так как он и записи из ESB обрабатывает, и на запросы клиентов отвечает. Ускорять типовой однопоточный обмен докупкой ресурсов сервера до бесконечности не получится. Поэтому, если вы сразу знаете, что объем данных будет колоссальный, нужно быть готовым рано или поздно (лучше рано) решать даже такую типовую задачу, как обмен товарами/ценами/заказами между учетной системой и сайтом (так произошло в нашем проекте ЕВРАЗ Маркетплейс ).

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

План действий

Этап 1: Бизнес-MVP

Бизнес должен «дозреть» до маркетплейса и отыскать партнеров для запуска. На этом этапе ИНТЕРВОЛГА может выступить в качестве консультанта, рассказать “как надо” и “как принято” в мире маркетплейсов.

Этап 2: Выбор подрядчиков, создание единой команды

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

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

Этап 3: Технический концепт

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

Этот этап не должен длиться дольше 2-3 недель. Дальше эту сжатую пружину надо отпустить.

Этап 4: MVP и запуск

Собственно, разработка. Временные рамки нужно задать жестко. Учтите, что 2 месяца — маловато для такого проекта, а 4 уже будет многовато для MVP.

Этап 5: Эксплуатация и рост

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

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

Этап 6: Оптимизация

Спустя полгода после запуска проекта в нем накопится объемный технический долг. К этому времени и картина мира с точки зрения бизнеса может измениться, возникнут новые требования к системе. А значит, настала пора прекратить рост и заняться оптимизацией системы. 

Далее

Повторять этапы 3-6

Поработаем?

Разработка маркетплейса — тяжеловесная задача. На маркетплейс с претензией на отказоустойчивость потребуется не менее 1500 часов веб-разработчиков и столько же на разработку учетной системы.

ИНТЕРВОЛГА может «выдать» такое количество часов в разумный срок и взять на себя обе роли — и сайт и учетную систему на базе 1С. Речь идет, конечно же, сразу о команде из разработчиков, аналитика, верстальщика и дизайнера. Оставьте заявку, и мы обсудим вашу задачу.

    Анатолий Е.