Интернет-магазин автозапчастей: какой поиск по артикулу включить в разработку

В задании на разработку магазина автозапчастей написано «сделать умный поиск». Разработчик понимает под этим исправление опечаток, владелец — поиск по номеру детали, а менеджер — подбор аналога с нужным сроком поставки. У этих задач разные данные и разные критерии правильного результата. Их стоит разделить до выбора платформы и оценки проекта.

Сначала определите, что покупатель уже знает

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

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

Артикул храните как обозначение, а не как обычное число

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

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

Нормализация должна иметь границы

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

Похожая буква из другого алфавита — отдельная проблема. Латинская A и кириллическая А выглядят близко, но это разные символы. Unicode описывает механизмы работы с визуально похожими знаками; простая замена всех похожих букв не становится проверкой идентичности товара. Для магазина полезнее заметить подозрительный ввод и дать понятную возможность уточнить его.

Что покажет прототип ниже

Локальный инструмент ищет только внутри выбранного бренда. Сначала он показывает совпадения исходного артикула без учёта регистра обычных латинских и русских букв. Затем — кандидатов, у которых после удаления пробелов и обычного дефиса получилась одинаковая строка. Эти две группы намеренно подписаны по-разному.

В учебной таблице есть позиции AB-001 и AB001 одного бренда, тот же номер другого производителя и вариант с кириллической буквой. Точное совпадение не растворяется среди похожих. Кандидат после удаления разделителей остаётся кандидатом: инструмент не складывает их остатки и не выбирает вместо покупателя.

Предложения поставщиков — следующий слой

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

При заказе интеграции уточните период обновления, поведение при недоступном источнике и обработку отказа поставщика. Лицензии каталогов, ограничения API и стоимость подключения оцениваются отдельно. Нельзя честно обещать «все аналоги» без согласованного источника и описания его границ.

Принимайте поиск на собственном контрольном наборе

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

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