Структура каталога интернет-магазина: как не перепутать категории, свойства и варианты

Почему каталог начинает разрастаться одинаковыми ветками

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

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

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

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

Где заканчивается категория и начинается свойство

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

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

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

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

Разные названия одинаковых свойств

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

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

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

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

Новый товар или исполнение существующего

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

В описании вариативных товаров WooCommerce у варианта есть собственные цена, изображение и сведения об остатке; ему можно назначить SKU — артикул для учёта. Запасы учитываются на уровне общего товара или отдельных вариантов. Выбор затрагивает работу склада. Сначала выясняют, какие исполнения хранятся отдельно и по каким записям списывают остаток, а затем определяют, как связать эти записи с вариантами на витрине и передать выбор в систему заказов.

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

Для цветочного гипермаркета команда ШТАБ ИТ разработала сайт на 1С-Битрикс с каталогом и торговыми предложениями. Сайт интегрировали с 1С, в том числе для обмена заказами. Здесь товарная модель связывает витрину с учётной системой.

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

Лишние сочетания размеров и материалов

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

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

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

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

Пробная загрузка до массового переноса

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

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

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

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

Что останется, если исправить только меню

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

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

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