Практический гид по Яндекс.Маркету: опыт системного аналитика
Привет, на связи Интаро.
Наш системный аналитик Григорий рассказывает об экспертизе в работе с маркетплейсами: о разработке, настройке, доработке и поддержке интеграций с ними для наших клиентов.
Рассматривать все маркетплейсы (далее МП) будем в разрезе интеграции с RetailCRM. Информация будет актуальна и в том случае, если вы используете иную CRM-систему.
Статья будет понятна и полезна для всех: от владельцев бизнеса (по умолчанию не имеющих компетенций в узких вопросах интеграции) до разработчиков (которым иногда может поступить задача не только на разработку, но и настройку системы уже «по месту»).
Задачи по запуску новых маркетплейсов, проработке интеграций на начальном этапе и настройке на финальном, у нас традиционно падают на системных аналитиков. Эта практика показала себя достаточно хорошо, и если у вас есть выбор в подборе человека на эту задачу, то лучше выбрать какой-то сбалансированный юнит, обладающий hard и soft-скиллами (ниже расскажем, почему).
Сегодня мы тактично пропустим этап разработки модуля с нуля (у нас он разработанный с нуля и доступен в каталоге модулей для RetailCRM) и перейдем к процессу настройки нового магазина.
Важно! Мы говорим исключительно про модель FBS (fulfilment by seller) — схеме, при которой продавец хранит товары на своем складе, а для доставки передает их курьерам маркетплейсов. Иные модели работы (DBS, FBO) — отдельные истории, со своими пакетами нюансов, которых мы коснемся в другой раз.
Процесс обработки заказа
Прежде чем говорить о настройке, посмотрим на базовый процесс обработки заказа по схеме FBS. Сам маркетплейс выделяет следующие пункты в его алгоритме:
Шаг 1. Ознакомьтесь с заказом
Если вы совсем не планируете заниматься обработкой заказов в ЛК — первой «ознакамливаться» с заказом будет ваша система. Это удобно, но при условии, что система умеет проверять доступный остаток для заказа и актуальность цены товара. В ином случае, менеджеру придется перепроверять вручную.
Шаг 2. Подготовьте и упакуйте заказы
Из нашего опыта, на данном этапе заказ уже уходит в обработку в специализированную складскую систему (например, 1С). Теоретически, вы можете осуществлять эти работы и в CRM, но зачастую 1С на проектах появляется гораздо раньше.
Шаг 3. Передайте информацию о грузовых местах и подготовьте ярлыки-наклейки
Информацию о грузовых местах передаете по API из интегрированной с Яндекс.Маркет системы. Ярлыки-наклейки, они же этикетки — формируете самостоятельно, исходя из требований маркетплейса, печатаете и наклеиваете на упаковки.
Шаг 4. Подготовьте к отгрузке заказы и акты приема-передачи
В API маркетплейса доступен метод получения актов приёма-передачи по номеру отгрузки. Запрос вернет вам акт в формате .pdf, где содержатся собранные и готовые к отправке заказы.
Шаг 5. Передайте информацию об отгрузке заказа
Финальный шаг в обработке заказа на стороне бизнеса. После того, как вы отгрузите курьеру маркетплейса пакет упакованных и промаркированных заказов, действий более не требуется. Яндекс.Маркет самостоятельно передаст вам статус по успешно доставленному заказу. Лишний раз напомним о том, что со стороны вашей системы должна быть настроена матрица статусов. Например, в нашем случае, финальный статус в RetailCRM — «Выдан клиенту».
Такая логика актуальна абсолютно для всех маркетплейсов. Принципиальные различия будут в используемых методах (наборах данных внутри), а также в подходах маркетплейсов к тем кейсам, когда в обмене что-то пошло не так.
Настройки интеграции
Верхнеуровнево (и ооочень упрощенно), интеграционный контур в нашем случае можно представить в виде схемы:
Невозможно обойтись без неё, потому что:
- широкие возможности по автоматизации процесса обработки заказов: меньше общего ручного контроля со стороны менеджеров, всё их внимание можно направить на крупные или проблемные заказы;
- дружелюбие интерфейса — одно из ключевых требований при разработке таких систем: ваши сотрудники смогут самостоятельно вносить изменения в настройки интеграции (но это не значит, что всем сотрудникам стоит это разрешать);
- возможность пополнения клиентской базы, даже с учётом того, что в базовой модели FBS маркетплейсы обычно отдают вам клиента в формате «КЛИЕНТ№XXX». Для расширенных моделей (например, когда вы используете доставку силами продавца) МП уже не имеют возможности скрывать от вас клиентские данные — тут-то их и можно привязать к уже существующим в БД CRM.
Тестирование
Возможность провести полноценное тестирование без потери рейтинга перед запуском магазина — это, на наш взгляд, одна из самых крутых функций личного кабинета Яндекс.Маркет (в иных маркетплейсах такого функционала просто нет). Особенно в тех случаях, если вы используете самописный модуль (как и мы) или подключаетесь к новой модели работы.
Здесь вам доступны два режима: готовые тест-кейсы и конструктор заказа.
Важно, что прохождение первых (их 5-6, в зависимости от модели работы) является обязательным этапом для активации кабинета на боевые продажи. Количество попыток не ограничено, в отличие от времени на выполнение каждого задания (сейчас это 15 минут). Поэтому, важно обеспечить четкое взаимодействие всех систем во время теста. Например, в нашем случае — это совместная работа с 1С, откуда интегрированная с ЯМ система получает статусы по комплектации и грузовые места заказа.
Из встреченных проблем на этом этапе можно выделить только одну: иногда не создаются заказы на этапе прохождения тест-кейсов. Первое, что нужно проверить: наличие товаров с не нулевом остатком и заполненными ценами. Если они есть, но создание заказа всё равно зависает — остаётся только пробовать через какое-то время. Причину такого поведения нам не смогли сообщить даже коллеги со стороны маркетплейса.
К тестам вы можете вернуться в любой момент и после запуска кабинета, на случай необходимости проверки каких-то настроек или доработок интеграции.
Что может пойти не так?
- Обновления цен на маркетплейсе
На одном из наших проектов бизнес-процесс заказчика построен так, что цены могут меняться несколько раз в день. Одна из причин — колебание цен на стороне поставщиков. Менеджеры производят изменения на стороне 1С, далее мы получаем обновление в CRM. Соответственно, необходимо максимально оперативно передать новые цены на маркетплейс, иначе мы получим заказ по старой цене. Его либо придётся отменять, что повлияет на рейтинг магазина, либо принимать в убыток.
Цены, согласно документации ЯМ, мы передаём самостоятельно. Либо через xml-фид, либо по API. Если вы выбираете работу по API, то рационально организовать передачу пакетами (актуальные ограничения на количество цен в пакете смотри в документации ЯМ). Однако, если у вас хотя бы одна цена из выгрузки будет с ошибкой — есть риск потерять обновление всего пакета. Частая проблема — некорректная разница между обычной и промо-ценой. Чтобы отслеживать такие случаи и оперативно передавать их менеджерам, отвечающим за цены, мы реализовали отправку уведомлений в отдельный технический Telegram-канал:
Если говорить про наш опыт, то мы пошли по пути дублирования методов обновления, используя в работе как API-запросы, так и фид, генерируемый раз в 60 минут на стороне модуля CRM. Такой подход помогает обеспечить наиболее стабильный обмен даже с учётом возможных ошибок менеджеров по установке скидок.
- Обновления остатков на маркетплейсе
Поддержание актуальных стоков было нашей самой большой болью на тех проектах, где Яндекс.Маркет — не единственный канал продаж, а товар находится не только на основном складе, но и на складах дистрибьюторов. Маркетплейс снижает рейтинг кабинета, если отменять заказы: от уменьшения лимита заказов до полной блокировки. Раньше было невозможным самостоятельно передавать стоки на маркетплейс: Яндекс.Маркет запрашивал их у системы продавца самостоятельно, исходя из своих регламентов.
Сейчас есть возможность выбрать один из двух вариантов: самостоятельная передача остатков по API или сохранение этого процесса за маркетплейсом. Мы настоятельно рекомендуем вам первый вариант. Настройте несколько полных выгрузок за сутки и не забудьте про частичные обновления остатков, триггерами для которых будут служить любые изменения на стороне вашей системы. Такая схема позволяет практически до нуля снизить случаи неактуального стока в личном кабинете, соответственно, сохранив его рейтинг на должном уровне.
- Недоступность сервисов маркетплейса и прочие проблемы в сети
За всё время работы с действительно серьезными сетевыми проблемами, которые бы парализовали работу с МП, мы сталкивались только однажды: в феврале-марте 2022 года. Кто-то из причастных к вопросу сетевой безопасности читателей, вероятно, вспомнит — локальные проблемы в ru-сегменте интернета становились в тот момент глобальными. С маркетплейсом мы в какой-то момент банально потеряли связь: обмены по ценам и остаткам не проходили, заказы мы не получали.
К счастью, здесь отыграла одна из лучших вещей, которая есть в Яндекс.Маркет — команда поддержки, от саппортов в личном кабинете и персонального менеджера в telegram-канале до тех специалистов, с которыми вы напрямую никогда не контактируете. Коллеги со стороны МП крайне объективно и тщательно подходят к проблемам и помогают найти решение. Например, если причины ошибки лежат вне зоны ответственности продавца, то это не повлияет на рейтинг и продажи не будут ограничены.
В случае с упомянутыми сетевыми проблемами — вопрос был пережит без потерь репутации личного кабинета.
Отдельная заметка, если вы не продавец, а сторонний интегратор для бизнеса: в подобных случаях (сетевых проблем, например) бывает гораздо сложнее убедить в корректности работы системы не тех.персонал маркетплейса, а вашего непосредственного заказчика. Если он не обладает каким-то объемом компетенций по теме, то рекомендуем вам правильно подобрать слова и пустить в бой все ваши soft-скиллы. Внутренние проблемы во взаимодействии команд (технической и бизнес) гораздо более разрушительны в перспективе, чем самые сильные хакерские атаки.
Яндекс не был бы той компанией, что мы знаем, если бы не заботился о качестве своих продуктов. Маркет — не исключение. Для нас, как для интегратора, особенно приятно, что можно получить техническую поддержку сразу на двух уровнях: в личном кабинете маркетплейса и у персонального менеджера в Telegram. Конечно, нам хотелось бы пожаловаться на методы работы рейтинга (сначала вам его уронят и заблокируют кабинет, а уже потом восстановят — после разбора полётов), но такой подход способствует формированию позитивного пользовательского опыта и отсеивает недобросовестных продавцов.
Если вы ответственно подходите к интеграции, готовы вкладывать труд в её поддержание и доработки — работа на маркетплейсе не вызовет у вас сложностей.
Если у вас нет нужных навыков или вам просто лень, хотим напомнить, что для RetailCRM у нас уже есть разработанные модули интеграции: нашей разработки и второй. При наличии RetailCRM с настроенными процессами подключение к маркетплейсу займёт не боле двух недель.
Интаро специализируется на разработке и поддержке сложных e-commerce проектов и B2B порталов. Мы реализуем высоконагруженные и отказоустойчивые системы, интегрируем сложные контуры и автоматизируем бизнес-процессы заказчика.