Как мы в разы ускорили создание карточек товаров на Ozon

Краткий ответ: сначала сделали систему автоматического создания карточек товаров, распарсили 50 миллионов товаров и 600 миллионов характеристик, сохранили 120 миллионов фотографий. Потом интегрировали её с API Ozon. Потом с её помощью сделали всё остальное.

А если серьезно, то мы делаем сервис catalog.app, который автоматизирует этот процесс, и в этой статье я расскажу, как он работает, с какими трудностями мы столкнулись в процессе его создания, и как их решали.

У наших клиентов возникла потребность работать с маркетплейсами. По ходу выяснилось, что создать аккаунт, и вручную там создавать карточки товаров и обновлять цены — медленно и неэффективно. К тому же, если это нужно сделать в трех-четырех личных кабинетах. Про решение для Яндекс Маркета я уже писал в прошлой статье. Сегодня разберем, как мы решали эту проблему с Озоном.

Идеально, если карточки товара будут создаваться автоматически, и цены будут формироваться с учетом цен конкурентов и обновляться автоматически. Все, что требуется от продавца в таком случае настроить загрузку актуальных файлов поставщиков. Забегая вперед, идеально пока не получилось, процесс нужно контролировать. Но значительно ускорить — получилось.

Автоматическое обновление цен мы сделали быстро, а с карточками товаров пришлось повозиться.

Сначала давайте посмотрим, как обстоят дела при создании карточки вручную в личном кабинете Озона. Для примера я взял первый попавшийся товар, им оказалась масштабная модель Bburago Феррари FXX K.

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

2. Создаем новый товар, заполняем информацию о товаре. Обратите внимание, нельзя пропустить на этой странице какое-либо из обязательных полей. То есть, создать черновую версию, и потом вернуться к ней не получится.

3. Теперь переходим к заполнению характеристик. На скриншоте представлена примерно треть из них, среди характеристик есть обязательные. Как и на прошлом экране, пропустить что-либо из обязательных полей не получится.

Кстати, на этом этапе есть весьма интересные варианты

4. Заполняем изображения и видео.

5. Сохраняем и получаем сообщение, что Rich-контент JSON на третьем шаге заполнен некорректно. Возвращаемся, переносим описание в поле Аннотация. Сохраняем еще раз, готово.

Озон не создает эталонные карточки товаров и не объединяет предложения разных продавцов на одной карточке товара. Что же, хоть мне как покупателю удобнее иметь информацию обо всех продавцах на одной странице, принцип понятен. В рамках концепции «продавец сам создает карточки товаров вручную» придраться можно только к невозможности создать черновик товара. Небольшие баги с валидацией или нерелевантными вариантами — ну у кого нет багов, один раз наткнулись, запомнили, и дальше они не мешают работать.

Давайте подумаем, что можно оптимизировать в этом процессе.

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

Во-вторых, бывают уникальные товары. Ну как уникальные, по крайней мере надписи отличаются. Хотя, бывают и реально уникальные товары, ручная работа, например. В этом случае хотелось бы создать карточку товара один раз, и использовать её и на своем сайте, и на маркетплейсах, и, скажем, в CRM.

В третьих, управлять ценами на всех площадках хотелось бы массово и централизованно.

Пока наш план (ага, план) выглядит не очень конкретно. Давайте все-таки попробуем приблизиться к реальности.

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

На самом деле, название, которое я ввел, не совпало до буквы с существующими названиями, но такая модель на Озоне уже была. В общем, наш алгоритм должен уметь сопоставлять такие товары, но при этом и не очень много ошибаться (скажем, 10 ошибок на тысячу сопоставлений — ну так себе, 5 — приемлемо, 2 — хорошо). Этот алгоритм, если он у нас будет, можно задействовать и для других целей.

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

В третьих, нужны исходные данные. Чем больше, тем лучше.

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

И в пятых, нужны интеграции. В рамках этой темы — с Озоном, но по сути, чем больше — тем лучше.

И мы сделали все пять пунктов. Точнее, у нас уже были готовы четыре первых составляющих из списка выше. Я уже публиковал относительно подробную статью об этом. А техническое устройство сервиса разбиралось на хабре, там получился целый цикл статей: раз, два, три, четыре. Исходных данных у нас уже почти 50 миллионов товаров, 120 миллионов изображений и почти 600 миллионов характеристик.

Теперь поговорим, как это все можно использовать конкретно в случае работы с Озоном. Вообще, работа строится таким образом:

1. Копируем дерево категорий Озона к себе, вместе со свойствами. Тут терминалогия еще не устоялась, по сути, подразумевается модель свойств, например, что у категории «машинки и масштабные модели” есть свойство “пол ребенка», оно содержит три варианта для выбора и обязательно к заполнению.

2. Копируем к себе все товары, которые уже есть в личном кабинете. Вместе с значениями свойств и изображениями.

3. Пользователь загружает файл со своими товарами и их ценами. Алгоритм сопоставляет товары, если товар есть в каталоге — обновляет на него цену. Если товара нет в каталоге, создает товар в нужной категории (алгоритм должен автоматически выбрать из дерева категорий нужную)

4. Всем товарам из каталога ищем соответствия среди наших 50 миллионов товаров.

5. После того, как соответствия найдены, заполняем характеристики в соответствии с моделью Озона для категории товара.

6. Отправляем созданные карточки товаров на Озон.

Человеку остается контролировать процесс и дополнять те карточки, в которых автоматически не получилось заполнить все обязательные поля. Иногда — дополнять карточку товара уникальными фотографиями и описанием.

Давайте посмотрим на результат автоматической работы. Возьмем для примера тот же товар.

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

Кроме того, автоматически мы смогли заполнить 5 свойств.

Мы даже нашли габариты упаковки, но автоматически разобрать их на длину, высоту и ширину у нас пока не получилось. Показали подсказку менеджеру.

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

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

Теперь про трудности.

Во-первых, алгоритм, который сопоставляет товары и мало ошибается — это непросто. А если учесть задачу сопоставить 50 миллионов товаров за приемлемое время, то вдвойне непросто. Подробно про него написано на хабре, там много текста. Сейчас сопоставление такого количества выполняется чуть быстрее двух часов.

То же самое можно сказать и про алгоритм обработки свойств и изображений (про него тоже есть).

И про авоматическое определение категории товара.

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

Предположим, мы прорабатываем категорию товаров «стиральные машины”, описываем, какие свойства должны быть в этой категории, какого типа, какие варианты есть на выбор. Вот есть свойство «потребляемая мощность», тип — дробное число, единица измерения — ватты. Свойство «тип» — взаимоисключающий выбор из трех вариантов: «встраиваемая”, “отдельно стоящая» и “настенная». А сколько вариантов вообще может быть? Ну, у большинства свойств будет до 20 вариантов. У некоторых будет 50. Редко где будет больше. Ну тысяча максимум, если больше — лучше указать, что это просто строка.

И на максимум тысячу мы рассчитываем наш интерфейс и всю логику, пишем запросы, которые не тормозят на таких данных.

А потом начинаем интеграцию с Озоном и понимаем, что в перечислении бывает 350 тысяч вариантов. И что нам придется переписать весь интерфейс работы со свойствами и значительную часть логики.

Это только один пример, на самом деле были и другие сложности.

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

Про то, сколько клиентам удалось заработать (или сэкономить) благодаря этому функционалу, я пока не могу сказать, мы только-только запустили это дело на продакшене. Вероятно, напишу об этом отдельно, когда накопится достаточно материала для следующей статьи.