Категории: одно дерево, а не три
Категория отвечает на вопрос «что это за товар вообще». Футболка, дрель, корм для кошек. Дерево категорий должно быть одно, и каждый товар должен иметь одно основное место в нём - иначе вы не сможете сказать, сколько у вас товаров, и поисковые системы получат десять URL с одним и тем же содержимым.
Типичная ошибка - попытка запихнуть в категории то, что категориями не является. «Скидки», «Новинки», «Подарки до 3000», «Бренд Х» - это не категории, а подборки: динамические выборки по признакам товара. Разница практическая. Категорию нужно наполнять руками, подборка собирается сама и не ломается, когда акция закончилась.
Глубину дерева держите в пределах трёх уровней. Дальше начинается «нажми ещё пять раз» - пользователь бросает и уходит в поиск по сайту. Если вам не хватает трёх уровней, вам, скорее всего, нужны не подкатегории, а фильтры.
- Основная категория товара - одна, остальные вхождения делаются подборками или фильтрами.
- Название категории - то, как товар называет покупатель, а не как он значится в вашей 1С.
- Каждая категория должна иметь свой URL и свой заголовок: /catalog/dreli/, а не /catalog/?cat=17.
Характеристики и фильтры: фильтр - это следствие, а не отдельная фича
Фильтр нельзя «прикрутить». Фильтр появляется сам, если у товаров есть структурированные характеристики. Пока размер лежит внутри текстового описания строкой «размер 42-44, состав хлопок», фильтровать нечего - данных в машинном виде нет.
Поэтому первый шаг - не выбор дизайна фильтров, а таблица характеристик. Для каждой категории список свойств: имя, тип (число, вариант из списка, да/нет), единица измерения. У дрелей - мощность в ваттах, тип патрона, наличие реверса. У футболок - размер, цвет, состав. Наборы у разных категорий разные, и это нормально: фильтры должны быть привязаны к категории, а не общие на весь магазин.
Проверить готовность к фильтрам можно за минуту: попробуйте выгрузить товары в таблицу, где каждая характеристика - отдельный столбец с одинаковыми написаниями. Если в столбце «цвет» встречаются «чёрный», «черный», «black» и «чёрн.» - фильтр будет показывать четыре разных цвета вместо одного. Справочники значений нужны заранее.
Ещё один момент, о котором вспоминают поздно: количество товаров рядом с каждым значением фильтра и запрет на выбор комбинаций, дающих ноль результатов. И URL, который меняется при выборе фильтров, чтобы отфильтрованную выборку можно было отправить в мессенджере и поставить в рекламу.
- Числовые характеристики храните числом, иначе не сделать диапазон «от - до».
- Определите заранее, какие фильтры попадут в URL как отдельные страницы под поиск, а какие останутся служебными.
- Мобильный вид фильтров проектируется отдельно: на телефоне это отдельный экран с кнопкой «Показать N товаров», а не боковая колонка.
Варианты товара: где вас ждут самые дорогие переделки
Вариант (его же называют торговым предложением или SKU) - это конкретная комбинация: та же футболка, но синяя и размера L. У варианта свои остаток, штрихкод, иногда своя цена и свои фото. Карточка при этом одна: покупатель выбирает цвет и размер, не перепрыгивая между страницами.
Альтернативный путь - заводить каждую комбинацию отдельным товаром. Иногда это оправдано, если различия существенные и товары продаются независимо. Но в одежде и обуви это почти всегда приводит к тому, что каталог раздувается в десять раз, отзывы размазываются по клонам, а в фильтре «цвет» появляется по три одинаковых карточки.
Именно на этом месте случаются самые болезненные переделки. Магазин запустили с плоским списком товаров, через полгода добавили размеры - и выясняется, что переписать нужно карточку, корзину, синхронизацию с 1С, выгрузку в маркетплейсы и всю аналитику. Поэтому вопрос «у вас будут варианты» задаётся до начала работ, даже если сейчас варианты не нужны.
Отдельно решите, что происходит с недоступной комбинацией. Размер L в синем закончился - вариант должен становиться неактивным с понятной подписью, а не молча пропадать и не давать положить в корзину то, чего нет.
- Что различает варианты: цвет, размер, объём, комплектация - список фиксируется до разработки.
- Что у варианта своё: остаток, цена, фото, артикул.
- Что делать при нуле на складе: скрывать, показывать как недоступное или предлагать уведомление о поступлении.
Остатки и источник правды
Каталог живёт только в связке с учётом. Ответьте на один вопрос: где хранится правда о товарах и цене - в 1С, в МоемСкладе, в таблице или на самом сайте? Если правда в учётной системе, сайт не должен позволять редактировать эти поля вручную: два источника всегда расходятся, и через месяц никто не знает, какая цена настоящая.
Из этого следуют требования к обмену: что синхронизируется (цены, остатки, новые товары, фото), как часто и что происходит при сбое. Отдельно проговорите, кто отвечает за наполнение: описания, фото в едином формате, заполненные характеристики. Разработчик сделает механику каталога, но пятьсот карточек с пустыми характеристиками не оживит никакая система фильтров.
Что спросить у подрядчика до подписания
Каталог - самая дорогая часть магазина именно потому, что его цена определяется структурой данных, а не количеством страниц. Разговор о структуре - это разговор о смете.
Если в ответ на просьбу расписать смету списком приходит одна цифра - это не смета. Каталог должен быть разложен на пункты: дерево категорий, характеристики и фильтры, варианты, обмен с учётной системой, поиск, импорт.
- Сколько уровней категорий и куда попадают подборки вроде «Хиты» и «Распродажа».
- Привязаны фильтры к категориям или общие на весь сайт.
- Будут ли варианты товара и что у них своё - цена, фото, остаток.
- Что происходит с товаром при нулевом остатке.
- Как выглядят URL категорий и отфильтрованных выборок.
- Кто заполняет характеристики первых партий товаров и в каком формате.
- Что будет при сбое обмена с 1С и увидит ли это кто-то, кроме покупателя.
Когда всё это не нужно
Если у вас двадцать товаров без вариантов, фильтры не нужны - они будут фильтровать пустоту, а пользователю проще пролистать список целиком. Хватит одной страницы с сеткой товаров и понятного поиска.
Если товар всего один или это услуга - интернет-магазин не нужен вообще. Лендинг с формой и оплатой решит задачу дешевле и быстрее, а разбираться в остатках и категориях будет незачем.
И наоборот: если у вас уже есть учётная система, размеры и несколько тысяч позиций, не пытайтесь сэкономить на структуре каталога, добирая красивым дизайном. Дизайн переделывается за недели, структура данных - за месяцы.
Как мы это делаем
В EFIMOV DEV мы начинаем магазин не с макетов, а с модели каталога: дерево категорий, характеристики по категориям, схема вариантов и обмен с учётной системой. Собираем на React и Node.js, обсуждать задачу вы будете напрямую с тем, кто ведёт проект. Вилка «от» по интернет-магазинам, поддержке и другим услугам опубликована на сайте, точная смета - после брифа, когда понятны структура товаров и источник данных.
Каталог начинается не с дизайна, а с модели данных: одно дерево категорий, характеристики в отдельных полях, продуманные варианты и один источник правды об остатках. Попросите подрядчика расписать эти пункты в смете отдельными строками - по ответам сразу видно, кто делал магазины, а кто только страницы.
Частые вопросы
Чем фильтр отличается от подкатегории?
Подкатегория отвечает на вопрос «что это за товар» и наполняется вручную. Фильтр отбирает товары по характеристике внутри категории и работает автоматически. Если вы собираетесь заводить подкатегорию «Синие футболки», вам нужен фильтр по цвету, а не подкатегория.
Можно ли сначала запустить простой каталог, а фильтры и размеры добавить потом?
Запустить простой вид - можно, и часто это разумно. Но структуру данных под варианты и характеристики нужно заложить сразу, иначе позже переписывать придётся карточку, корзину, обмен с учётной системой и аналитику. Скажите подрядчику о планах заранее, даже если сейчас варианты не нужны.
Сколько товаров нужно, чтобы фильтры были оправданы?
Ориентируйтесь на поведение, а не на число. Фильтры нужны, когда внутри одной категории десятки позиций и покупатель выбирает по конкретным признакам - размеру, мощности, объёму. При двадцати товарах на весь магазин достаточно сетки и поиска.
Кто заполняет характеристики товаров?
Обычно заказчик или его контент-менеджер, потому что это знание о товаре. Разработчик делает механику, справочники значений и импорт из таблицы или учётной системы. Договоритесь об этом до старта: незаполненные характеристики превращают фильтры в нерабочий элемент.