Автор: Николай Казимиров, руководитель отдела контента, Департамент Софтлайн.ру
В эпоху «больших данных» и огромных контентных потоков, остро встает проблема управления электронными каталогами — структурированными массивами данных, содержащих подробную информацию о номенклатуре, представленной в различных интернет-магазинах.
Речь идет не о магазинах с парой сотен или даже тысяч единиц номенклатуры, а о площадках, способных аккумулировать десятки и сотни тысяч, если не миллионы, номенклатурных позиций, а также предоставлять их внешним сайтам в некотором унифицированном формате. В том числе, появляются идеи создания подобных каталогов на государственном уровне.
Ясно, что как при аккумулировании внешних данных, так и при универсальном предоставлении сгенерированных данных внешним потребителям требуется система, способная в автоматическим режиме управлять некоторым единым каталогом номенклатурных позиций.
Что она должна уметь?
Такая система управления каталогом продуктов должна:
- (matching) корректно сопоставлять номенклатурные позиции прайс-листов разных поставщиков, отождествляя одинаковые позиции и не спутывая заведомо разные;
- (pricing) генерировать итоговую цену для клиентского интернет-магазина (ИМ) на основании прайсов поставщиков и правил ценообразования данного ИМ;
- (currency) учитывать особенности налогообложения и формирования валютных курсов страны данного ИМ;
- (discount) предоставлять маркетологам гибкий инструмент управления скидками;
- (classify) структурировать каталог продуктов универсальным способом, независимо от их каталогизации в прайс-листах поставщиков;
- (export) предоставлять единообразные наименования продуктов и перечни их физических и технических характеристик в универсальном формате;
- (autoname) предоставлять возможности по автоматическому формированию настроек для SEO-оптимизации;
- (multilang) предоставлять контент на нескольких языках, сохраняя универсальную структуру данных и алгоритмы их агрегирования;
- (API) предоставлять API клиентскому ИМ, позволяющий забирать данные, предназначенные данному ИМ, в полном объеме на нужном ему языке.
Разработчики
Такие сложные многозадачные системы агрегации цен и формирования контента создаются и поддерживаются несколькими крупными компаниями, такими как it4profit, Riversand, Amazon, Yandex.Market, icecat и т.п. Все они являются уникальными внутренними разработками этих компаний и не присутствуют на рынке в виде простого коробочного решения, подобного Magento или OpenCart. Они либо предоставляются в пользование на ресурсах самого разработчика (it4profit.com, icecat.biz), либо устанавливаются на ресурсах заказчика с постоянной поддержкой силами создателей (Riversand), либо эксплуатируются исключительно для собственных нужд разработчика (Amazon).
При этом в каждой из этих систем решаются некоторые, но не все из перечисленных задач. Например, Riversand и it4profit не предоставляют систему матчинга прайс-листов, icecat не имеет ни модуля матчинга, ни модуля ценообразования, являясь чисто контентной системой.
Рассмотрим функционал системы, которая могла бы решать поставленные выше задачи. Требуемую систему можно условно разделить на следующие процессинговые блоки:
1. Матчинг прайс-листов;
2. Ценообразование;
3. Управление каталогом;
4. Мультиязыковая поддержка.
Матчинг прайс-листов
Представляет собой подсистему, которая на входе получает прайс-листы поставщиков товаров (номенклатурные позиции с ценами) и сопоставляет их с продуктовыми позициями каталога товаров. На каждый продукт каталога может приходиться несколько прайсовых позиций от разных поставщиков (но не наоборот).
Очень важно понимать, что позиции прайс-листов и продукты каталога товаров – это разные сущности базы данных. Задача процесса матчинга (сопоставления) – создать правильные привязки между прайсовыми позициями и продуктами каталога. Результатом этого процесса является возможность сравнивать прайсовые позиции различных поставщиков, соответствующие одному и тому же товару.
Например, поставщик A продает товар T под кодовым названием AT1, а поставщик B продает тот же самый товар под кодовым названием BT2. Подсистема матчинга должна создать привязки вида AT1→ T и BT2→ T. При этом, если поставщик C продает другой, но похожий на T товар под кодовым названием CT3, то система матчинга не должна создать привязку CT3→ T.
Таким образом, матчинг прайс-листов и продуктов каталога нельзя назвать системой с нечеткой логикой, каковыми обычно бывают обучаемые системы с искусственным интеллектом. Для матчинга лучше что-то не сопоставить, чем сопоставить лишнее.
Поэтому работа подсистемы матчинга определяется некоторым набором детерминированных правил матчинга, которые могут быть как универсальными (т.е. применяться ко всем прайсам), так и специальными (т.е. использоваться для матчинга позиций какого-то одного поставщика или производителя).
Например, правилом матчинга может быть указание сравнивать PartNumber товаров из прайс-листов, и в случае их полного совпадения считать такие товары тождественными. Более сложные правила предполагают работу с текстовыми полями прайс-листов, например, с названием номенклатурной позиции. Эти правила могут использовать регулярные выражения (regexp) для преобразования сравниваемых текстовых полей.
Правила матчинга задаются либо для всего ИМ в целом, либо для конкретного поставщика или производителя. Система последовательно обрабатывает заданные правила до тех пор, пока не получит либо тождество позиций, либо отрицательный результат, отвергающий возможность автоматического сопоставления позиций прайс-листов с продуктами каталога.
Искусство настроек правил матчинга определяет эффективность этого механизма и существенно влияет на дальнейший процесс формирования цен.
После того как произведен матчинг, и мы весьма уверены в том, что все нужные привязки произведены корректно, для каждого продукта каталога имеется набор цен – столько, сколько поставщиков продают данный товар. Этот набор может быть пустой, может состоять из одной цены, а может из нескольких.
Ценообразование
С этим набором цен начинает работать механизм ценообразования. Главной задачей данного механизма является определение итоговой цены товара на основе набора цен поставщиков. Итоговая цена отправляется на сайт клиентского ИМ в качестве цены продукта каталога.
Ценообразование – это чисто арифметическая процедура, состоящая из правил ценообразования. Подобно правилам матчинга, правила ценообразования могут быть универсальными и специальными – все зависит от того, какие финансовые цели ставит ИМ по продажам товаров своего каталога и какие существуют договоренности по ценовой политике с поставщиками и производителями товаров.
Например, правилом ценообразования может быть такое: выбрать минимальную из цен поставщиков и добавить к ней 5%. Более сложный вариант: рассчитать средневзвешенную по складским остаткам цену поставщиков и прибавить к ней 5%.
Заметим, что цены поставщиков могут быть заданы в разной валюте, поэтому механизм ценообразования предполагает конвертацию цен в валюту сайта ИМ, а также демпфирование валютных рисков в виде небольшой дополнительной наценки.
Кроме того, поставщики могут предоставлять несколько видов цен: розничную, оптовую, рекомендованную и т.п. Правила ценообразования должны (так же, как и правила матчинга) уметь работать с разными ценовыми полями. При расчете итоговой цены система пытается последовательно применять правила из стека заданных правил, пока не дойдет до правила, работающего с теми ценовыми полями, которые использует данный конкретный поставщик.
Дополнительными инструментами ценообразования являются различные маркетинговые правила: применение временных скидок, распродаж, купонов, оптовых и партнерских цен. Чаще всего маркетинговые правила нацелены на то, чтобы на сайте ИМ показывать две цены товара – зачеркнутую и реальную (99 руб./100 руб.). При этом зачеркнутая цена рассчитывается с помощью основных правил ценообразования, а реальная – с помощью дополнительных.
Процессы матчинга и ценообразования являются низкоуровневыми в том смысле, что всегда работают непосредственно с номенклатурой – позициями прайс-листов и продуктами каталога, т.е. с теми сущностями, которые клиент покупает на сайте ИМ и затем видит в сопроводительных документах.
Управление каталогом
Параллельно с этими двумя процессам существует процесс управления каталогом. Две его главные задачи:
1. Формирование структуры каталога товаров;
2. Формирование полных и достоверных описаний товаров, включая специальный поисковый контент.
Организация всей совокупности товаров на сайте ИМ в единый структурированный каталог служит, прежде всего, удобству поиска товара. Одновременно это решает задачу объединения различных классификаций поставщиков в одну. Действительно, разные поставщики могут по-разному структурировать свои каталоги в прайс-листах: например, одни могут выделять в разные категории смартфоны и фаблеты, другие – нет; одни могут отделять серверные комплектующие от десктоповых и ноутбучных, другие не уделяют этому должного внимания. Уход с помощью матчинга от исходных прайс-листов к универсальному каталогу позволяет структурировать товары независимо от предпочтений поставщиков.
Кроме того, распределение товаров по продуктовым типам позволяет организовывать поиск по типу товара, создавать удобное навигационное меню, сравнивать и сортировать товары одного типа.
Более глубокая структура каталога, например, выделение продуктовых линеек или моделей товаров на сайтах используется редко, однако она крайне необходима при работе над формированием основного контента товарных карточек – графических, текстовых и технических описаний продуктов.
Представим себе, что нам требуется описать 10 одинаковых игрушек, которые отличаются лишь цветом. В случае плоского каталога затраты на описание 10 игрушек почти в 10 раз больше, чем затраты на описание 1 игрушки. Но в правильно построенном каталоге мы создаем одну абстрактную сущность (модель), описываем ее как товар, лишенный единственного признака – цвета, затем привязываем к этой модели 10 наших игрушек разного цвета, и в каждой из них указываем нужный цвет, а все остальное описание наследуется от модели. В этом случае затраты на описание 10 игрушек лишь немного превышают затраты на описание одной.
Механизмы формирования контента
Механизм наследования описательных признаков вдоль дерева каталога является мощным инструментом формирования и модификации контента товарных карточек. Например, если мы группируем товары в модели, модели в линейки, а линейки в категории, то у нас появляется возможность диверсифицировать процесс формирования контента, указывая описательные признаки на том уровне абстракции, где они применимы. Такая организация контента решает следующие задачи:
1. ускорение формирования контента (не нужно каждый товар описывать «с нуля»);
2. единообразие контента (никакую контентную единицу мы стараемся не указывать дважды, а значит, одно и то же свойство, присущее различным продуктам, будет описано одинаково для этих товаров);
3. упрощение модификации устаревшего или ошибочного контента (те описательные признаки, которые были внесены на абстрактных уровнях каталога, там же и исправляются, например, размер диагонали ноутбуков, сгруппированных в одну общую линейку <<ноутбуки 15”>>);
4. определение единых уникальных правил формирования контента сразу для больших групп товаров.
Другим полезным механизмом формирования контента является система экспортных скриптов. По сути, это ряд правил, заданных для конкретной группы товаров (категории, линейки), преобразующих содержащийся в каталоге контент в некоторый презентабельный вид для его размещения на клиентском сайте ИМ.
Дело в том, что структурирование контента под механизм наследования заставляет нас сильно декомпозировать описание товара, разбивая его на большое число контентных единиц, как то: единицы измерения физических величин, списки различных опций, функций, возможностей в характеристиках товаров и т.д.
В результате описание товара представляет собой пирамиду, сложенную из сотен кирпичей, находящихся на разных уровнях дерева каталога.
Чтобы это описание сделать более гладким и целостным, а также ввести в нем некоторую дополнительную разметку (например, выделить существенные признаки товара, чтобы предоставить пользователю сайта инструмент фильтрации списка товаров по этим признакам, а также задать метатеги), требуется все эти кирпичи склеить в определенном порядке по определенным правилам. Для этой цели API каталога использует специальные скрипты экспорта данных, которые могут быть «заточены» под конкретный ИМ.
В частности, экспортные скрипты могут по определенным правилам складывать наименование продукта из названий его родительских узлов в системе каталога, а также из некоторых характеристик. Так, при формировании названия «Смартфон Apple iPhone X 128GB» мы можем слово «Смартфон» взять из названия категории товара, слово Apple – из названия производителя, iPhone X – из названия линейки, а характерный признак 128GB взять из числовой характеристики данного товара, отвечающей за объем памяти смартфона.
Аналогично можно сформировать такие метатеги, как <keywords> и <description> для карточки товара. Причем, в любой момент можно легко переделать правила формирования имен, просто отредактировав нужный скрипт экспорта вместо того, чтобы править тысячи независимых товарных карточек.
Наконец, еще одним процессом формирования контента является механизм локализации контента, т.е. перевода его на другие языки. Этот процесс стоит в стороне от управления каталогом и ценами, но принимает непосредственное участие в экспорте данных на сайт ИМ.
Задачей механизма локализации является обеспечение перевода всех контентных единиц каталога (тех самых кирпичей, из которых складывается карточка товара) на языки, отличные от основного языка системы. Сопряжение скриптов экспорта, заточенных под конкретный язык ИМ, с контекстно-независимыми переводами контентных сущностей, позволяет достаточно гибко и дружелюбно по отношению к пользователям сайта формировать мультиязычный контент. Заметим, что это более трудоемкий процесс, чем использование внешних систем перевода, как это делает Aliexpress, но при этом несоизмеримо более качественный.
При локализации нам снова сильно помогает декомпозиция контента на многочисленные контентные единицы, которые задаются единожды и используются многократно системой наследования данных вдоль дерева каталога. Это позволяет создать набор словарей для организации и хранения переводов однотипных сущностей, участвующих в строительстве карточки товара на нужном языке.
Преимущества системы управления контентом и ценами
Итак, мы рассмотрели общую структуру системы управления контентом и ценами, в основе которой лежит глубокая структуризация данных, единые правила управления контентом и ценами, универсальный механизм предоставления контента клиентским интернет-магазинам.
Такая система может использоваться для организации однотипных интернет-магазинов с узнаваемым брендбуком компании сразу в нескольких странах и с использованием поставщиков, работающих в этих странах.
Описанная здесь система, с одной стороны, является сложной информационно-аналитической средой по управлению ценами и контентом сайтов, с другой стороны, это масштабируемая мультиязычная централизованная система, управление которой сводится к настройке правил матчинга, правил ценообразования, правил экспорта данных, таблиц перевода, структуры каталога и созданию многочисленных контентных единиц, а также к работе квалифицированных контент-менеджеров, умеющих грамотно расставлять заданные контентные единицы по уровням каталога с целью получить качественный итоговый контент продуктовой карточки.
В заключение добавим, что такая система успешно реализована и эксплуатируется для сайта store.softline.ru и зарубежных интернет-магазинов Softline.
