Как мы разрабатываем маркетплейс для маркетплейсов

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

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

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

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

В рамках MVP загрузку номенклатуры мы сделали через CSV-файл, а при добавлении новых товаров или снятия их с производства файл просто подгружается заново. Сервис автоматом определяет, куда загружать базу и распределяет товары на Озон, Вайлдберис и на Яндекс.Маркет.

Главной проблемой для нас стало API маркетплейсов. У Яндекс.Маркета оно было вполне приличное, к нему претензий практически не было (хотя кое-что в документации и было написано двояко). Другое дело – Wildberries... Адекватный API у него появился только осенью прошлого года: маркетплейс хоть и уже давно раскрученный, а поставщики по-прежнему загружали на него свою номенклатуру через ЛК.

Осенью 2020 года Wildberries наконец заявили, что они доделали своё API – правда, немножко покривили душой, т.к. картинки через неё до сих пор нельзя нормально загрузить. Почти сразу после запуска что-то сломалось, и вот уже три месяца, как они всё это дело чинят. Из-за этого изображения поставщику приходится добивать вручную, на данный момент эту функцию взял на себя администратор сервиса нашего заказчика.

У Ozon тоже были кое-какие нюансы, но по сравнению с Вайлдберис всё отлично, жаловаться просто грех.

На стороне поставщика в любом случае должен быть программист, который настраивает API и тот, кто формирует CSV-файл. Сейчас перед нами стоит задача выйти на поставщиков более мелкого уровня, а у них как раз особенно наблюдается отсутствие денег на внутреннюю автоматизацию и адекватное подключение к API маркетплейсов.

Вообще, вся эта идея «маркетплейса для маркетплейсов» потому и родилась, что у программистов поставщика часто не хватает знаний, умений или денег, чтобы самим сделать прямые интеграции. Агрегатор нашего заказчика упрощает и удешевляет этот процесс. Мы заметили, что кроме крупных, у средних и малых поставщиков есть необходимость в подобном решении. И наша задача – взять их всех на себя: их много, и крупному бизнесу они неинтересны.

Получается, что у Агрегатора теперь будет фронтенд, который делится на две части.

• Публичная – небольшой сайт, описывающий идею, преимущества и условия использования продукта.
• Личный кабинет поставщика. API не потребуется, так же, как не потребуется и нанимать программиста или заниматься другими сложными задачами. Вместо этого можно воспользоваться ЛК, и загружать базу товаров через него.

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

Именно здесь производитель загружает CSV-файл со всеми товарными остатками. Отсюда они уходят в уже созданный функционал и раскидываются по маркетплейсам. Также пользователь может регулировать здесь количество остатков, продолжая передавать их по API или вручную. Решили оставить оба варианта, чтобы удобно было и большим компаниям, и маленьким, у которых в номенклатуре лишь несколько десятков позиций.

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

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

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

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

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

Фишка Агрегатора в том, что за пользование берётся не абонентская плата, как в некоторых аналогах, а процент с заказов. И за этот процент поставщики (особенно малые) существенно упрощают свой бизнес, получая в рамках этого автоматизированного сервиса и отдел маркетинга, и отдел продаж, и отдел сбыта. Совсем как Яндекс.Еда в ресторанном бизнесе – подключаешься, загружаешь и продаёшь. За доставку и клиентов беспокоится уже сам Яндекс. Всё, что делает ресторан – получает заказы и передаёт их курьеру.

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

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

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

Другой важный момент – не привязываться к одному поставщику, например, к Wildberries. Допустим, вы придумали какую-то фишку, которая улучшает работу поставщика с этим маркетплейсом. В итоге, он просто заберёт её себе, а вы останетесь без бизнеса. Наш агрегатор рассчитан на несколько маркетплейсов, и как бы Я.М, Озон или Вайлдберис ни старались, украсть эту идею они не смогут, даже если захотят, ведь она рассчитана не только на них, а на весь рынок маркетплейсов в целом.

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

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

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