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

• Маркетплейс: архитектура, программирование, учетная система, маркетинг и много другое
  • Почему идея маркетплейсов так популярна?
• Организация данных
  • Партнеры
  • Юнит-экономика и монетизация
  • Доставка
  • Каталог
• Архитектура маркетплейса
  • Общее устройство маркетплейса
  • Интеграция с партнерами
  • Сопоставление данных
  • Как все это организовать
  • Актуальность данных
  • Геозависимость
  • Мобильное приложение
  • Внутренние интеграции
• План действий
  • Этап 1: Бизнес-MVP
  • Этап 2: Выбор подрядчиков, создание единой команды
  • Этап 3: Технический концепт
  • Этап 4: MVP и запуск
  • Этап 5: Эксплуатация и рост
  • Этап 6: Оптимизация
  • Далее
• Поработаем?

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

Маркетплейс: архитектура, программирование, учетная система, маркетинг и много другое

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Партнеры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доставка

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

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

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

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

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

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

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

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

Каталог

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

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

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

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

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

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

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

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

Основа основ — каркас, который создаётся в самом начале проекта. Его перестройка всегда будет долгим и дорогим квестом.

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

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

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

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

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

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

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

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

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

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

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

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

С каждым партнером нужно наладить обмены:

1. Редко:

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

2. Часто:

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

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

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

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

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

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

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

Чем обмениваемся	Периодичность	Направление	На коленке	Золотая середина	Как в лучших домах Европы
Товары	Редко	Партнер → МП	Партнер и ваш контент-менеджер связываются по E-mail или телефону и общаются по заказу. Ваш контент-менеджер дымится и вносит все вручную в вашу учетную систему.	Партнер предоставляет товарный фид или вносит товары в ЛК на сайте, или в вашей учетной системе (потребуется настройка прав)	Интеграция с (каждым!) партнером (фиды, FTP, веб-сервисы и т.д. ). Партнеры работают со своей учетной системой, ваши сотрудники — в вашей.
Цены	Часто	Партнер → МП
Остатки	Часто	Партнер → МП
Заказы	Часто	МП → Партнер		Партнер работает на сайте маркетплейса или в вашей учетной системе (потребуется настройка прав)
Статусы заказов	Часто	Партнер → МП
Состав заказов	Часто	Партнер → МП

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бизнес	IT-команда от бизнеса	Подрядчик WEB	Подрядчик УС	Партнеры
Найти партнеров	Получить от партнеров прайс-листы	Разработать сайт маркетплейса (дизайн, код, инфраструктура)	Разработать учетную систему для сотрудников	(Необязательно, но желательно) Доработать свои IT-системы для обмена с маркетплейсом
Выбрать схему монетизации	Составить собственный каталог (разделы, свойства)		Настроить правила преобразования товаров и значений свойств товаров в собственный каталог
Выбрать схему доставки	(Не для light-маркетплейса) Сопоставить товары		(Для light-маркетплейса) Скопировать товары
Преобразовать бизнес-процессы компании для запуска маркетплейса			(Не для light-маркетплейса) Разработать инструмент сопоставления товаров
		Разработать обмен: Сайт-УС
			Разработать обмен УС-Партнер

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

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

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

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

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

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

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

1. Шина ESB

2. REST API сайта

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

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

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

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

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

Интеграция	Достоинства	Недостатки
Типовая (например, БУС-1С)	Работает сразу	Ограничена скорость обмена Слабо поддается доработке
Обмен файлами по FTP	Простая реализация	Отсутствует обратная связь между приемником и источником данных
Непосредственная работа учетной системы с БД сайта	Архитектура маркетплейса не усложняется, нет новых узлов Максимально возможная скорость обмена	Специалистам по доработке учетной системы нужно очень хорошо представлять устройство БД сайта Легко испортить данные на сайте
Веб-сервисы, например REST API	Компромисс по скорости и надежности	Требуется большая доработка с обеих сторон (учетная система и сайт)
Промежуточная БД	Максимально возможная скорость обмена	Требуется большая доработка с обеих сторон (учетная система и сайт) Усложняется архитектура маркетплейса

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

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

Кратко и тезисно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Далее

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

Поработаем?

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

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

Вам может быть интересно:

Разработка и запуск маркетплейса

Больше информации про интранет-системы в нашем телеграм-канале: https://t.me/r4intranet.