Покупатель нашёл нужную куртку, но замер на строке выбора размера: «M — это на меня или уже нет?». Если рядом нет понятной таблицы с реальными мерками, дальше два сценария — он уходит без покупки или берёт «на удачу», а через неделю оформляет возврат. И то и другое стоит магазину денег. Размер — это не мелкий технический атрибут, а точка, где заказ либо состоится, либо развалится.
Эта статья — практический разбор того, как в интернет-магазине на 1С-Битрикс правильно подавать размерные сетки: где хранить таблицы, как связать их с торговыми предложениями и наличием, как сделать подбор размера удобным и как всё это снижает возвраты. По ходу — конкретика по инфоблокам, свойствам и обмену с 1С. Если каталог и товарные данные у вас ведутся в 1С, многое из этого закрывается грамотной автоматизацией на 1С.
Коротко
- Размер-вариант (торговое предложение) и таблица размеров — разные сущности; в карточке нужны оба.
- Одинаковые сетки выносите в отдельный инфоблок и привязывайте к товарам, а не дублируйте руками.
- Показывайте реальные мерки изделия и подсказку, как снимать замеры, а не только буквы размеров.
- Понятная таблица и подбор размера напрямую снижают возвраты «не подошёл размер».
Почему размер решает судьбу заказа
В категориях одежды, обуви, нижнего белья и детских товаров размер — главный источник сомнений и возвратов. Покупатель не может примерить вещь, поэтому решение он принимает по цифрам и по доверию к магазину. Если таблицы нет или она формальная («S/M/L» без сантиметров), клиент вынужден угадывать. Часть угадавших неверно вернёт товар, часть просто не станет рисковать.
Возврат — это не только логистика в обе стороны. Это замороженный на складе товар, повторная приёмка, иногда потеря товарного вида и почти всегда — испорченное впечатление о магазине. Поэтому вложение в качественные размерные сетки окупается не ростом конверсии как таковой, а снижением дорогой обратной логистики и повторных обращений.
Размер-вариант и таблица размеров — не одно и то же
Первое, что важно развести, — две разные вещи, которые часто путают.
- Размер как торговое предложение (SKU). Это конкретный вариант товара с собственным остатком, штрихкодом и иногда ценой. Покупатель выбирает «42» и добавляет в корзину именно эту позицию. В Битриксе это реализуется через торговые предложения инфоблока и свойство «Размер».
- Таблица размеров. Это справочная информация: какому обхвату груди или длине стопы соответствует каждый размер. Она не участвует в учёте и наличии, а помогает выбрать правильный вариант.
Ошибка — пытаться заменить одно другим. Если оставить только буквы размеров-вариантов без таблицы, покупатель не поймёт, что именно значит «M». Если сделать красивую таблицу, но не связать размеры с остатками, клиент выберет размер, которого нет в наличии. Работать должны обе сущности одновременно.
Где хранить сетку в 1С-Битрикс
1С-Битрикс даёт несколько мест для хранения таблицы, и выбор зависит от того, насколько сетки различаются между товарами.
| Способ хранения | Когда подходит | Плюсы и минусы |
|---|---|---|
| Отдельный инфоблок «Размерные сетки» + свойство-привязка | Сетка общая для коллекции, бренда или категории | Обновляешь в одном месте — меняется везде; требует настройки привязки |
| HTML-свойство товара | У каждой модели своя уникальная таблица | Гибко, но легко наплодить дубли и рассинхрон |
| Highload-блок соответствий размеров | Нужны таблицы соответствия систем RU/EU/US | Переиспользуемый справочник, удобен для подбора; сложнее в настройке |
| Раздел описания / вкладка | Простые магазины без частых изменений | Быстро, но плохо масштабируется и не структурировано |
Практичный компромисс для среднего каталога — отдельный инфоблок с сетками, привязанный к товарам свойством типа «Привязка к элементам». Тогда сотни карточек ссылаются на одну таблицу, и её правка мгновенно отражается везде. Дублирование HTML в каждой карточке — прямой путь к рассинхрону, когда в одном месте сетку обновили, а в сотне других забыли.
Что должно быть в таблице размеров
Формальная таблица «S — M — L» бесполезна: она не отвечает на вопрос покупателя «а это мой размер?». Полезная таблица содержит реальные мерки и подсказку, как их снимать.
- Мерки изделия или тела. Обхват груди, талии, бёдер, длина рукава, длина по стельке — в сантиметрах. Уточняйте, это мерки тела или готового изделия.
- Соответствие систем. Наш размер, RU, EU, US, международный (S/M/L) в одной строке.
- Инструкция по замерам. Короткая подсказка или схема, где и как прикладывать сантиметр.
- Особенности посадки. «Маломерит», «свободный крой» — фразы, которые реально помогают выбрать.
Чем ближе таблица к реальным сантиметрам, тем меньше ошибок. Покупатель, который знает свой обхват груди, найдёт размер точно, а не по ощущению «обычно ношу M».
Как подавать таблицу в карточке
Место и способ показа не менее важны, чем содержание. Оптимальный паттерн для большинства магазинов:
- Ссылка рядом с селектором. Возле выбора размера — заметная ссылка «Таблица размеров». Именно здесь возникает сомнение, и помощь должна быть под рукой.
- Открытие в модальном окне. Таблица разворачивается поповером без перезагрузки страницы, чтобы не удлинять карточку для тех, кто размер знает.
- Подгрузка по клику. Тяжёлый HTML и картинки мерок грузятся только при открытии окна, а не в каждой карточке сразу.
- Единый шаблон. Изображения схемы замеров лежат в общем шаблоне и переиспользуются, а не встраиваются в каждый товар.
Разные системы размеров: RU, EU, US
Покупатели привыкли к разным системам: кто-то мыслит российскими размерами, кто-то — европейскими, а обувь часто знают в US. Если показать только одну систему, часть аудитории будет вынуждена конвертировать в уме и ошибаться. Правильный подход — свести системы в одну таблицу, где строка соответствует одному физическому размеру, а столбцы — разным обозначениям.
Хранить соответствия удобно в справочнике — highload-блоке или отдельном инфоблоке. Тогда таблица соответствий заводится один раз и переиспользуется во всех карточках, а не пересчитывается вручную. Это тот случай, когда правильная структура данных экономит недели работы контент-менеджеров. Похожая логика справочников и связей подробно разобрана в материале про D7 и ORM в 1С-Битрикс.
Интерактивный подбор размера
Следующий уровень после статической таблицы — интерактивный подбор. Покупатель вводит свои мерки (обхват груди, рост, длину стопы), а система подсказывает подходящий размер и подсвечивает его в селекторе. Это заметно точнее, чем самостоятельное чтение таблицы.
Реализовать подбор можно по-разному: от простого JavaScript-калькулятора поверх той же справочной таблицы до полноценного модуля с учётом особенностей посадки конкретных моделей. Логику соответствия «мерка → размер» держат в тех же справочниках, что и таблица, чтобы не поддерживать две разные истины. Такой модуль — это уже кастомная разработка; принципы построения собственных модулей мы разбирали в статье про разработку своего модуля для 1С-Битрикс.
Размеры как торговые предложения и наличие
Таблица подскажет размер, но покупателю нужно ещё и купить именно доступный вариант. Здесь работают торговые предложения: каждый размер — отдельный SKU со своим остатком. Ключевые правила:
- Показывайте наличие по каждому размеру. Отсутствующие размеры не скрывайте молча — помечайте их как «нет в наличии» или предлагайте уведомить о поступлении.
- Блокируйте выбор пустых размеров. Нельзя дать положить в корзину размер, которого нет на складе.
- Синхронизируйте с таблицей. В селекторе — только те размеры, что реально существуют у модели; таблица показывает мерки для всех.
Остатки по размерам приходят на сайт обменом из учётной системы, поэтому корректность селектора напрямую зависит от качества интеграции с 1С. Если остатки «отстают», покупатель закажет размер, которого нет, и это тоже приведёт к отмене и разочарованию.
Автоматизация из 1С обменом
Размеры-варианты и их остатки обычно ведутся в 1С, а на сайт попадают обменом CommerceML: товар выгружается с торговыми предложениями, где размер — это характеристика предложения. Характеристики изделия (мерки) тоже можно передавать свойствами, если они ведутся в учёте.
Что это даёт: сетка и селектор на сайте всегда соответствуют реальному ассортименту, а контент-менеджеру не нужно вбивать размеры и остатки руками. Если обмен настроен грамотно, добавление нового размера в 1С автоматически появляется на сайте с корректным остатком. Настройка стабильного обмена и правил выгрузки — это область аудита и оптимизации 1С: часто именно кривой обмен, а не сайт, виноват в рассинхроне размеров и наличия.
Мобильная версия и доступность
Больше половины заказов в fashion-категориях приходит с телефонов, а широкая таблица размеров на маленьком экране легко превращается в нечитаемую кашу. О мобильной подаче нужно думать отдельно:
- Горизонтальная прокрутка таблицы. Широкую таблицу оборачивают в контейнер со скроллом, чтобы она не ломала вёрстку.
- Крупные элементы выбора. Размеры-варианты — это кнопки под палец, а не мелкие радиокнопки.
- Доступность. Таблица размечена как настоящая таблица с заголовками, модальное окно закрывается с клавиатуры, ссылки читаемы скринридером.
Влияние на возвраты и что мерить
Чтобы понять, работает ли ваша размерная система, за ней нужно наблюдать в цифрах. Полезно отслеживать:
- Долю возвратов «не подошёл размер». Главная целевая метрика — она должна падать после улучшения таблиц.
- Открытия таблицы размеров. Как часто клиенты пользуются подсказкой — если почти никогда, значит, её не находят.
- Конверсию карточек с размерами. Сравните до и после внедрения понятной сетки.
- Обращения в поддержку по размерам. Снижение вопросов «какой размер выбрать» — тоже показатель.
Возвраты и повторные отгрузки — это данные из учётной системы. Связка сайта и 1С позволяет видеть причины возвратов и считать их долю в разрезе моделей, чтобы точечно доработать проблемные сетки.
Частые ошибки
- Таблица только с буквами. «S/M/L» без сантиметров не помогает выбрать и не снижает возвраты.
- Дублирование HTML в каждой карточке. Обновить сотни таблиц вручную нереально — начинается рассинхрон.
- Ссылка на сетку спрятана внизу описания. Ею не пользуются, потому что не находят в момент выбора.
- Одна система размеров. Покупатели из других систем конвертируют в уме и ошибаются.
- Селектор не связан с остатками. Можно заказать размер, которого нет, — отмена и негатив.
- Таблица ломает мобильную вёрстку. Широкие таблицы без скролла нечитаемы на телефоне.
- Размеры заводят руками, а не обменом. Ручной ввод отстаёт от реального ассортимента и остатков.
Чек-лист внедрения
- Разделите сущности. Размеры-варианты — торговые предложения с остатками; таблица — справочная информация.
- Выберите место хранения. Общие сетки — в отдельный инфоблок с привязкой; соответствия систем — в справочник.
- Наполните таблицу мерками. Сантиметры, соответствие RU/EU/US, схема замеров, особенности посадки.
- Поставьте ссылку у селектора. Модальное окно, подгрузка по клику, общий шаблон изображений.
- Свяжите с наличием. Показывайте и блокируйте отсутствующие размеры, синхронизируйте с остатками.
- Настройте обмен с 1С. Размеры и остатки приходят обменом, а не заводятся руками.
- Проверьте мобильную версию. Скролл таблицы, крупные кнопки, доступность с клавиатуры.
- Мерьте возвраты. Отслеживайте долю возвратов по размеру и открытия таблицы, дорабатывайте проблемные модели.
Вывод
Размерная сетка — это не декоративный элемент карточки, а инструмент, который прямо влияет на возвраты и доверие. Разведите две сущности: размеры-варианты как торговые предложения с остатками и таблицу размеров как справочную информацию. Храните общие сетки централизованно, наполняйте их реальными мерками, показывайте у селектора в удобном окне и связывайте с наличием.
И помните, что данные о размерах и остатках живут в 1С: чем точнее и стабильнее обмен, тем меньше рассинхрона и ошибочных заказов. Наведённый порядок в товарных данных и обмене превращает размерные сетки из источника возвратов в конкурентное преимущество магазина.
