Практический гид по Ozon: опыт системного аналитика
Привет, это Интаро.
Системный аналитик Григорий рассказывает об интеграции с маркетплейсами на примере Ozon — вторым по популярности маркетплейсом в РФ.
В предыдущей статье мы говорили про опыт интеграции с Яндекс.Маркетом (если еще не читали — ознакомиться можно здесь). В этом материале используем референсы и сравнения двух площадок.
Все маркетплейсы мы рассматриваем на примере интеграции с RetailCRM. Но информация будет актуальна и в том случае, если вы используете иную CRM-систему.
Процесс обработки заказа
Прежде чем говорить о настройке, посмотрим на базовый процесс обработки заказа по схеме FBS. Сам маркетплейс выделяет следующие пункты в его алгоритме:
Шаг 1. Ознакомьтесь с заказом Если вы совсем не планируете заниматься обработкой заказов в ЛК — первой «ознакамливаться» с заказом будет ваша система. Это удобно, но при условии, что система умеет проверять доступный остаток для заказа и актуальность цены товара. В ином случае, менеджеру придется перепроверять вручную.
Шаг 2. Подготовьте и упакуйте заказы Из нашего опыта, на данном этапе заказ уже уходит в обработку в специализированную складскую систему (например, 1С). Теоретически, вы можете осуществлять эти работы и в CRM, но зачастую 1С на проектах появляется гораздо раньше.
Шаг 3. Передайте информацию о грузовых местах и подготовьте ярлыки-наклейки Информацию о грузовых местах передаете по API из интегрированной с Ozon системы. Ярлыки-наклейки, они же этикетки — формируете самостоятельно, исходя из требований маркетплейса, печатаете и наклеиваете на упаковки.
Шаг 4. Подготовьте к отгрузке заказы и акты приема-передачи В API маркетплейса доступен метод получения актов приёма-передачи по номеру отгрузки. Запрос вернет вам акт в формате .pdf, где содержатся собранные и готовые к отправке заказы.
Шаг 5. Передайте информацию об отгрузке заказа Финальный шаг в обработке заказа на стороне бизнеса. После того, как вы отгрузите курьеру маркетплейса пакет упакованных и промаркированных заказов, действий более не требуется. Ozon самостоятельно передаст вам статус по успешно доставленному заказу. Лишний раз напомним о том, что со стороны вашей системы должна быть настроена матрица статусов. Например, в нашем случае, финальный статус в RetailCRM — «Выдан клиенту».
Такая логика актуальна абсолютно для всех МП, работающих по схеме FBS. Принципиальные различия будут в используемых методах (наборах данных внутри), а также подходах МП к тем кейсам, когда в обмене что-то пошло не так.
Настройки интеграции
Верхнеуровнево (и ооочень упрощенно), интеграционный контур в нашем случае можно представить в виде схемы:
Невозможно обойтись без нее, потому что:
- широкие возможности по автоматизации процесса обработки заказов: меньше общего ручного контроля со стороны менеджеров, все их внимание можно направить на крупные или проблемные заказы;
- дружелюбие интерфейса — одно из ключевых требований при разработке таких систем: ваши сотрудники смогут самостоятельно вносить изменения в настройки интеграции (но это не значит, что всем сотрудникам стоит это разрешать);
- возможность пополнения клиентской базы, даже с учётом того, что в базовой модели FBS маркетплейсы обычно отдают вам клиента в формате «КЛИЕНТ№XXX». Для расширенных моделей (например, когда вы используете доставку силами продавца) МП уже не имеют возможности скрывать от вас клиентские данные — тут-то их и можно привязать к уже существующим в БД CRM.
Тестирование
К сожалению, на данный момент, перед запуском работы с Ozon по API отсутствует возможность протестировать работу интеграции на тестовых заказах. Мы получили от тех.поддержки информацию, что тестовый контур находится в разработке.
Единственный путь, который доступен бизнесу: регистрация аккаунта покупателя и создание «боевого» заказа. После тестирования заказ отменяется со стороны клиента, но на время теста средства будут временно захолдированы на стороне маркетплейса.
Плюс этой системы (в сравнении с ЯМ, например) — возможность отработать на тестовом заказе реальную упаковку, маркировку и отгрузку заказа в пункт приёма, а также принятие «возврата» от клиента невыкупленного заказа.
Логирование: решения, делающие жизнь проще
Можешь логировать? Логируй Не стесняйтесь добавлять логирование на все критичные пункты, где ваша система (в нашем случае это модуль Ozon для RetailCRM) передает или принимает важные для бизнес-процесса данные. Как уже писали в статье по ЯМ — это здорово упрощает жизнь при разборе каких-то инцидентов. Особенно, если вы тот, кто сопровождает интеграционный контур с МП, так как заказчик, в первую очередь, придет с вопросами к вам.
Дайте доступ к истории событий тем, кто может у вас ее запросить Для модуля Ozon мы реализовали это как функционал отправки ошибок на email. Например, на скриншоте — ежедневный отчет по артикулам, для которых возникли проблемы по обновлению цены и ошибка, полученная от маркетплейса:
Не забудьте разделить потоки логов: публичные (доступные для бизнеса) и внутренние (доступные только для разработки/поддержки) Это важный «политический» момент в контексте совместной работы «интегратор-заказчик». Пакеты ошибок при тестировании новой фичи или же просто вагоны данных какого-то мониторинга событий внутри системы —это не та информация, которую нужно видеть бизнесу.
Давайте коллегам доступ только к тому, что будет полезно для их работы. Для ответственных за карточки товаров сотрудников — только ошибки по обновлению цен и остатков, например, как и для логистов — информацию по созданным заявкам на доставку (для кейсов с экспресс-доставкой курьерами МП).
Что может пойти не так?
Обновление цен Самая популярная ошибка по ценам, которую мы наблюдаем при работе с Ozon и ЯМ — это некорректный размер скидки. У разных маркетплейсов свои процентные лимиты на установку промо-цены, поэтому, если значения не подходят под требования, — цена может быть не обновлена (для Ozon — это отдельный артикул, а для ЯМ — весь пакет цен в запросе). Доступ к логу обновления для ответственных сотрудников — лучшее решение данной проблемы. Также, на начальных этапах внедрения интеграции с МП, обратите особое внимание на лимиты обновления по API. Если передадите слишком большой пакет артикулов — маркетплейс может не принять весь.
Обновление остатков Про возможные проблемы с обновлением остатка мы уже писали в статье по ЯМ. Вводные актуальны и для Ozon. Но в очередной раз акцентируем внимание на том, что если складов в ваших системах много и между ними возможны перемещения, то раз в сутки полезно делать полные выгрузки-синхронизации (в нашем случае это 1C-CRM).
Если товар удаляется из каталога на вашей стороне, то необходимо отправить остаток 0 шт. и в Ozon, иначе он будет числиться в количестве последней отправки остатка на маркетплейс, а при получении заказа в вашу систему неизбежны иные ошибки.
Крупногабаритные товары Кейс тривиален и лежит в зоне ответственности контент-менеджера. Каждый товар, если у вас не подключена торговля КБТ, должен укладываться в ограничения, установленные Ozon по длине, ширине, высоте и весу упаковки. Проверка происходит по тем данным, которые вы задаете в личном кабинете в карточке товара.
Крупногабаритные заказы (КБТ) Более интересный кейс, так как для работы в автоматическом режиме требует от вас реализации отдельной логики, которая будет делить товары по разным отправлениям Ozon.
Проверка габаритов была организована по следующему алгоритму:
- Посчитать общий вес товаров заказа:
если сумма больше 25 кг, а товаров в заказе больше 1 шт., то заказ требует разделения
- Посчитать общий объемный вес товаров:
если общий объемный вес товаров в заказе больше максимального объемного веса Ozon, то заказ требует разделения
- Определить максимальную длину из всех товаров и сравнить с длиной, шириной и высотой грузоместа Ozon:
если хотя бы в одном случае товар не попадает в габарит, то такой заказ будет невозможно отгрузить без подключения специального тарифа на крупногабарит.
Потерянные заказы Последний кейс в подборке, проблема-загадка. Год-два назад, стабильно раз в месяц, мы сталкивались с тем, что некоторые заказы Ozon просто не отдает по API. При этом, запрос на получение заказов за период был корректен, что подтверждала поддержка маркетплейса.
Единственное, что помогло частично решить проблему — добавить контрольные выгрузки раз в сутки всех заказов за последние 24 часа. Даже после этого некоторые заказы отсутствовали в выгрузках, что не давало возможности корректно их обработать (они падали в просроченные и повышали рейтинг отмен).
В 2023 году у нас была пара-тройка таких случаев. В 2024 — еще ни одного. Остается надеяться, что это был какой-то плавающий баг на стороне маркетплейса, который был исправлен в одном из обновлений.
Если бы пришлось охарактеризовать двумя словами интеграцию с Ozon, то мы бы назвали ее «почти беспроблемной». Учитывая то, что иная система работы рейтинга магазина и начисления штрафных баллов не блокирует ваш магазин сразу же, а дает отсрочку времени на решение вопроса.
В этих условиях уже не является минусом отсутствие оперативного контакта с поддержкой в чате Телеграм (что есть у ЯМ), так как поддержка в личном кабинете отвечает достаточно оперативно. И да, за последний год она стала сильно лучше в своем качестве работы.
Если вы ответственно подходите к интеграции, готовы вкладывать труд в ее поддержание и доработки — работа на маркетплейсе не вызовет у вас сложностей.
Интаро специализируется на разработке и поддержке сложных e-commerce проектов и B2B порталов. Мы реализуем высоконагруженные и отказоустойчивые системы, интегрируем сложные контуры и автоматизируем бизнес-процессы заказчика.