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

Что обещает поиск по полному артикулу

Почему товар не находится по артикулу, который виден в его карточке? Такой результат лишает покупателя самого короткого пути к заказу: обозначение уже известно, а каталог заставляет повторно выбирать изделие. Разберём поиск оборудования, где рядом используются артикул изготовителя и внутренний код продавца. Для него важнее сохранить точность полного обозначения, чем показать побольше внешне похожих позиций.

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

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

Один товар или список вариантов

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

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

Три способа сопоставить запрос с товаром

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

Полное совпадение

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

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

Единый вид записи

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

Подбор близких обозначений

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

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

Где приведение к единому виду становится подменой

Правило «убрать все пробелы и дефисы» опасно, если после преобразования несколько исходных кодов становятся одинаковыми: поиск уже не сможет однозначно определить товар, хотя покупатель ввёл его полное обозначение без ошибки. Такие совпадения ищут в каталоге до запуска.

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

Что поручить владельцу каталога

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

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

Старые и чужие коды

Артикулы снятых моделей, прежние обозначения поставщика и обозначения аналогов полезны только при явной связи с текущим товаром. Связь «тот же товар под старым кодом» отличается от связи «возможная замена»: в первом случае покупателю объясняют переименование, во втором предлагают сравнение параметров. База соответствий требует владельца. Если никто не отвечает за её актуальность, поиск начнёт воспроизводить устаревшие связи увереннее, чем сотрудник, который помнит об изменении изделия.

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

Как принять выдачу на настоящем каталоге

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

Набор запросов для испытания

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

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

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

Обновление данных

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

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

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

Точный товар остаётся главным результатом

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

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

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