В 2 раза больше заказов для интернет-магазина детских товаров после интеграции с маркетплейсами

Заказчик

«Олант» — сеть магазинов для будущих мам и малышей.

Задача

Автоматизация процесса взаимодействия интернет-магазина с маркетплейсами.

Магазин для будущих мам и малышей «Олант» обратился с запросом — автоматизировать процесс взаимодействия интернет-магазина с маркетплейсами.

До этого маркетолог вручную подключал, настраивал и выгружал товары на площадки:

• Добавлял единицы товаров в excel-файл и загружал его через личный кабинет маркетплейса.
• Вносил в таблицу данные о товаре. Один товар — 10 минут, а на каждом маркетплейсе размещается по 3000+ товаров.
• Вручную актуализировал цены и информацию об остатке товара.
• Вручную отслеживал поступающие заказы, переносил их в 1С и менял статус.

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

Этапы интеграции

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

1. Написание ТЗ

Написали техническое задание и сделали декомпозицию объемных задач для оценки сроков.

Синхронизацию каталога разбили на подзадачи:

• описание методов API;
• функционал экспорта товарных позиций;
• функционал синхронизации данных у товаров;
• синхронизации цен и остатков.

2. Разработка

На этапе разработки мы описали методы взаимодействия с API, а также написали функционал взаимодействия между системами.

Рассмотрим на примере маркетплейса Ozon, какие работы были проведены на данном этапе:

1. Написали функционал для работы с API маркетплейса;
2. Создали классы для выборки и обработки данных из интернет-магазина для последующей отправки в маркет;
3. Создали API-сервисы для обработки запросов на новые заказы от маркета и предоставления данных ERP-системе;
4. Внедрили функционал логирования и информирования о критичных ошибка при обменах. Если произойдет сбой, мы будем знать где произошел сбой, при каких данных и быстро отреагируем;
5. Создали отчеты для сверки данных по товарным позициям в маркетплейсе и интернет магазине. Отчет представлен в 2-х вариантах: в виде отчет-таблицы для менеджеров и сверки данных в автоматическом режиме каждые 2 часа.

3. Тестирование и отладка процесса

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

В результате тестирования на основе данных логов и обратной связи от клиента у нас получился следующий список для доработок:

• некорректная передача данных при отрицательных остатках;
• API OZON не отдавала результат при печати маркировки с первого раза;
• некорректное SKU товара (1С может менять артикул на своей стороне);
• ошибка от API — too many requests, которая возникла с увеличением размера каталога;
• некорректная отработка загрузки изображений.

4. Развитие интеграционного решения

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

1. Поменяли время вызовов узлов системы и доработали функции для удобства взаимодействия с ERP-системами.
2. Реализовали новые фичи: печать маркировки, работа с премиум-ценами, web-сервис получения трек-номера DPD ERP-системой. С увеличением размера каталога перенастроили запуск скриптов обмена.
3. Внедрили очереди выполнения и оптимизировали нагрузку, изменив фильтры выборки по дате изменения данных товара, а также разделив выгрузку на регулярную (на основе изменения товара в каталоге) и общую. Часть статичных данных перенесли на хранение в кэш. К такому решению пришли потому, что при увеличении количества товарных позиций в каталоге возникли проблемы со временем выполнения скриптов и превышением максимального количества запросов.

Технические нюансы интеграции с маркетплейсами

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

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

Результат

• Мы минимизировали ручной труд с помощью бесперебойного экспорта товара. Теперь достаточно пометить нужные товары в 1С, и они автоматически загрузятся на маркетплейс за 3–5 минут. Взаимодействие с 2 системати одновременно больше не требуется. 
• За первые полгода после интеграции на маркетплейсах сделали более 40 000 заказов — это в 2 раза больше, чем до интеграции. При этом «Олант» не использует все маркетинговые возможности площадок — такой результат достигается только за счет размещения товаров и автоматизации процесса. 
• Работа, которую один сотрудник выполнял бы в течении 2,5 месяцев (для одного маркетплейса), занимает 5 минут в автоматическом режиме.
• Выросла скорость обновления данных: информация по остаткам и ценам каталога автоматически актуализируется каждые 8—10 минут. Процесс актуализации занимает 5 минут. Для сравнения — в ручном режиме на эти действия уходило 30–40 минут на один маркетплейс. То есть мы в 40 раз увеличили скорость обновление данных, освободив для маркетолога 3,5 часа рабочего времени ежедневно.
• Заказы синхронизируются между маркетплейсом, 1С-Битрикс и ERP-системой. Это позволяет сократить влияние человеческого фактора и минимизировать время реакции на заказ с 30 до 5–10 минут.

Итак, у нас получилась следующая схема интеграции с маркетплейсами:

Отзыв клиента

Анатолий Тесля, основатель и директор по развитию сети «Олант»

Благодаря автоматизации в мае наш показатель отказов составил 1,7%, почти 100% заказов собираются в срок. Текущий показатель просрочки по сборке — 0,26%.

Перейти на сайт