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

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

Можно выделить два типа продавцов на маркетплейсах:

1. Профессиональные селлеры, для которых МП — основной канал продаж;
2. Ритейлеры, для которых МП является дополнительной витриной.

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

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

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

К операционным задачам относятся:

1. Размещение и актуализация товарного контента, а также управление стоками (если FBS/DBS) и ценами. В том числе, централизованное управление товарами на разных площадках;
   
2. Обработка и исполнение заказов (если продавец работает по FBS/DBS);
3. Документооборот, работа с отчетностью и финансами.

1. Аналитика продаж. В том числе, аналитика конкуренции, товарных ниш и самих товаров;
2. Управление маркетинговыми инструментами маркетплейсов;
3. Работа с отзывами: аналитика отзывов и автоматизация ответов.

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

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

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

Идеальное решение:

• Максимально легко интегрируется с уже работающими системами;
• Снимет с ритейлера задачу настройки обмена данными с многочисленными маркетплейсами;
• Обеспечит корректность преобразования потоков данных и их маппинг с внешними витринами.

Посмотрим, какие именно задачи может решать идеальный сервис.

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

1. Импорт фидов и файлов в разных форматах: YML, Google Merchant, Excel, CSV и других. Практически любой ритейлер использует хотя бы один их этих форматов в маркетинге;
2. Передача товарных данных по API: более быстрый и тонко настраиваемый способ импорта товаров;
3. Периодичность и состав импортов должна быть настраиваемой в интерфейсе сервиса;
4. Система должна справляться с большим количеством обновлений, так как крупные ритейлеры могут оперировать сотнями тысяч артикулов за один раз.

Категорийные деревья на разных маркетплейсах не похожи друг на друга, и все они отличаются от классификации самого продавца. Например, «Кормление собаки», «Миски и поилки» и «Аксессуары для кормления» это разные названия одной категории в 3-х маркетплейсах.

Сервис должен управлять сопоставлением категорий:

1. Маппинг категорий настраивается отдельно для каждого маркетплейса;
2. Система должна автоматически маппить категории по названию (желательно с учетом морфологии и минимального словоизменения);
3. Можно как угодно управлять маппингом вручную: устанавливать связи один-ко-многим, многие-к-одному, при этом можно задавать правила фильтрации товаров категории;
4. Администратор сервиса должен получать уведомления об изменении категорийного дерева со стороны маркетплейсов.

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

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

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

Сервис должен:

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

И, наконец, отдельно отметим значения атрибутов. Маркетплейсы, как правило, не ограничивают продавцов в возможности задавать значения атрибутов. Однако продавец может сам посчитать целесообразным адаптировать данные под разные маркетплейсы. Например, объединить цвета «Бургунди» и «Алый» в просто «Красный» или добавить к названию коллекции год или название бренда.

От сервиса требуется:

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

В разных маркетплейсах объединение товаров в одну карточку по цвету, размеру или другим характеристикам устроено по-разному. В PIM-системах ритейлеров, как правило, товары уже каким-то образом объединены. Эту логику иногда нужно передать на маркетплейс, а иногда отредактировать или отменить. Например, ритейлер продает телефоны Apple и на своих витринах объединяет по цвету и объему памяти все товары одной модели, а на Яндекс Маркете хочет выставить каждый товар в виде отдельной позиции.

От сервиса требуется:

1. Транслировать на МП логику объединения товаров в единую карточку по разным признакам.
2. Управлять логикой объединения товаров в карточки для каждого МП отдельно.
3. Управлять этой логикой по категориям или по-товарно.

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

1. Автоматическая проверка соответствия изображений требованиям каждого из МП. Например, типы и размер файлов.
2. Выбор для каждого МП отдельно, какие фото- и видео-материалы будут опубликованы.
3. Выбор заглавного изображения или видео для каждого МП отдельно.
4. Rich-контент также не поддается стандартизации и требует работы с инструментами каждого маркетплейса отдельно.

Из крупных площадок по API умеет работать только Ozon. На остальных МП сертификаты добавляются только через ЛК и после этого их ID нельзя получить через запросы.

Сервис должен:

1. Отображать список брендов, для которых требуются сертификаты.
2. Подгружать сертификаты из мастер-систем продавца, добавлять их на МП (автоматизированно только Ozon, у остальных только через ЛК).
3. Показывать сроки действия сертификатов и их статус: валидный, скоро просрочится, просрочился.
4. Автоматически привязывать нужные сертификаты к товарам.

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

Сервис должен:

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

Большое количество товаров, площадок и сотрудников отдела товарного контента — причины неизбежных коллизий. Чтобы эффективно расследовать причины тех или иных ошибок, нужно логировать изменения:

1. Фиксировать дату, время, автора и характер изменения товарного контента.
2. Откатываться к предыдущим состояниям там, где это возможно.

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

Сервис должен:

1. Уметь подключаться к потокам данных мастер-систем по ценам и стокам. В том числе в API должны быть реализованы методы, по которым мастер-системы принудительно передают новые данные.
2. Максимально быстро отправлять изменившиеся данные на все подключенные площадки.
3. Отслеживать ситуации, когда цены меняются слишком сильно, чтобы предупреждать ошибочные продажи. Настраивать дельту, при достижении которых отправляется предупреждение (меньшая дельта) или блокируются продажи (большая дельта).
4. Отображать актуальные цены, по которым продаются товары на каждой площадке.
5. Отображать актуальные остатки и резервы по всем складам.
6. Логировать изменение цен, остатков и резервов по всем маркетплейсам и складам.

Заказы на маркетплейсах требуют разного подхода в зависимости от схемы продаж: FBO, FBS или DBS. Когда продавец собирает заказы самостоятельно, ему нужно их отслеживать и обрабатывать, и многие ритейлеры делают это в собственных специализированных системах — OMS. Задача сервиса — агрегрегировать заказы со всех маркетплейсов, унифицировать их и передать в мастер-системы.

Сервис должен:

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

Каждый из маркетплейсов рассчитывает сроки и стоимость доставки по-своему, поэтому унифицировать и стандартизировать эти показатели не получится. Они настраиваются в ЛК каждого из маркетплейсов и применяются ко всем заказам автоматически. Материалы: Яндекс (тарифы, сроки).

Концепция сервиса подразумевает, что мастер-данные и инструменты их создания/преобразования находятся во внешних системах ритейлера или ЛК маркетплейсов. Поэтому сервису не требуется сложная ролевая модель. Достаточно:

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

Отдельно стоит отметить способность интегрироваться с ролевыми сервисами ретейлеров

1. Создать такое решение сложно, так как главные площадки слишком сильно отличаются друг от друга и каждая из них еще и активно развивается и часто меняет API и процессы.
2. Маркетплейсы нацелены на работу c относительно небольшими продавцами, которые должны пользоваться их экосистемами, поэтому развиваются в первую очередь личные кабинеты площадок.
3. Вокруг маркетплейсов развивается рынок продуктов и сервисных компаний, но они так же нацелены на продавцов, для которых маркетплейсы — основной канал.
4. Крупные ритейлеры, которые часто сами являются IT-компаниями, занимаются собственными задачами и не думают о создании универсального enterprise-решения для быстрой интеграции с ведущими маркетплейсами.

Чтобы осилить разработку такого решения, нужно иметь достаточно ресурсов, опыта в отрасли и понимание того, как устроены большие ритейлеры. Команда платформы Ensi работает над Ensi Cloud Feed — первым enterprise-решением, которое позволит быстро интегрировать мастер-системы с главными маркетплейсами.