Варианты товаров в интернет-магазине: как спроектировать каталог, карточку и остатки, чтобы SKU не сломали проект

Варианты товара — одна из тех функций, которые кажутся простыми на старте и превращаются в главный источник боли через полгода после запуска. Магазин одежды с 40 моделями, 6 размерами и 4 цветами — это почти тысяча комбинаций, у каждой свои остатки, цена и фото. Если спроектировать каталог «на глаз», к третьей коллекции менеджеры начнут вести учёт в Excel, а покупатели — натыкаться на надпись «в наличии» у товаров, которых физически нет. В этой статье разберём, как правильно смоделировать варианты, спроектировать карточку и выстроить обмен остатками, чтобы рост ассортимента не сломал ни каталог, ни интеграции.

Что такое вариант товара и чем он отличается от опции

Ключевое понятие — SKU (Stock Keeping Unit): учётная единица, у которой есть собственные остатки, штрихкод и цена. Вариант — это конкретная комбинация значений атрибутов: «футболка Model X, размер M, цвет графит». Важно не путать варианты с обычными опциями: подарочная упаковка или гравировка не создают новый SKU, потому что не влияют на складской учёт. Правило простое: если по комбинации нужно хранить остатки и отгружать её со склада — это вариант; если это лишь дополнение к покупке — это опция. Ошибка на этом уровне стоит дорого: переделывать модель данных после запуска значит переносить тысячи позиций и переписывать интеграции.

Комбинаторный взрыв: как 7 размеров и 4 цвета превращаются в тысячи SKU

Число вариантов растёт как произведение значений атрибутов, а не как сумма. Одна модель кроссовок: 7 размеров × 4 цвета = 28 SKU. Коллекция из 60 моделей — уже 1 680 учётных позиций, каждая со своими остатками и карточкой на складе. Добавьте третий атрибут «ширина колодки» — получите 6 720 SKU без увеличения реального ассортимента. Отсюда типичные симптомы: администратор тратит часы на заведение одного товара, фильтры в каталоге тормозят, а выгрузка на маркетплейсы падает по таймауту. Поэтому первый шаг проектирования — ревизия атрибутов: оставить только те, что реально влияют на выбор покупателя и складской учёт, остальное вынести в описание или опции.

Структура каталога: один товар с вариантами или отдельные карточки

Базовый принцип: один товар — одна карточка, варианты внутри неё. Покупателю, который выбирает футболку, не нужны 24 отдельные позиции в выдаче — ему нужна одна карточка, где он быстро выберет размер и цвет. Когда что использовать:

• Один товар с вариантами — размеры, цвета и простые комплектации одной модели;
• Отдельные карточки — позиции с разным артикулом производителя, существенно разной ценой или собственным SEO-спросом (например, смартфон на 128 ГБ и 512 ГБ часто выводят отдельно);
• Наборы и комплекты — собранные из нескольких товаров позиции со своим SKU и остатком.

Ещё один критерий — поисковое поведение: если люди ищут «футболка oversize белая», а не просто «футболка», вам нужны фасетные фильтры, а не дробление каталога на сотни карточек.

Карточка товара: как оформить выбор варианта

Интерфейс должен показывать доступность ещё до клика. Цвета — свотчи с миниатюрой фото конкретного расцветки, размеры — кнопки, где недоступный размер неактивен (или кликабелен с пометкой «ожидается», если включён предзаказ). Галерея обязана переключаться на фото выбранного цвета — это заметно влияет на конверсию и снижает возвраты. Обязательный сценарий: покупатель выбрал цвет, для которого остался единственный размер, — система мягко подсказывает это, а не выдаёт ошибку после нажатия «В корзину». И правило для разработчиков: цена, наличие и артикул должны обновляться без перезагрузки страницы — по AJAX или из предзагруженных данных вариантов.

Остатки и цены: всё живёт на уровне SKU

Остаток хранится на уровне варианта, а не товара — это аксиома, которую нарушают постоянно, особенно при интеграции с 1С, где «остатки по характеристикам» нужно корректно настроить в обмене. Что обязательно настроить:

1. Пороговые значения: показывать «мало осталось» при остатке ≤ 3 штук — это работает на конверсию;
2. Единую политику нулевых остатков: скрывать вариант, оставлять с пометкой «нет в наличии» или включать предзаказ;
3. Резерв товара при оформлении заказа и время жизни резерва — иначе остатки «разъедутся» параллельными заказами;
4. Отдельные цены для вариантов: размер XL из премиум-ткани дороже S — если прайс в 1С ведётся по артикулам, обмен должен подтягивать цену каждого SKU;
5. Логику комплектов: либо отдельный SKU с собственным остатком, либо сборка на лету с проверкой остатков каждого компонента.

И не забудьте про единицы измерения: «цена за метр» при остатках в рулонах — отдельная история складского учёта.

Техническая реализация и интеграция с 1С и CRM

На уровне базы правильная модель — три сущности: товар (общие данные), атрибуты со справочником допустимых значений и варианты как таблица комбинаций со ссылкой на каждый SKU. Плохая модель — цвета и размеры строкой в одном поле или варианты как дубли товаров: на объёмах от пары тысяч SKU каталог начнёт тормозить, а фильтры по атрибутам станут невозможными. При интеграции с 1С используйте обмен через CommerceML или API с идентификацией вариантов по артикулу и штрихкоду, а не по названию: переименование характеристики на стороне склада не должно ронять соответствие. Обмен остатков делайте инкрементальным (только изменённые позиции) — полная выгрузка 10 000 SKU каждые пять минут положит и сайт, и 1С. Отдельно продумайте конфликтные ситуации: заказ пришёл на сайт, а склад уже продал последнюю единицу, — нужен процесс быстрой отмены и уведомления покупателя.

SEO вариантов: одна каноническая страница вместо сотен дублей

С точки зрения поисковой оптимизации варианты не должны плодить индексируемые страницы. Рабочая схема: одна каноническая страница товара, выбор варианта — через параметры вида ?color=graphite&size=m без индексации комбинаций. Исключение — комбинации с реальным поисковым спросом: «кроссовки 43 размер белые» люди ищут отдельно, и такая страница может честно конкурировать в выдаче. В любом случае не оставляйте десятки URL с одинаковым контентом — это размывает релевантность и съедает краулинговый бюджет. Фасетные фильтры закрывайте от индексации либо генерируйте посадочные страницы только для частотных сочетаний фильтров, где вы реально можете дать уникальный текст.

Частые ошибки, которые мы видим на аудитах

• Остатки на уровне товара, а не SKU — покупатель заказывает «есть в наличии», а склад отвечает «этого цвета нет»;
• Варианты, созданные как дубли товаров, — каталог распухает, фильтры показывают лишнее, SEO размывается;
• Атрибуты, заведённые свободным текстом («размер: М / m / 48-50»), — фильтры и обмен с 1С ломаются;
• Одна фотография на 12 расцветок — конверсия падает, возвраты растут;
• Полный пересчёт всех остатков при каждом заказе вместо точечного обновления одного SKU;
• Комплекты без проверки остатков компонентов — магазин продаёт то, чего нет на складе.

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

Итог

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