Архитектура маркетплейса27.11.2020 09:47

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

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

Как говорит Википедия, маркетплейс — это платформа e-commerce, онлайн-магазин электронной торговли, предоставляющий информацию о продукте или услуге третьих лиц, чьи операции обрабатываются его оператором. Если объяснять проще, то маркетплейс является торговой площадкой, которая работает по принципу связующего звена между покупателями и продавцами. Поначалу его легко перепутать с интернет-магазином, но между ними — кардинальная разница. У маркетплейса непримечательный дизайн, зато в каталоге сотни тысяч товаров. А у каждого товара — десятки цен.

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

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

• продает чужие товары (партнеров-поставщиков);

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

• легко подключает новых поставщиков.

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

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

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

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

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

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

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

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

Каталог 

Как маркетплейс собирает в одном месте каталоги нескольких поставщиков? Разберемся с теорией.

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

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

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

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

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

Партнеры

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

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

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

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

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

Монетизация

На этапе разработки маркетплейса сразу решается, кто будет заниматься обработкой платежей.

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

Для 100%-ной предоплаты заказа годятся обе схемы. Принимать все платежи самому проще технически и удобнее. От маркетплейса потребуется лишь типовая интеграция с платежным агрегатором.

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

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

Доставка

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

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

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

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

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

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

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

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

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

IT Инфраструктура

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

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

• ESB занимается стандартизацией данных от партнеров, в УС и на сайт данные попадают уже в чистом виде

• Сайт взаимодействует с платежными системами и службами доставки (как в схеме с обычным ИМ)

• Сайт должен быть готов к вынесению БД на отдельный сервер и кластеризации

  

Внешние интеграции (с партнерами)

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

1. Разово или периодически:

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

2. Постоянно:

   1. Получать цены товаров партнера

   2. Получать остатки товаров партнера

   3. Подтверждать заказы товаров у партнера

   4. Получать статусы заказов у партнера

Как это реализовать — вопрос, не имеющий правильного ответа. Большие маркетплейсы делают это через файлы фидов своего стандарта или через личный кабинет партнера (если у партнеров по 10–20 товаров — вполне жизнеспособный вариант). Маленькие и растущие идут навстречу каждому партнеру и, по сути, дорабатывают свой маркетплейс так, чтобы он мог подтягивать данные конкретно этого поставщика. В предельном случае (если каталог небольшой и партнеров немного) задача решается в ручном режиме контент-менеджером, ежедневно актуализирующем информацию на сайте.

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

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

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

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

Интеграция товаров, цен, остатков

Если партнер уже подключен к какому-либо агрегатору или маркетплейсу (например, Яндекс.Маркету), то в первую очередь нужно рассмотреть поддержку именно этого формата. В случае с Яндекс.Маркетом есть хорошо документированный формат YML, который достаточно просто как генерировать, так и читать.

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

Интеграция заказов

Нам о существовании подобных готовых интеграций не известно. Поэтому — только заказная интеграция. Как и в случае с интеграцией товаров, у партнера уже могут быть какие-то решения, если ваш маркетплейс для него не первый (например, партнер может уже быть интегрирован с Беру! и поддерживать их API передачи заказа). Начните с их изучения.

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

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

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

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

Заключение

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

© Habrahabr.ru