Маркетплейс. Архитектура и организация
— А у вас нет такого же, но с перла… с перламутровыми пуговицами?
— К сожалению, нет.
— Нет? Будем искать.
Из к/ф «Бриллиантовая рука»
Что такое маркетплейс?
Поначалу его легко перепутать с интернет-магазином. Понятная структура сайта, обычный дизайн, и сотни тысяч товаров в каталоге. И вот что странно — у каждого не одна цена, а сразу десять.
Карточка товара на сайте-маркетплейсе. Количество цен и кнопок “В корзину” может поставить в тупик.
Вот такой он, маркетплейс. Неприметный на первый взгляд, но дьявольски сложный внутри.
собирает на одной площадке нескольких продавцов (обычно их называют партнерами);
с каждой продажи оставляет себе процент;
дружелюбен к новым партнерам, обычно предлагает несколько простых способов интеграции.
Покупатели и интернет-магазины до и после прихода маркетплейсов
Из этих принципов вытекают приятные «побочные эффекты»: бешеный трафик и высокие позиции в поисковиках. Оказаться в выдаче выше чем производитель — норма для маркетплейса.
Примеров много. Свой “Amazon” сделали Wildberries, Яндекс (сначала Маркет, потом «Беру!», потом снова Маркет), goods.ru. Примеры поменьше, но верные той же идее: Ozon, Delivery Club, АСНА.
Почему идея маркетплейсов так популярна?
Дело в том что маркетинг, продажа, доставка и другие услуги не менее важны чем производство и сам товар. В современном мире все это еще и очень дорого. Причина популярности маркетплейсов чисто экономическая: производителям и мелким ритейлерам просто не под силу строить собственные торговые механизмы.
В реальном мире мелкие магазинчики вытесняются огромными супермаркетами, в онлайне – маркетплейсы медленно, но верно уничтожают интернет-магазины. Это общемировая тенденция.
Выживут только бутиковые компании – у них узкая, но супер-лояльная аудитория. Впрочем, в пандемию даже нишевые товары от условно-массового ecco до сумок Karl Lagerfeld доступны в Wildberries.
В любом случае у торговой компании в 2021 году всего два пути: или влиться в какой-то маркетплейс, или самой стать маркетплейсом. Выбор пока есть.
Эта статья — об архитектуре таких проектов и задачах, которые предстоит решить для его запуска, основанная на нашем опыте работы с маркетплейсами ( ЕВРАЗ Маркетплейс , маркетплейс лекарств , развитие сайта АСНА ).
Организация данных
Партнеры
Маркетплейс невозможен без партнеров. Это отправная точка для круговорота Партнеры -> Товары -> Пользователи -> Заказы -> Новые Партнеры.
Идеальный круговорот маркетплейса
Чтобы партнеров было много, им нужны:
Выгодные условия сотрудничества. Комиссия за заказ должна окупаться оборотом, который вы дадите. Маркетплейс должен сбалансировать комиссию заказов партнера с долгосрочной выгодой от присутствия его товаров на сайте.
Понятная отчетность. И маркетплейс, и партнер должны отлично — и одинаково — понимать, кому что причитается. Стандартный отчет по продажам интернет-магазина для такого не годится, нужно разрабатывать собственный. И, разумеется, партнерам нужен способ самостоятельно сформировать такой отчет в личном кабинете маркетплейса.
Простое подключение. У маркетплейса должны быть два-три типовых механизма подключения (например, интерфейс в личном кабинете для ручной загрузки товаров и поддержка фида YML). И должна быть IT-команда (инхаус или проверенный подрядчик), чтобы разработать интеграцию с нуля (если сразу понятно, что выгода от подключения партнера покрывает затраты на разработку).
Юнит-экономика и монетизация
Кто будет обрабатывать платежи?
Схема монетизации 1
Вариант 1. Платежи принимает маркетплейс, а потом переводит деньги партнерам за вычетом комиссии и налогов. Выплаты могут быть в установленные даты (как у Ozon — 2 раза в месяц) или после доставки заказа.
Схема монетизации 2
Вариант 2. Платежи принимают партнеры, а потом сами оплачивают комиссию маркетплейсу.
Обе схемы годятся для полной предоплаты. Нюансы оплаты при получении обсудим в разделе о доставке.
Плюсы первой схемы:
полный контроль маркетплейса над платежами;
выгоднее в реализации — один раз настроить интеграцию с банком для приема оплаты в обход агрегаторов и пользоваться годами.
Партнерам же удобнее вторая схема: деньги поступают сразу же после покупки, а комиссию нужно платить когда-то потом (или платить за размещение/клики заранее). Если с поиском новых партнеров проблемы, стоит попробовать второй вариант взаиморасчетов.
Возвраты в обоих случаях — процесс неприятный. При второй схеме он еще и перегружен участниками. В процессе участвует покупатель, маркетплейс (как посредник, которому и предъявляют претензию в первую очередь), продавец и платежный агрегатор.
Доставка
Как и в случае с оплатой, есть две противоположных схемы оплаты:
Доставкой занимается маркетплейс (сам или через службу доставки). Если у маркетплейса нет собственного склада, то реализуется классическая схема дропшиппинга — прямая поставка покупателю без хранения товаров на промежуточных складах.
Доставкой занимается партнер (сам или через службу доставки)
Доставкой занимается маркетплейс
Доставкой занимается партнер
Если у вас собственная служба доставки, готовая к росту количества посылок, то вам больше подходит первая схема, в остальных случаях лучше передать часть опецарий фулфилмента партнерам.
В обеих схемах действует правило: тот, кто взаимодействует со службой доставки, тот с ней и рассчитывается (в противном случае речь шла бы о трехстороннем договоре, а это слишком усложнит жизнь как маркетплейсу, так и партнерам).
Во втором случае на сайте маркетплейса должна быть реализована интеграция со всеми возможными службами доставки всех партнеров хотя бы на уровне калькулятора цен и сроков.
Каталог
Каталог состоит из трех частей: дерева каталога, перечня свойств и списка товаров.
Дерево каталога поможет составить SEO-специалист. Взять готовое дерево вряд ли получится — ассортимент маркетплейса шире, чем у партнеров, да и SEO-шники у каждого свои. Удачный пример универсального классификатора публикует Яндекс.Маркет (файл категорий market_categories.xls обновляется ежедневно): в нем
3700 категорий, при этом корневых разделов всего 18 (немного для маркетплейса, торгующего всем на свете).
Перечень свойств основан на перечнях партнеров. Основан, но не равен их «логической сумме». Дьявол кроется в различии названий свойств партнеров и «блуждающими» единицами измерения. Можно ли объединить под «одной крышей» свойства разных продавцов «Вес», «Вес, кг» и «Масса»? Решать должен эксперт, а не софт.
Список товаров. У каждого производителя своя номенклатура и свои артикулы. Отыскать у двух разных партнеров один и тот же товар — задача нетривиальная. Потребуется инструмент для сопоставления товаров (и он должен быть рассчитан на десятки партнеров).
- Бонус. После сопоставления товаров и свойств требуется получить корректные значения свойств. «0.5 кг», «0,5» и «500 гр» — одно и тоже для человека, но не для софта.
Сопоставляются не каталоги, а товары. Группы каталога у маркетплейса должны быть свои
Сопоставление свойств и товаров — работа, которую нельзя полностью автоматизировать. Но можно ускорить, разработав инструмент в помощь самому незаменимому для маркетплейса сотруднику — категорийному менеджеру.
Архитектура
Общее устройство маркетплейса
А теперь поговорим о технике и тонкостях реализации. А если вы хотите обсудить свою задачу с нашим менеджером — оставьте заявку на разработку маркетплейса в форме в конце статьи.
В предложенной «типовой архитектуре маркетплейса» система распределена по трем серверам.
Учет товаров, сопоставление аналогов и управление деревом каталога происходит в учетной системе маркетплейса.
Точкой входа для партнеров является ESB (enterprise service bus — сервисная шина предприятия). О предпосылках использования сервисной шины для тяжелых веб-проектов мы уже писали в нашем блоге. Она отлично подходит для такого вида проектов, разгружая учетную систему и сайт.
Сайт выводит каталог, оформляет заказы, взаимодействует с платежными шлюзами и службами доставки (как в схеме с обычным ИМ) и также взаимодействует с ESB.
Важно: Сервер «FRONT» в любой момент может превратиться в кластер серверов.
В отдельных случаях роль ESB может заменить учетная система (но сайт — никогда). От ESB можно отказаться при смягчающих условиях, например:
товары не надо стандартизировать (если вы уговорили партнера использовать ваш фид);
товары не надо сопоставлять (если ваши партнеры не пересекаются (и не пересекутся) по ассортименту. Такой проект можно назвать light-маркетплейсом, потому что это снимает огромный пласт задач с учетной системы и/или ESB).
Убирать ESB в иных случаях, особенно в целях экономии бюджета — значит нагрузить учетную систему так, что она уже не поднимется.
Интеграция с партнерами
С каждым партнером нужно наладить обмены:
- Получать товары партнера
2. Часто:
- Получать цены товаров партнера
- Получать остатки товаров партнера
- Передавать заказы партнерам
- Получать статусы заказов партнера
Большие маркетплейсы требуют от партнеров файлы фидов или предоставляют личный кабинет на сайте (удобно, если у партнера ассортимент небольшой).
А вот маркетплейс-новичок не может диктовать условия рынку и вынужден поначалу подстраиваться под каждого партнера.
Для каждого варианта интеграции мы предложили по три способа:
На коленке — разрабатывать почти ничего не нужно, но пользоваться этим не слишком-то удобно. Ответственным сотрудникам придется вносить или вытаскивать данные вручную, заниматься их пост- или пред-обработкой, исполнять длинные инструкции.
Золотая середина — несколько недель разработки и достаточно удобный интерфейс. Самые сложные задачи выполняются без участия человека.
Как в лучших домах Европы — после нескольких месяцев разработки все работает само, необходимо только мониторить процессы.
Как в лучших домах Европы
Партнер и ваш контент-менеджер связываются по E-mail или телефону и общаются по заказу. Ваш контент-менеджер дымится и вносит все вручную в вашу учетную систему.
Партнер предоставляет товарный фид или вносит товары в ЛК на сайте, или в вашей учетной системе (потребуется настройка прав)
Интеграция с (каждым!) партнером (фиды, FTP, веб-сервисы и т.д. ).
Партнеры работают со своей учетной системой, ваши сотрудники — в вашей.
Партнер работает на сайте маркетплейса или в вашей учетной системе (потребуется настройка прав)
Сопоставление данных
Одна из самых больших задач для старта маркетплейса. Нужно сопоставлять тысячи свойств и сотни тысяч товаров всех партнеров. И делать это придется достаточно часто (при подключении новых партнеров, при обновлении каталогов).
Товары в маркетплейс дают партнеры. Иногда разные партнеры продают один и тот же товар.
Для первого партнера алгоритм наполнения каталога простой — скопировать товар в свою базу. Сложность становится видна лишь со второго партнера. Если второй продает такой же товар, как и первый, нужно эти товары как-то сопоставить. И этот процесс очень трудно полностью автоматизировать. Артикулы производителя есть не у всех. А если и есть — они могут отличаться. Сравнивать по названию — несколько примеров из этой статьи показывают, какие ошибки при этом можно пропустить.
Выбирать свойства для сопоставления, управлять правилами преобразования — очень кропотливая работа
Можно внедрить сколько угодно инструментов поиска дублей в каталоге, но он либо будет находить совсем очевидные клоны, либо начнет сливать воедино «iPhone X» и «iPhone XR». Так что от ручной работы тут никак не уйти.
Хотя некоторые маркетплейсы (в том числе и гиганты) сдались на этой задаче и просто выдают пользователям многочисленные копии товаров от разных поставщиков без какого-либо сопоставления.
Пример поисковой выдачи на OZON. Найдено 433 экземпляра одного и того же светильника.
Фрагмент ER-диаграммы маркетплейса
Для решения этой задачи категорийному менеджеру понадобится удобный инструмент. Excel’ем тут не обойтись, нужен специально изготовленное программное обеспечение. Для комфортной работы с каталогами категорийному менеджеру понадобятся следующие экраны.
Список партнеров с возможностью быстро отключать их от маркетплейса
Сводный список всех товаров маркетплейса с быстрым обзором всех аналогов в разрезе по партнерам
Список товаров каждого партнера, с фильтром «сопоставлен-не сопоставлен»
Карточка товара маркетплейса с возможностью сопоставления с товаром каждого партнера
Карточка товара маркетплейса (цены и остатки)
Как все это организовать
Разработка и запуск маркетплейса требуют значительной вовлеченности со стороны бизнеса. Требуется отыскать партнеров и договориться с ними об условиях сотрудничества, определиться со схемой монетизации и доставки. И самый серьезный процесс — внутренние преобразования компании.
В процесс разработки и эксплуатации маркетплейса также должны быть вовлечены:
IT-команда от бизнеса. Она обязана быть, если вы созрели до разработки маркетплейса.
Подрядчик по WEB и по учетной системе
Партнеры. Совсем без их участия сделать ничего не получится, нужно сразу закладывать в стоимость проекта совместное проектирование, разработку и тестирование обменов.
Распределение остальных обязанностей по ролям приведено в таблице ниже.
Источник