Как составить базу поставщиков

Как зарабатывать на базе поставщиков?

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

p, blockquote 1,0,0,0,0 —>

Что такое база поставщиков и как на этом заработать?

p, blockquote 2,0,0,0,0 —>

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

p, blockquote 3,0,0,0,0 —>

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

p, blockquote 4,0,0,0,0 —>

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

p, blockquote 5,0,0,0,0 —>

Кто такие поставщики и как они помогут заработать?

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

p, blockquote 6,0,0,0,0 —>

Магазин обращается к поставщику и приобретает его товар по низкой цене, а затем выставляет его на своей площадке. Наценка, в таком случае, может составить 300-500% от конечной цены, за которую продукт был приобретен.

p, blockquote 7,0,1,0,0 —>

Так, например, обувь из магазина за 1000 рублей была приобретена за несколько сотен рублей.

p, blockquote 8,0,0,0,0 —>

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

p, blockquote 9,0,0,0,0 —>

Заводы и фабрики, либо производители, всегда ищут себе дистрибьюторов. Так называют людей или компаний, которые реализуют работу с магазинами и торговцами. Они договариваются о цене и берут весь процесс реализации на себя. То есть, это своеобразная пищевая цепь, реализованная в торговле. Производитель создает продукт, дистрибьютор договаривается о его реализации, а магазин продает. Каждый участник цепи берет небольшой процент.

p, blockquote 10,0,0,0,0 —>

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

p, blockquote 11,0,0,0,0 —>

Как заработать на базе поставщиков физ лицу?

p, blockquote 12,0,0,0,0 —>

Физическое лицо — обычный человек, который не имеет собственной компании и огромного капитала. Так какой смысл тогда производителю работать с ним?

p, blockquote 13,0,0,0,0 —>

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

p, blockquote 14,1,0,0,0 —>

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

p, blockquote 15,0,0,0,0 —>

Способы заработка на базе поставщиков

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

p, blockquote 16,0,0,0,0 —>

Перепродажа

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

p, blockquote 17,0,0,0,0 —>

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

p, blockquote 18,0,0,0,0 —>

Если распространять информацию об ее продаже в социальных сетях, на досках объявлений и тематических форумах, то удастся продавать ее 10-20 раз в сутки без особых проблем.

p, blockquote 19,0,0,0,0 —>

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

p, blockquote 20,0,0,0,0 —>

Самостоятельное использование

p, blockquote 21,0,0,1,0 —>

Еще один простой способ того, как использовать базу поставщиков в своих целях. Человек может экономить на определенных товарах, покупая их прямо у поставщика. В таком случае ему не нужен посредник в лице магазина или продавца. Разница в ценниках может доходить до двух, а иногда и трех раз. Так, например, литр напитка Coca-Cola, при розничной цене в 80 рублей, удастся купить примерно за 35-45 рублей. Экономия видна невооруженным взглядом.

p, blockquote 22,0,0,0,0 —>

Правда нужно уточнить, что некоторые поставщики предлагают не слишком выгодные условия для доставки товара. Например, человек заказывает сахар, объемом в 10 килограмм за 200 рублей, но стоимость доставки может превысить этот показатель. Что же делать в таком случае? Например, стоит поинтересоваться о возможности самостоятельно вывоза товара. Есть еще вариант по покупке сразу множества товаров, чтобы доставка в несколько сотен рублей не выглядела чересчур дорогой!

p, blockquote 23,0,0,0,0 —>

Организация бизнеса

p, blockquote 24,0,0,0,0 —>

Если же у человека есть выход на поставщиков какой-либо техники или интересных товаров, то он может организовать собственный бизнес с минимальными вложениями. Так, например, работают интернет-магазины. У них есть выход на поставщиков и, если они получают заказы, то сразу оформляют нужный товар на складе. Так им удается избежать трат на аренду помещения и заработных плат. Более того, есть огромное количество людей, которые живут на такой доход.

p, blockquote 25,0,0,0,0 —>

Организация совместных закупок

Это очень интересный и перспективный способ того, как воспользоваться своей базой поставщиков.

p, blockquote 26,0,0,0,0 —>

Человек должен найти много людей, которым, например, требуются телевизоры. Нужно указать в заявке о возможности обратиться к поставщику. Собрав, например 10 таких людей, человек сможет убить сразу двух зайцев. Он поможет поставщикам реализовать свой продукт и заработает деньги. Как? За организацию совместных закупок нужно брать небольшой процент от суммы каждого товара. Люди, в свою очередь, смогут сэкономить деньги на покупке нужных вещей. Как результат: все довольны и получили желаемое, так еще и дешевле, чем в магазинах!

p, blockquote 27,0,0,0,0 —> p, blockquote 28,0,0,0,1 —>

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

Как собрать каталог поставщиков?

Допустим, у нас стоит задача собрать каталог поставщиков некоторой продукции, как это быстро решить?

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

Ознакомьтесь с примерами электронных каталогов, разработанными на нашей платформе.

Ручной сбор данных в каталог поставщиков

Берете 2GIS и обзваниваете все конторы на предмет получения информации о них. Представиться лучше как каталог по такой-то отрасли, который бесплатно размещает компании и дает дополнительный охват целевой аудитории. Метод долгий, затратный, в то же время наверно самый качественный, т.к. вы получите информацию из первых уст. Если ваш каталог поставщиков предполагает в итоге не более 100 позиций, – такой вариант вполне подойдет.

Парсинг существующих каталогов поставщиков

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

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

Каталог поставщиков на основе API интерфейса

Вы находите поставщиков и договариваетесь, что они будут работать с вами по API. Либо вы предоставляете им API для работы на вашей площадке, либо они предоставляют вам свой API, чтобы вы могли забрать необходимые данные. Если у вас немного поставщиков и они довольно “продвинутые”, то этот вариант является наиболее предпочтительным, т.к. позволяет обеспечить актуальность данных в дальнейшем, т.е. обновление данных будет происходить автоматически по API.

Идеальный вариант сбора данных для каталога

Итак, каталог поставщиков можно составить тремя основными способами:

• вручную,
• парсингом похожих сайтов,
• настроить обмен данными по API.

Какой вариант выбрать – решать вам. Как видите, это зависит от конкретной ситуации.

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

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

Для лучшего представления о функционировании агрегатора посмотрите демо площадки, разработанное на базе нашей платформы

Как мы автоматизировали большой интернет-магазин и стали сопоставлять товары автоматически

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

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

• Работа с поставщиками. Чтобы продать что-то ненужное, нужно сначала купить что-то ненужное.
• Управление каталогом. У кого-то узкая специализация, а кто-то продает сотни тысяч разных товаров.
• Управление розничными ценами. Тут придется учесть и цены поставщиков, и цены конкурентов, и доступные финансовые инструменты.
• Работа со складом. В принципе, можно и не иметь собственного склада, а забирать товар со складов партнеров, но так или иначе вопрос стоит.
• Маркетинг. Тут наполнение сайта контентом, размещение на площадках, реклама (онлайн и офлайн), акции и много чего еще.
• Прием и обработка заказов. Колл-центр, корзина на сайте, заказы через мессенджеры, заказы через площадки и маркетплейсы.
• Доставка.
• Бухгалтерия и прочие внутренние системы.

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

Так что рассматриваем отдельную систему, более-менее универсальную, с которой интегрирована остальная инфраструктура компании.

В чем проблема работы с поставщиками

А их много, на самом деле. Просто приведу некоторые:

• Поставщиков самих по себе много. У нас — порядка 400. Каждому нужно уделить какое-то время.
• Нет единого способа получить предложения поставщиков. Кто-то шлет на почту по расписанию, кто-то по запросу, кто-то загружает в файлообменники, кто-то размещает на сайте. Способов много, вплоть до пересылки файла по скайпу.
• Нет единого формата данных. Я даже картинку нарисовал на эту тему (она ниже, таблицы символизируют разные форматы).
• Существует понятие минимальных розничных и минимальных оптовых цен, которые нужно соблюдать, чтобы продолжать работать с поставщиком. Часто они предоставляются в своем собственном формате.
• Номенклатура у каждого поставщика своя. В итоге один и тот же товар называется по-разному, и нет уникального ключа, по которому их можно достаточно просто сопоставить. Поэтому мы сопоставляем сложно.
• Не автоматизирована система размещения заказа у поставщика. У кого-то заказываем по скайпу, у кого-то в личном кабинете, кому-то каждый вечер посылаем эксель-файл со списком заказов.

С этими проблемами мы научились справляться. Кроме последней, над последней работа в процессе. Сейчас будут технические подробности, а потом рассмотрим следующий список.

Собираем данные

Как было

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

Как стало

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

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

Получилось гибко. Естественно, не с первого раза все учли, но сейчас гибкости хватает чтобы настроить обработку всех 400 поставщиков с учетом того, что у всех разное форматирование файлов.

Что касается форматов файлов, то понимаем xls, xlsx, csv, xml (yml). В нашем случае этого оказалось достаточно.

Также придумали, как фильтровать записи. Завели список стоп-слов, и если предложение поставщика его содержит, то мы его не обрабатываем. Технические подробности такие: на небольшом списке можно и даже лучше “в лоб”, на больших списках быстрее фильтр Блума. С ним поэкспериментировали и оставили все как есть, потому что выигрыш ощущается на списке на порядок большем нашего.

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

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

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

Как работает сопоставление

Как было

Сопоставлением занималась 1С (сторонний платный модуль). Что касается удобства / скорости / точности, то такая система позволяла поддерживать каталог с 60 тысячами товаров в наличии на этом уровне силами 6 человек. То есть, каждый день устаревало и исчезало из предложений поставщиков столько сопоставленных товаров, сколько создавалось новых. Очень примерно — 0,5% от размеров каталога, т.е. 300 товаров.

Как стало: общее описание подхода

Чуть выше я привел пример того, что нам нужно сопоставлять. Исследуя тему сопоставления, я был немного удивлен, что ElasticSearch пользуется популярностью для задачи сопоставления, по-моему, у него есть концептуальные ограничения. Что касается нашего стека технологий, то для хранения данных мы используем MS SQL Server, но сопоставление работает на собственной инфраструктуре, а поскольку данных много и нужно обрабатывать их быстро, применяем оптимизированные под конкретную задачу структуры данных и стараемся без необходимости не обращаться к диску, базе и прочим медленным системам.

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

План выполнения каждого нашего алгоритма (с оговоркой про вырожденные случаи) можно кратко представить такой общей последовательностью:

Токенизация. Разбиваем исходную строку на что-то значащие самостоятельные части. Можно сделать один раз и дальше использовать во всех алгоритмах.

Нормализация токенов. По-хорошему, нужно слова естественного языка привести к общему числу и склонению, а идентификаторы типа “АВС15МХ” (это кириллица, если что) конвертировать в латиницу. И привести все к одному регистру.

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

Поиск лучшего кандидата на совпадение.

Оценка вероятности того, что исходная строка и лучший кандидат действительно обозначают один и тот же товар.

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

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

Потом нам нужно нормализовать токены. Конвертируем их в нижний регистр. Вместо того, чтобы приводить все к именительному падежу, мы просто отрезаем окончания. Ещё у нас есть небольшой словарь, и мы переводим наши токены на английский. Помимо прочего, перевод избавляет нас от синонимов, похожие по смыслу русские слова на английский переводятся одинаково. Где не сумели перевести, меняем похожие по написанию кириллические символы на латиницу. (Совсем не лишнее, как оказалось. Даже там, где не ждешь подвоха, например, в строке “Samsung UЕ43NU7100U” кириллическая Е вполне может встретиться).

Категоризация токенов. Мы можем выделить категорию, производителя, модель, артикул, EAN, цвет. У нас есть каталог, где данные структурированы. У нас есть данные о конкурентах, которые нам предоставляют торговые площадки. При их обработке, где возможно, мы структурируем данные. Мы можем исправить ошибки или опечатки, например, производителя или цвет, которые встречаются только один раз во всех наших источниках, не считать за производителя и цвет соответственно. Как следствие, у нас есть большой словарь возможных производителей, моделей, артикулов, цветов, и категоризация токена — это просто поиск по словарю за O(1). Теоретически, можно иметь открытый список категорий и какой-то умный алгоритм классификации, но и наш базовый подход работает хорошо, а категоризация не является узким местом.

Тут следует оговориться, что иногда поставщик предоставляет уже структурированные данные, например, артикул находится в отдельной ячейке в таблице, или поставщик при оптовых продажах делает скидку от розницы, а розничные цены можно получить в yml (xml) формате. Тогда мы сохраняем структуру данных, а эвристически делим токены на категории только из неструктурированных данных.

А теперь о том, какие алгоритмы и в каком порядке применяем.

Точные и почти точные совпадения

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

Что касается хэширования, то напрашивается применение «исключающего или» и функция типа такой:

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

Таким образом, мы ищем совпадения без учета порядка слов и их формы. Работает такой поиск за O(1).

К сожалению, редко, но бывает и так: “ABC 42 Type 16” и “ABC 16 Type 42”, и это два разных товара. С такими вещами мы тоже научились справляться, но об этом позже.

Сопоставление подтвержденных человеком товаров

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

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

Сопоставление по атрибутам

Первые два алгоритма быстрые и точные, но их недостаточно. Следующим мы применяем сопоставление по атрибутам.

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

Самый надежный атрибут — это EAN (https://ru.wikipedia.org/wiki/European_Article_Number). Совпадения EAN дают почти стопроцентную гарантию того, что это один и тот же продукт. Несовпадение EAN, при этом, ничего не говорит, потому что у одного товара могут быть разные EAN. Все бы хорошо, но в наших данных EAN встречается редко, поэтому его влияние на сопоставление на уровне погрешности.

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

Как и на прошлом этапе, тут мы используем словари (поиск за O(1)), а в качестве ключа используется хэш от (производитель + модель + артикул). Хэширование позволяет производить все операции в памяти. При этом учитываем еще и цвет, если он совпадает или его нет, то считаем, что товары совпали.

Поиск наилучшего совпадения

Предыдущие этапы были простыми, быстрыми и довольно надежными, но, к сожалению, они покрывают меньше половины сопоставлений.

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

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

Мы придумали представить наш каталог в виде словаря словарей, на первом уровне ключом будет хэш от производителя (данные в каталоге структурированы, производителя мы знаем), значением — словарь. Теперь второй уровень. Ключом на втором уровне будет хэш от токена, значением — список id товаров из каталога, где этот токен встречается. Причем в данном случае мы используем в том числе комбинации токенов в том порядке, в котором они встречаются в нашем каталоге. Что использовать как комбинацию, а что — нет решаем в зависимости от количества токенов, их длины и так далее, это компромисс между скоростью, точностью и требуемой памятью. На рисунке я упрощенно изобразил эту структуру, без хэшей и без нормализации.

Если на каждый товар в среднем использовать 20 токенов, то в наших списках, которые значения вложенного словаря, ссылка на товар встретится в среднем 20 раз. Различных токенов при этом будет не более чем в 20 раз больше, чем товаров в каталоге. Приблизительно можно посчитать память, которая требуется на каталог в миллион записей: 20 миллионов ключей по 4 байта на каждый, 20 миллионов id товаров по 4 байта на каждый, накладные расходы на организацию словарей и списков (порядок такой же, но поскольку размер списков и словарей мы не знаем заранее, а увеличиваем на ходу, умножаем на два). Итого — 480 мегабайт. В реальности получилось чуть больше токенов на товар, и нам требуется до 800 мегабайт на каталог в миллион товаров. Что приемлемо, возможности современного железа позволяют одновременно хранить в памяти больше сотни каталогов такого размера.

Вернемся к алгоритму. Имея строку, которую нам надо сопоставить, мы можем определить производителя (у нас есть алгоритм категоризации), а потом получить токены по такому же алгоритму, что и для товаров из каталога. Тут я подразумеваю в том числе комбинации токенов.

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

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

Вернемся к строкам “ABC 42 Type 16” и “ABC 16 Type 42”. Решение на удивление простое — если у нескольких товаров одинаковые хэши, то мы их не сопоставляем по хэшу. А последний алгоритм учтет порядок токенов. Теоретически, такие строки в прайсе поставщика нельзя сопоставить чему-то произвольному, где числа 16 и 42 не встречаются вообще. Практически с такой необходимостью мы не сталкивались.

Скорость и точность сопоставления

Теперь что касается скорости всего этого. Время, которое требуется на подготовку словарей, линейно зависит от размеров каталога. Время, которое требуется непосредственно на сопоставление, линейно зависит от количества сопоставляемых товаров. Все структуры данных, участвующие в поиске, не изменяются после создания. Это дает нам возможность использовать многопоточность на этапе сопоставления. Подготовительная работа для каталога в миллион записей занимает порядка 40-80 секунд. Сопоставление работает со скоростью 20-40 тысяч записей в секунду и не зависит от размера каталога. Потом, правда, нужно сохранить результаты. Выбранный подход в целом выгодный для больших объемов, но файл с десятком записей будет обрабатываться непропорционально долго. Поэтому мы используем кэш и пересчитываем наши поисковые структуры раз в 15 минут.

Правда, данные для сопоставления нужно где-то прочитать (чаще всего это эксель файл), а сопоставленные предложения нужно где-то сохранить, и это тоже занимает время. Так что итоговое число 2-4 тысячи записей в секунду.

Для того, чтобы оценить точность, мы подготовили тестовый набор из примерно 20 000 проверенных вручную сопоставлений разных поставщиков из разных категорий. Алгоритм после каждого изменения тестировался на этих данных. Результаты получились такие:

• товар есть в каталоге и был сопоставлен правильно — 84%
• товар есть в каталоге, но не был сопоставлен, требуется ручное сопоставление — 16%
• товар есть в каталоге и был сопоставлен неправильно — 0.2%
• товара нет в каталоге, и программа это правильно определила — 98.5%
• товара нет в каталоге, но программа его сопоставила какому-то из товаров — 1.5%

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

Есть еще одна категория ошибок, не связанная с сопоставлением, это неправильные цены наших поставщиков. Отчасти поэтому мы не учитываем цену в сопоставлении. Мы решили, что раз уж у нас есть дополнительная информация в виде цены, то будем с ее помощью пытаться определить не только свои, но и чужие ошибки.

Поиск неправильных цен

Это та часть, которая над которой мы сейчас активно экспериментируем. Базовая версия есть, и она не позволяет продавать телефон по цене чехла, но у меня есть ощущение, что можно лучше.

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

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

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

Работа с базой данных

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

• удаляем индексы из таблицы, с которой работаем
• отключаем full text индексирование по этой таблице
• удаляем все записи с определенным условием (например, все предложения конкретных поставщиков, которых обрабатываем в данный момент)
• вставляем новые записи при помощи BULK COPY
• заново создаем индексы
• включаем full text индексирование

Bulk copy работает со скоростью 10-40 тысяч записей в секунду, почему такой большой разброс еще предстоит выяснить, но и так приемлемо.

Удаление записей занимает примерно такое же время, что и вставка. Еще некоторое время требуется на пересоздание индексов.

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

В чем проблема ведения каталога

А их тоже много. Сейчас будем перечислять:

• В каталоге примерно 400 тысяч товаров из совершенно разных категорий. Невозможно профессионально разбираться в каждой из категорий.
• Нужно соблюдать определенную стилистику, следовать общими для всего каталога правилами наименования, выделения подкатегорий и так далее. Таким образом мы пытаемся добиться стройной и логичной структуры каталога.
• Один и тот же товар можно создать несколько раз, и это проблема. Без инструмента, который анализирует похожие наименования, создание дублей происходит постоянно.
• Разумно добавлять в каталог те товары, которые есть у поставщиков в наличии. При этом нужно иметь приоритеты на товарные категории.
• Нам требуется несколько каталогов. Один свой, его мы ведем сами, другой — каталог агрегатора, его обновляем по апи. Смысл второго каталога в том, что площадка-агрегатор работает только с собственным каталогом, и, соответственно, предложения принимает в своей номенклатуре. Это еще одно место, где оказалось нужно сопоставление.

Как мы ведем каталог

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

В качестве базовых свойств мы выбрали такие:

• производитель
• категория
• модель
• артикул
• цвет
• EAN

Как работает поиск

Удобство управления каталогом, в первую очередь — это возможность быстро найти товар в каталоге или предложение поставщика, причем есть нюансы. Например, нужно уметь искать строчку “LG 21.5″ 22MP48D-P (16:9, IPS, VGA, DVI) 22MP48D-P” по запросу “2MP48”.

Полнотекстовый поиск sql сервера из коробки не годится, потому что он так не умеет, а поиск с помощью LIKE ‘%2MP48%’ слишком медленный.

Наше решение достаточно стандартно, мы используем N-граммы. Если точнее — то триграммы. А уже по триграммам строим полнотекстовый индекс и производим полнотекстовый поиск. Не уверен, что мы очень рационально используем место в этом случае, но по скорости такое решение подошло, в зависимости от запроса, работает от 50 до 500 миллисекунд, иногда до секунды на массиве в три миллиона записей.

Поясню, строка “LG 21.5″ 22MP48D-P (16:9, IPS, VGA, DVI) 22MP48D-P” преобразуется в строку “lg2 g21 215 152 522 22m 2mp mp4 p48 48d 8dp dp1 p16 169 69i 9ip ips psv svg vga gad adv dvi vi2 i22”, которая сохраняется в отдельное поле, которое участвует в полнотекстовом индексе.

Кстати, триграммы нам еще пригодятся.

Создание нового товара

В большинстве своем, товары в каталоге создаются по предложениям поставщика. То есть, у нас уже есть информация, что поставщик предлагает “LG Монитор LCD 21.5» [16:9] 1920х1080(FHD) IPS, nonGLARE, 250cd/m2, H178°/V178°, 1000:1, 16.7M Color, 5ms, VGA, DVI, Tilt, 2Y, Black OK 22MP48D-P” по цене 120 долларов, и на складе у него от 5 до 10 единиц.

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

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

Во-вторых, прежде чем показать пользователю форму создания нового товара, мы выполним поиск по триграммам и покажем самые релевантные результаты. (технически это делается с помощью CONTAINSTABLE).

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

И в четвертых, помните мы разбивали строки на токены, нормализовали их, считали хэши? Сделаем то же самое и просто не дадим создать товары с одинаковыми хэшами.

Еще на этом этапе мы стараемся помочь пользователю. По строке, которая есть в прайсе, мы попытаемся определить производителя, категорию, артикул, EAN и цвет товара. Сначала — по токенам (мы умеем их делить на категории), потом, если не получилось, найдем самый похожий товар по триграммам. И, если он достаточно похож, заполним производителя и категорию.

Редактирование товара работает почти так же, просто не все применимо.

Как мы формируем свои цены

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

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

Собираем цены конкурентов

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

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

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

Настраимаем профиль

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

Потом настраиваем финансовые инструменты, указываем, какие рассрочки доступны и сколько банк заберет себе.

И уже в границах наценок мы формируем собственные цены, пытаясь соблюсти тот самый баланс во-первых, и сделать так, чтобы наши складские товары лучше продавались во-вторых. Это в двух словах так, а на деле я не берусь объяснить простыми словами, что там происходит.

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

Интеграции со сторонними системами

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

Рассылки настраиваемые, так (и не только так) мы доставляем наши предложения оптовым клиентам.

Еще один способ работать с оптовыми клиентами — b2b портал. Он пока в активной разработке, заработает буквально через месяц.

Аккаунты, логирование изменений

Еще один неинтересный с технической точки зрения вопрос. У нас у каждого пользователя свой аккаунт.

Если кратко, то сказать можно следующее: если используется ORM, то в ней есть встроенный механизм отслеживания изменений. Если в него влезть (а в нашем случае это EF Core и там даже API есть), то можно получить логирование всего практически в две строчки.

Для истории изменений мы сделали интерфейс, и теперь можно проследить, кто и что менял в настройках системы, кто редактировал или сопоставлял определенные товары и так далее.

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

Немного об общем устройстве системы

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

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

Веб-интерфейс сделан на ASP.NET Core и бутстрапе, а тяжелые опрерации выполняются Windows — сервисом.

Еще одна особенность, которая пошла проекту на пользу, на мой взгляд, — разные модели на чтение и запись данных. Полноценный СQRS мы не внедряли, но одну из концепций оттуда взяли. Запись в базу у нас через репозитории, но объекты, которые используются для записи, никогда не покидают методов обновления / создания / удаления. Массовое обновление делаем посредством BULK COPY. Для чтения сделана отдельная модель и отдельная прослойка доступа к данным, таким образом мы читаем только то, что нужно в конкретный момент. Получилось, что можно пользоваться ORM, и при этом избежать тяжелых запросов, обращений к базе в неопределенные моменты (как с ленивой загрузкой), проблемы N + 1. А еще мы используем модель для чтения как DTO.

Из крупных зависимостей у нас ASP.NET Core, несколько сторонних nuget-пакетов и MS SQL Server. Пока возможно, стараемся не зависеть от множества сторонних систем. Для того, чтобы полностью развернуть проект локально, достаточно установить SQL Server, забрать исходный код из системы контроля версий и собрать проект. Нужные базы будут созданы автоматически, а больше ничего и не надо. Возможно, придется изменить одну-две строчки в конфигурации.

Что не сделали

Пока не сделали систему знаний по проекту. Хотим делать вики и подсказки по месту. Не сделали простого интуитивного интерфейса, тот, что есть неплох, но для неподготовленного человека немного запутан. CI/CD пока только в планах.

Не сделали обработку подробных характеристик товаров. Тоже планируем, но пока нет конкретного срока.

Итоги с точки зрения бизнеса

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

За три месяца, которые мы в продакшене, количество товаров в наличии для оптовых клиентов выросло с 70 тысяч до 230 тысяч, количество товаров на сайте — с 60 тысяч до 140 тысяч. Сайт всегда запаздывает, потому что ему нужны характеристики, картинки, описания товаров. На агрегатор мы выгружаем 106 тысяч предложений вместо 40 тысяч три месяца назад. Количество человек, работающих с каталогом, не изменилось.

Мы работаем с 425 поставщиками, это число выросло почти в два раза за три месяца. Отслеживаем цены более тысячи конкурентов. Ну как отслеживаем — система для парсинга у нас есть, но в большинстве случаев мы берем готовые данные у тех, кто их регулярно предоставляет.

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

Еще один итог — получился проект, по сути не связанный с инфраструктурой конкретного магазина, и из него можно сделать публичный сервис. Так было задумано с самого начала, и этот план почти сработал. Коробочного решения еще, к сожалению, не получилось. Чтобы предлагать проект как сервис, где можно зарегистрироваться, поставить галочку “я согласен”, и который работает “как есть”, без адаптации к клиенту, нужно переработать интерфейс, добавить гибкости и создать вики. А еще сделать инфраструктуру легко масштабируемой и устранить единую точку отказа. Сейчас у нас из средств обеспечения надежности есть только регулярные бекапы. Как энтерпрайз решение, думаю, мы уже готовы решать задачи бизнеса. Дело за малым — найти бизнес.

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