Как спроектировать каталог интернет-магазина: категории, фильтры и карточки

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

На практике каталог определяет, как магазин разговаривает с покупателем.

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

Поэтому каталог стоит проектировать не как место хранения товаров, а как систему выбора.

10 мин чтения2 147 словE-commerce и AI
Александр Владимиров
Александр Владимиров
Автор CompanionAI
Как спроектировать каталог интернет-магазина: категории, фильтры и карточки

Мы столкнулись с этим при создании демо-магазина Bosco Wood. Казалось бы, мебель разложить несложно: столы, стулья, кресла, шкафы, консоли. Но затем появились вопросы. Что делать с коллекциями? Цвет — это характеристика, фильтр или вариант? Столы одной модели длиной 160 и 180 см должны находиться в одной карточке или в разных? Какие параметры нужны покупателю в каталоге, а какие достаточно показать уже внутри товара?

Разберём этот процесс по порядку.

Каталог интернет-магазина начинается со сценария выбора

У бизнеса и покупателя почти всегда разный взгляд на ассортимент.

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

Страница каталога демо магазина bosco wood

*Страница каталога демо магазина bosco wood

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

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

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

Получается простой маршрут:

потребность → категория → фильтры → карточка → выбор

Категория отвечает на вопрос «что я ищу?».

Фильтры — «какие варианты мне подходят?».

Карточка товара — «подходит ли мне именно эта модель?».

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

Почему структуру компании не стоит переносить на сайт как есть

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

Коллекция Natura → серия 03 → артикул → отделка.

Сотруднику всё понятно.

Покупателю — не обязательно.

Для него естественнее:

Столы → Обеденные столы

а уже внутри категории — выбор размера, материала, формы и других важных параметров.

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

Главный принцип здесь простой:

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

Что нужно определить в ассортименте до создания категорий

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

На демо-магазине мы разделили как минимум:

  • тип товара;
  • модель;
  • коллекцию;
  • вариант товара;
  • связи с другими товарами.

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

Пример карточек товара в каталоге

Тип товара, модель и коллекция — разные вещи

Возьмём условный стол Lago.

Стол — тип товара.

Lago — модель.

Natura — коллекция, в которую вместе со столом могут входить стулья, шкаф или консоль.

Один товар одновременно описывается несколькими признаками:

Тип: обеденный стол

Модель: Lago

Коллекция: Natura

Материал: массив дуба

Отделка: медовый дуб

Ошибка начинается, когда все эти признаки пытаются превратить в уровни дерева:

Мебель → Natura → Столы → Дуб → Медовый дуб → Lago

Формально логика есть. Пользоваться таким каталогом неудобно.

Что считать отдельным товаром

Ещё один вопрос, который лучше решить до наполнения: где заканчивается одна модель и начинается другая?

Например, стол Lago может выпускаться длиной 160 и 180 см.

Это может быть:

одна карточка → два варианта

или:

две самостоятельные карточки.

На решение влияют цена, остатки, артикулы, изображения, характеристики и пользовательский сценарий.

Полезная проверка:

Покупатель воспринимает это как «тот же стол, но другого размера» или как два разных товара?

Если это одна модель с выбором модификации, чаще логичнее работать с вариантами.

Конкретный продаваемый вариант обычно получает собственный SKU — учётную единицу, по которой можно отдельно хранить цену, остаток и другие данные.

Как разделить ассортимент на категории и не построить лабиринт

Категория нужна не потому, что несколько товаров можно логически объединить. Её задача — сократить пространство выбора.

Для мебельного магазина понятны категории:

Столы → Обеденные столы

Стулья → Обеденные стулья

Шкафы

Кресла

А структура вроде:

Мебель → Мебель для дома → Мебель для кухни → Столы для кухни → Деревянные столы

может оказаться лишней, особенно если в последнем разделе всего несколько моделей.

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

Когда нужна подкатегория

Подкатегория оправдана, если группа:

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

Например, если в разделе «Столы» сотни позиций, деление на обеденные, письменные, журнальные и кофейные заметно упрощает поиск.

Но параметр «массив дуба» уже чаще логичнее оставить фильтром внутри категории «Обеденные столы».

Категория или фильтр?

Это один из самых полезных вопросов при проектировании каталога.

ПризнакЧто чаще использовать
Обеденные столыКатегория
Письменные столыКатегория
Массив дубаФильтр
Длина до 180 смФильтр
На 6 человекФильтр
NaturaКоллекция
Круглые столыФильтр или отдельная посадочная при достаточном ассортименте и спросе

Универсального правила нет. Но хорошая отправная точка такая:

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

Категория и коллекция решают разные задачи

Для нашего демо-магазина это особенно важно.

Человек может сначала искать обеденный стол — это товарная категория.

А после выбора модели захотеть посмотреть всю Natura — это коллекция.

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

Карточку товара нужно спроектировать до того, как её наполнять

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

Базовая модель карточки может включать:

  • название и артикул;
  • категорию и коллекцию;
  • цену и наличие;
  • характеристики;
  • размеры;
  • материалы;
  • варианты;
  • изображения;
  • описание;
  • связанные товары.

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

Для разных типов товара нужны разные поля

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

Для обеденного стола важны:

длина, ширина, высота, форма, материал, количество мест.

Для кресла:

габариты, материал каркаса, обивка, размеры посадки.

Для шкафа:

ширина, высота, глубина, количество секций, внутреннее устройство.

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

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

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

Один смысл — одно значение

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

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

Дуб

дуб

массив дуба

натуральный дуб

дуб натуральный

Человек может догадаться, что речь идёт об одном или близких материалах. Для системы это разные значения.

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

Поэтому характеристики лучше нормализовать заранее.

Например:

Характеристика: Материал

Допустимое значение: Массив дуба

То же самое касается форматов.

Если длина хранится в сантиметрах, не стоит в одной карточке писать 180, во второй 180 см, а в третьей 1800 мм.

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

Характеристика, фильтр и вариант товара — три разные задачи

Эти понятия часто смешивают, хотя в каталоге они выполняют разные функции.

СущностьЗадачаПример
КатегорияОбъединяет класс товаровОбеденные столы
ХарактеристикаОписывает конкретный товарМатериал: массив дуба
ФильтрСужает выборМатериал
ВариантВыбирает модификациюДлина: 160 / 180 см

Одно свойство при этом может участвовать сразу в нескольких механизмах.

Допустим, цвет.

В карточке:

Цвет: медовый дуб — характеристика.

В списке товаров:

Цвет → медовый дуб — фильтр.

А если одну модель можно заказать в нескольких отделках:

Медовый дуб / тёмный дуб — варианты товара.

Это не три разных параметра. Это три разных способа использовать один признак.

Характеристика описывает товар

Характеристика — это факт.

Из чего сделан стол? Каковы его размеры? Какая отделка? Сколько он весит?

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

Фильтр помогает принимать решение

Не нужно автоматически превращать все характеристики в фильтры.

Вопрос проще:

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

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

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

Вариант — это конкретная модификация модели

У варианта могут быть собственные:

  • SKU;
  • цена;
  • остаток;
  • размеры;
  • изображения.

Например, Lago длиной 160 и 180 см может оставаться одной моделью, но иметь две продаваемые модификации.

Если человек воспринимает выбор как «тот же товар, но другого размера, цвета или комплектации», одна карточка с вариантами часто оказывается понятнее.

Если же характеристики и сценарий покупки существенно расходятся, есть основания разделить позиции.

Какие характеристики стоит превращать в фильтры

Самый простой способ определить фильтры — на время забыть о CMS и выписать вопросы покупателя.

Для обеденного стола это может быть:

Какой размер мне подходит?

Сколько человек должно помещаться?

Какая нужна форма?

Какой материал?

Какой цвет?

Какой бюджет?

Из этих вопросов появляются возможные фильтры:

размер, количество мест, форма, материал, цвет, цена.

После этого их уже нужно сопоставить с реальным ассортиментом.

Если в магазине 95% столов одного материала, фильтр «Материал» мало что даст. Если размеры сильно различаются и это важный критерий выбора — фильтр по размеру становится полезным.

Фильтр не должен демонстрировать возможности CMS

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

Десятки чекбоксов, технические термины, параметры с одним значением, пустые группы.

Формально данных много. Практической помощи мало.

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

Почему одного дерева категорий недостаточно

Классическая структура выглядит так:

категория → подкатегория → товар.

Но ассортимент редко существует только в виде дерева.

Возьмём обеденный стол из нашего демо-магазина. С ним могут быть связаны:

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

То есть каталог содержит горизонтальные связи:

товар ↔ коллекция ↔ комплект ↔ аналог ↔ сопутствующий товар

Для мебельного магазина это особенно заметно.

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

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

Такая структура пригодится не только интерфейсу. Структурированные категории, характеристики и связи позже можно использовать в рекомендациях, поиске по каталогу и AI-ассистентах.

Проверяем каталог на реальном сценарии покупателя

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

Возьмём наш пример:

Нужен обеденный стол из дуба примерно на шесть человек и длиной не больше 180 см.

Теперь попробуем пройти будущий магазин.

Понятно ли, в какой раздел зайти?

Есть ли категория «Обеденные столы»?

Можно ли выбрать материал?

Можно ли ограничить размер?

Указано ли количество мест?

После фильтрации остаётся несколько действительно подходящих моделей?

Можно ли быстро понять разницу между ними по карточкам?

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

Это простой, но полезный тест:

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

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

Именно поэтому универсального набора категорий и фильтров не существует.

Чем больше ассортимент, тем дороже ошибка

На десяти карточках неправильное название характеристики можно исправить вручную.

На тысяче SKU то же решение может потребовать изменения данных, фильтров, импорта и уже созданных страниц.

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

Наше предложение по разработке интернет-магазина!

Индивидуальный дизайн, SEO, контент и маркетинговая система CompanionAI — всё необходимое для успешного запуска продаж и дальнейшего роста.

Что проверить до начала наполнения интернет-магазина

До массовой загрузки товаров стоит убедиться, что:

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

После этого можно переходить к наполнению.

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

В следующей части цикла разберём это на том же демо-магазине: «Наполнение интернет-магазина: как подготовить контент и карточки товаров».