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

⟶ Рассмотрим, каким мог бы быть идеальный сервис по работе на нескольких маркетплейсах.

Содержание

Типы продавцов
Задачи продавцов на маркетплейсах
Операционные задачи на маркетплейсах
Почему до сих пор нет enterprise-решения для торговли на маркетплейсах
Мини-книга в PDF ⚡

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

Типы продавцов

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

1

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

2

Ритейлеры, для которых МП является дополнительной витриной.

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

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

Задачи продавцов на маркетплейсах

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

Операционные задачи

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

Маркетинговые задачи

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

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

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

Операционные задачи на маркетплейсах

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

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

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

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

1

Максимально легко интегрируется с уже работающими системами;
2

Снимает с ритейлера задачу настройки обмена данными с многочисленными маркетплейсами;
3

Обеспечивает корректность преобразования потоков данных и их маппинг с внешними витринами.

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

Товарный контент

Импорт товаров из систем продавца

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

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

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

Показывать сроки действия сертификатов и их статус: валидный, скоро просрочится, просрочился;
4

Автоматически привязывать нужные сертификаты к товарам.

Готовность к публикации

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

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

1

Показывать процент готовности к публикации на каждом из маркетплейсов;
2

Подсвечивать, какие еще требования каждой площадки необходимо выполнить, чтобы товар можно было выставить на продажу;
3

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

История изменений карточек товаров

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

1

Фиксировать дату, время, автора и характер изменения товарного контента;
2

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

Цены и стоки

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

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

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

Работа с заказами

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

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

1

Обеспечить маппинг и унификацию статусов заказов между разными МП и собственными системами продавца;
2

Получать новые заказы со всех МП и пробрасывать их в мастер-системы;
3

Обеспечивать транзит статусов заказов между МП и OMS продавца;
4

Отображать перечень заказов со всех площадок и историю изменения статусов по ним.

Названия схем продаж товаров на основных маркетплейсах

Тарифы и сроки доставки для схем DBS

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

Материалы: Яндекс (тарифы, сроки).

Управление пользователями

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

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

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

Почему до сих пор нет enterprise-решения для торговли на маркетплейсах

1

Создать такое решение сложно, так как главные площадки слишком сильно отличаются друг от друга, и каждая из них еще и активно развивается и часто меняет API и процессы;
2

Маркетплейсы нацелены на работу c относительно небольшими продавцами, которые должны пользоваться их экосистемами, поэтому развиваются в первую очередь личные кабинеты площадок;
3

Вокруг маркетплейсов развивается рынок продуктов и сервисных компаний, но они так же нацелены на продавцов, для которых маркетплейсы — основной канал;
4

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

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

Запуск Ensi Cloud Feed состоится в 2024 году

Оставляйте предварительную заявку на демо