Супер-сервис для интеграции с маркетплейсами для крупных ритейлеров
Селлеры на маркетплейсах часто работают сразу на нескольких площадках. И им приходится делать одно и то же с учетом особенностей каждой из них: заводить товары, менять цены, обрабатывать заказы. Посмотрим, каким мог бы быть идеальный сервис по работе на нескольких маркетплейсах.
Типы продавцов
Можно выделить два типа продавцов на маркетплейсах:
- Профессиональные селлеры, для которых МП — основной канал продаж;
- Ритейлеры, для которых МП является дополнительной витриной.
Первые, как правило, полностью полагаются на предоставляемую маркетплейсами инфраструктуру, а также на специализированные сервисы, которые развиваются вокруг крупных торговых площадок.
Вторые — работают в собственных IT-системах, которые нужно интегрировать с маркетплейсами. Другой вариант — создавать дополнительный слой, связанный с мастер-системами и помогающий управлять торговлей на внешних витринах. Об этом дополнительном слое, то есть о специализированных IT-решениях для работы на дополнительных витринах, и поговорим.
Задачи продавцов на маркетплейсах
Развитие бизнеса на маркетплейсах требует работы на двух уровнях: операционном и маркетинговом.
Операционные задачи
К операционным задачам относятся:
- Размещение и актуализация товарного контента, а также управление стоками (если FBS/DBS) и ценами. В том числе, централизованное управление товарами на разных площадках;
- Обработка и исполнение заказов (если продавец работает по FBS/DBS);
- Документооборот, работа с отчетностью и финансами.
Маркетинговые задачи
- Аналитика продаж. В том числе, аналитика конкуренции, товарных ниш и самих товаров;
- Управление маркетинговыми инструментами маркетплейсов;
- Работа с отзывами: аналитика отзывов и автоматизация ответов.
Конкуренция на Озоне, Wildberries, Яндекс Маркете и других маркетплейсах высока. Поэтому недостаточно заниматься только операциями: заводить товары, следить за остатками и обрабатывать заказы. Нужно активно заниматься продвижением.
Но в этой статье мы будем говорить об операционном уровне, потому что маркетинговые инструменты каждой площадки слишком отличаются друг от друга и пока что едва ли поддаются автоматизации и интеграции с системами продавца.
Операционные задачи на маркетплейсах
Перед ритейлерами, которые выходят в новые для себя каналы, стоит задача адаптировать текущие процессы, системы и команды под дополнительные потоки. Причем обычно ценой минимальных изменений в действующем IT-ландшафте.
Такой сервис не должен влиять на работу собственных витрин ритейлера: рождать новую бизнес-логику или менять мастер-данные. Задача приложения — обеспечить бесшовную интеграцию, а также управляемость товарным предложением и транзакциями на внешних витринах.
💡 Важно отметить, что создать сервис единого окна для всех основных площадок не получится. У каждого маркетплейса много особенностей, часть из которых доступны только из личного кабинета и требуют ручного управления. Но основные транзакционные потоки, связанные с товарным контентом, ценами, стоками и заказами можно обрабатываться централизовано.
Идеальное решение:
- Максимально легко интегрируется с уже работающими системами;
- Снимает с ритейлера задачу настройки обмена данными с многочисленными маркетплейсами;
- Обеспечивает корректность преобразования потоков данных и их маппинг с внешними витринами.
Посмотрим, какие именно задачи может решать идеальный сервис.
Товарный контент
Импорт товаров из систем продавца
Для подготовки товарного контента к публикации на маркетплейсах нужно импортировать данные о товарах из мастер-систем ритейлера в сам сервис, назовем его Feed. Причем сервис должен быть готов к разным сценариям;
- Импорт фидов и файлов в разных форматах: YML, Google Merchant, Excel, CSV и других. Практически любой ритейлер использует хотя бы один их этих форматов в маркетинге;
- Передача товарных данных по API: более быстрый и тонко настраиваемый способ импорта товаров;
- Периодичность и состав импортов должна быть настраиваемой в интерфейсе сервиса;
- Система должна справляться с большим количеством обновлений, так как крупные ритейлеры могут оперировать сотнями тысяч артикулов за один раз.
Маппинг категорий
Категорийные деревья на разных маркетплейсах не похожи друг на друга, и все они отличаются от классификации самого продавца. Например, «Кормление собаки», «Миски и поилки» и «Аксессуары для кормления» это разные названия одной категории в 3-х маркетплейсах.
Сервис должен управлять сопоставлением категорий:
- Маппинг категорий настраивается отдельно для каждого маркетплейса;
- Система должна автоматически маппить категории по названию (желательно с учетом морфологии и минимального словоизменения);
- Можно как угодно управлять маппингом вручную: устанавливать связи один-ко-многим, многие-к-одному, при этом можно задавать правила фильтрации товаров категории;
- Администратор сервиса должен получать уведомления об изменении категорийного дерева со стороны маркетплейсов.
Маппинг атрибутов
Так же как и категории на разных маркетплейсах отличаются и атрибуты (а также их значения, о чем ниже). Сервис должен управлять этим процессом:
- Маппинг атрибутов настраивается отдельно для каждого маркетплейса.
- Атрибуты маппятся автоматически по названию.
- Можно связывать любые атрибуты вручную, в том числе менять автоматически созданные связи.
- Администратор сервиса должен получать уведомления об изменении атрибутов со стороны маркетплейсов.
Обратная совместимость
Зрелый продавец пользуется сразу несколькими площадками, каждая из которых организована по своему, к тому же маркетплейсы периодически вносят изменения в свою работу.
Сервис должен:
- Отслеживать изменения и, когда это возможно, бесшовно компенсировать изменения. Например, в случае изменения названий методов API.
- Подсвечивать изменения, которые касаются бизнес-логики. Например, во всех кейсах маппинга говорится об уведомлениях в случае изменений на стороне маркетплейсов.
Управление значениями атрибутов
И, наконец, отдельно отметим значения атрибутов. Маркетплейсы, как правило, не ограничивают продавцов в возможности задавать значения атрибутов. Однако продавец может сам посчитать целесообразным адаптировать данные под разные маркетплейсы. Например, объединить цвета «Бургунди» и «Алый» в просто «Красный» или добавить к названию коллекции год или название бренда.
От сервиса требуется:
- Отдельно для каждого маркетплейса управлять правилами преобразования значений атрибутов.
- Устанавливать целевые значения по схеме один-к-одному и многие-к-одному.
Объединение товаров в одну карточку и создание вариантов по размерам, цветам и другим атрибутам
В разных маркетплейсах объединение товаров в одну карточку по цвету, размеру или другим характеристикам устроено по-разному. В PIM-системах ритейлеров, как правило, товары уже каким-то образом объединены. Эту логику иногда нужно передать на маркетплейс, а иногда отредактировать или отменить. Например, ритейлер продает телефоны Apple и на своих витринах объединяет по цвету и объему памяти все товары одной модели, а на Яндекс Маркете хочет выставить каждый товар в виде отдельной позиции.
От сервиса требуется:
- Транслировать на МП логику объединения товаров в единую карточку по разным признакам.
- Управлять логикой объединения товаров в карточки для каждого МП отдельно.
- Управлять этой логикой по категориям или потоварно.
Управление медиа-контентом
Требования к фото на разных маркетплейсах отличаются. Но в целом, большая часть фотографий, которые использует зрелый ритейлер, подойдет всем основным площадкам. Экзотические требования к фото бывают у новых площадок. Например, у «Спортмастера» название файла с изображением товара должно быть завязано на артикул и цвет.
- Автоматическая проверка соответствия изображений требованиям каждого из МП. Например, типы и размер файлов.
- Выбор для каждого МП отдельно, какие фото- и видео-материалы будут опубликованы.
- Выбор заглавного изображения или видео для каждого МП отдельно.
- Rich-контент также не поддается стандартизации и требует работы с инструментами каждого маркетплейса отдельно.
Сертификаты и бренды
Из крупных площадок по API умеет работать только Ozon. На остальных МП сертификаты добавляются только через ЛК и после этого их ID нельзя получить через запросы.
Сервис должен:
- Отображать список брендов, для которых требуются сертификаты.
- Подгружать сертификаты из мастер-систем продавца, добавлять их на МП (автоматизированно только Ozon, у остальных только через ЛК).
- Показывать сроки действия сертификатов и их статус: валидный, скоро просрочится, просрочился.
- Автоматически привязывать нужные сертификаты к товарам.
Готовность к публикации
Каждый маркетплейс выдвигает свои требования к товарному контенту. Менеджеру продавца важно контролировать готовность к размещению товаров. Например, Озон требует, чтобы название товаров начиналось с большой буквы.
Сервис должен:
- Показывать процент готовности к публикации на каждом из маркетплейсов.
- Подсвечивать, какие еще требования каждой площадки необходимо выполнить, чтобы товар можно было выставить на продажу.
- Предлагать автоматически корректировать названия товаров, чтобы они соответствовали правилам площадок.
История изменений карточек товаров
Большое количество товаров, площадок и сотрудников отдела товарного контента — причины неизбежных коллизий. Чтобы эффективно расследовать причины тех или иных ошибок, нужно логировать изменения:
- Фиксировать дату, время, автора и характер изменения товарного контента.
- Откатываться к предыдущим состояниям там, где это возможно.
Цены и стоки
Продажа товаров, которых нет на складе или цена которых не соответствует рыночной ситуации, может привести не только к прерыванию LTV клиента, но и к санкциям за это со стороны маркетплейсов. Поэтому сервис должен максимально быстро актуализировать данные на всех подключенных площадках.
Сервис должен:
- Уметь подключаться к потокам данных мастер-систем по ценам и стокам. В том числе в API должны быть реализованы методы, по которым мастер-системы принудительно передают новые данные.
- Максимально быстро отправлять изменившиеся данные на все подключенные площадки.
- Отслеживать ситуации, когда цены меняются слишком сильно, чтобы предупреждать ошибочные продажи. Настраивать дельту, при достижении которых отправляется предупреждение (меньшая дельта) или блокируются продажи (большая дельта).
- Отображать актуальные цены, по которым продаются товары на каждой площадке.
- Отображать актуальные остатки и резервы по всем складам.
- Логировать изменение цен, остатков и резервов по всем маркетплейсам и складам.
Работа с заказами
Заказы на маркетплейсах требуют разного подхода в зависимости от схемы продаж: FBO, FBS или DBS. Когда продавец собирает заказы самостоятельно, ему нужно их отслеживать и обрабатывать, и многие ритейлеры делают это в собственных специализированных системах — OMS. Задача сервиса — агрегрегировать заказы со всех маркетплейсов, унифицировать их и передать в мастер-системы.
Названия схем продаж товаров на основных маркетплейсах
Сервис должен:
- Обеспечить маппинг и унификацию статусов заказов между разными МП и собственными системами продавца.
- Получать новые заказы со всех МП и пробрасывать их в мастер-системы.
- Обеспечивать транзит статусов заказов между МП и OMS продавца.
- Отображать перечень заказов со всех площадок и историю изменения статусов по ним.
Тарифы и сроки доставки для схем DBS
Управление пользователями
Концепция сервиса подразумевает, что мастер-данные и инструменты их создания/преобразования находятся во внешних системах ритейлера или ЛК маркетплейсов. Поэтому сервису не требуется сложная ролевая модель. Достаточно:
- администратора, обладающего всеми правами и доступом к настройкам,
- менеджера, который может настраивать маппинги и просматривать данные,
- читателя, который не может ничего менять, а только просматривать.
Отдельно стоит отметить способность интегрироваться с ролевыми сервисами ретейлеров
Почему до сих пор нет enterprise-решения для торговли на маркетплейсах
- Создать такое решение сложно, так как главные площадки слишком сильно отличаются друг от друга и каждая из них еще и активно развивается и часто меняет API и процессы.
- Маркетплейсы нацелены на работу c относительно небольшими продавцами, которые должны пользоваться их экосистемами, поэтому развиваются в первую очередь личные кабинеты площадок.
- Вокруг маркетплейсов развивается рынок продуктов и сервисных компаний, но они так же нацелены на продавцов, для которых маркетплейсы — основной канал.
- Крупные ритейлеры, которые часто сами являются IT-компаниями, занимаются собственными задачами и не думают о создании универсального enterprise-решения для быстрой интеграции с ведущими маркетплейсами.
Чтобы осилить разработку такого решения, нужно иметь достаточно ресурсов, опыта в отрасли и понимание того, как устроены большие ритейлеры. Команда платформы Ensi работает над Ensi Cloud Feed — первым enterprise-решением, которое позволит быстро интегрировать мастер-системы с главными маркетплейсами.
Действительно ли нужен такой инструмент? В выводах приведены тезисы “Маркетплейсы ориентированны на более мелких селлеров” и “Ритейлу хватает других задач” — кажется, будто проблема и не такая серьёзная, раз никто её не решает
Все решают тихо и самостоятельно, как и вообще любую автоматизацию. Очередная сложная задача, которое решает IT в крупном ритейле. И какая-то заготовка, которая упростить решение этой задачи, определенно нужно. Тут же еще вопрос поддерживания актуальности, ведь МП постоянно что-то меняют
Я считаю, что важно, чтобы такие решения были максимально гибкими и легко настраиваемыми под потребности каждого конкретного продавца
Чем гибче, тем сложнее управлять. Поэтому нужен баланс
Раз Российская система, то и цена космические за 100500 долларов. Российские разработчики думают так- раз работает бизнесмен на маркетплейсы, значит миллионер и цены должны быть высокими- не условно 5-6 тыс рублей в месяц, а чем выше тем лучше- 25-50
Тыс
О цене мы вроде не говорим. Если сервис сложный и требует интеграций в не менее сложный IT-ландшафт, тогда работы требуется немало, а значит и цена не может быть копеечной.
Да и разницу в ценообразовании между российскими и остальными сервисами не замечал. Точнее замечал, но, скорее не в пользу зарубежных.