{"id":13465,"url":"\/distributions\/13465\/click?bit=1&hash=1e6228dc4e5e22730d5108e1c30ee96b3462205737e7a3fe7ce4c965aaacfe57","title":"\u041a\u043e\u043d\u0444\u0435\u0440\u0435\u043d\u0446\u0438\u044f Ozon \u2014 \u043a\u043e\u043c\u0443, \u0447\u0442\u043e \u0438 \u043a\u0430\u043a \u043f\u0440\u043e\u0434\u0430\u0432\u0430\u0442\u044c \u0432 \u043a\u0440\u0438\u0437\u0438\u0441","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"6b1e0c55-41d3-56c2-84e2-fe6f447e3825","isPaidAndBannersEnabled":false}
Торговля
Yury Loskat

Как мы в разы ускорили создание карточек товаров на 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 тысяч вариантов. И что нам придется переписать весь интерфейс работы со свойствами и значительную часть логики.

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

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

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

0
8 комментариев
Написать комментарий...
Nikolay Kenig

Что-то в этом есть. Понаблюдаем

Ответить
Развернуть ветку
Egik

"На этапе создания товара Озон показал нам такую плашку:"
эээ там пусто.
Это какой-то тонкий программистский юмор или выпавший скрин?

"Сопоставлению товаров по названию" - аплодирую стоя. Безумству храбрых поем мы песню.
Ну и соответственно если вы не можете выловить аналоги, то вся аналитика становиться ущербной.

Ответить
Развернуть ветку
Yury Loskat
Автор

Вернул плашку, это выпавший скрин.

А что касается сопоставления по названию, то это не работает на товарах типа "Свитер с оленями", но уже на нашем примере "масштабная модель Bburago Феррари FXX K" к сопоставлению вопросов не возникает.

Ответить
Развернуть ветку
Egik

Ну это техасский стрелок. Из 500 предложений машинок на просторах интернета вы нашли 20 - Ура наш алгоритм работает.
Я этой фигней занимаюсь уже более 15 лет. Торговая фирма 100+ Поставщиков, 250 000+ SKU. Так вот идентификация по наименованию у меня присутствует только как жест отчаяния - для совсем отмороженных поставщиков, которые до сих пор ручкой на бланке накладные заполняют или типа того.

Ответить
Развернуть ветку
Yury Loskat
Автор

У нас "сопоставление по названию" учитывает и EAN, цену, бренд, категорию, артикул, цвет и так далее, когда они есть. Когда их нет - приходится работать с тем, что есть. На хабре я подробно написал об этом алгоритме, ссылка https://habr.com/ru/post/456604/. Там же есть статистика по результатам, которые мы дотошно проверили вручную.

В части работы с поставщиками у двух из наших клиентов есть по 1 500 000 SKU и по 500+ поставщиков, естественно для каждого поставщика используется тот максимум информации, который можно получить.

С ценами конкурентов и просто товарами из интернета сложнее, EAN хорошо если в 1% случаев есть. Вот и учимся работать с тем, что есть и извлекать из этого пользу. И найти 20 из 500 и создать на их базе карточку в нужном формате автоматически - ну чем плохо? Контент-менеджеру (в этом примере мне) не пришлось гуглить, сохранять картинки, загружать картинки. Вручную нужно было указать 4 значения, 3 из которых были на этой же странице.

Ответить
Развернуть ветку
Alex Guide

Ну так и пишите - Сопоставление по названию и ХХ-параметрам, а то читаешь и мозг ломаешь - или ребята что то не оо делают и тут выпендриться решили или что то не договорили, или я что не понимаю...🤔

Ответить
Развернуть ветку
Yury Loskat
Автор

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

В примере шла речь про строку "масштабная модель Bburago Феррари FXX K" - да, тут есть категория и бренд, но по сути все вместе - это название товара, и понять что есть что в этой строке - это отдельная задача.

Ответить
Развернуть ветку
Egik

У нас "сопоставление по названию" учитывает и EAN, цену, бренд, категорию, артикул, цвет и так далее, когда они есть.
Ну это совсем другая песня. Это рабочая тема.
20 / 500 я приводил пример при конкурентном анализе. Цены там и все такое. Где важна наполненность выборки.
Для создания/заполнения карточки 20/500 даже избыточно, у троих параметры совпали - 99%, что, то что надо (если только они друг у друга ошибки не копируют :-))
Покурю хабр попозже для общего развития.
Меня смутил "поиск по наименованию" в тексте.

Ответить
Развернуть ветку
Читать все 8 комментариев
null