Что делать, если номенклатура хранится в 1С, кроссы и применяемость — в Excel или внешних базах, а ассортимент насчитывает десятки тысяч SKU? Нужно ли сначала собрать все данные в одной системе или сайт может одновременно работать с несколькими источниками? И как при этом сделать каталог, которым действительно смогут пользоваться дилеры и клиенты?
В этом видео вместе с техническим специалистом разбираем эти вопросы на примере действующего сайта производителя автозапчастей. Это не классический интернет-магазин: прямых продаж на сайте нет. Его задача — помочь пользователю найти нужную деталь, проверить характеристики и совместимость, подобрать аналоги, а затем перейти к дилеру, у которого товар можно приобрести.
Показываем, как может быть организована работа с данными, когда они изначально находятся в разных системах. Номенклатура может поступать из 1С, кроссы и применяемость — из собственных таблиц или внешних баз. При этом не всегда нужно сначала переносить все в единую систему: архитектуру можно выстроить вокруг уже существующих у компании процессов и настроить обмен с несколькими источниками.
Отдельно разбираем поиск — одну из ключевых частей сайта производителя с большой номенклатурой. Показываем поиск по артикулу и его части, оригинальному номеру и наименованию, подбор по VIN, марке, модели и модификации автомобиля. В карточке товара пользователь получает характеристики, оригинальные номера, применяемость и другую информацию, которая помогает самостоятельно проверить деталь и реже обращаться к менеджеру с уточнениями. В проекте предусмотрены разные сценарии поиска именно для того, чтобы пользователь мог подобрать товар как при наличии точного номера, так и без него.
Еще один вопрос — откуда брать кроссы и данные о применяемости. В видео сравниваем несколько вариантов: собственную базу, внешние базы и подключение сторонних сервисов. У каждого подхода своя экономика и требования к поддержке. Например, при использовании платных внешних сервисов важно заранее продумать ограничения запросов, чтобы не оплачивать неконтролируемое использование базы.
Отдельный блок посвящен масштабированию. На живом проекте показываем, почему структуру каталога важно проектировать не только под текущий ассортимент, но и под его дальнейший рост. Категории, фильтры, поиск и источники данных должны быть организованы так, чтобы увеличение товарной матрицы не требовало перестраивать весь сайт.
При этом не обязательно запускать весь функционал одновременно. На первом этапе можно реализовать каталог, карточку товара, поиск по артикулам и оригинальным номерам, аналоги и раздел «Где купить». Более сложные механики — применяемость, подбор по автомобилю, гараж и API для дистрибьюторов — подключать постепенно, если архитектура проекта предусматривает их появление в будущем.