Возвраты одежды в онлайн-магазине достигают 30–40% — и 80% из-за неверного размера. Таблица размеров, привязанная к товару, снижает этот показатель на 15–20%. Но стандартный Битрикс не умеет хранить и выводить такие данные. Настраиваем инфоблоки и свойства, чтобы замкнуть размерную сетку на товар и категорию. Наш опыт: за 8 лет мы реализовали это для десятков магазинов — один проект с каталогом 10 000 товаров после внедрения снизил возвраты с 35% до 22% за два месяца. Экономия на логистике и переупаковке при среднем чеке $27–39 и 10 000 заказах в месяц составила более $36k–52k.
Почему таблица размеров критична для одежного магазина?
Возвраты одежды в онлайн-магазинах достигают 30–40% — и большинство из них связано с неправильным размером. Таблица размеров рядом с выбором торгового предложения напрямую снижает этот показатель. Наш опыт: внедрение такой таблицы сокращает возвраты на 15–20% уже в первый месяц. Это окупает затраты на разработку за счёт сокращения логистики и переупаковки.
Архитектура хранения
Таблицы размеров — это структурированные данные, привязанные к товарам или категориям. В Битриксе для этого есть два места:
Свойство инфоблока типа «Привязка к элементам» — создаётся отдельный инфоблок «Таблицы размеров», каждый элемент которого содержит данные таблицы. Товары через свойство PROP_SIZE_TABLE ссылаются на нужную таблицу. Плюс: удобно переиспользовать одну таблицу для сотен товаров одного бренда.
Пользовательское поле типа «HTML/текст» — таблица хранится прямо в свойстве товара в виде HTML-разметки. Дешевле, но не масштабируется: при изменении размерной сетки нужно править каждый товар вручную.
Рекомендуется первый вариант. Структура инфоблока «Таблицы размеров»:
| Поле | Тип | Описание |
|---|---|---|
| NAME | string | Название (например, «Женская одежда EU») |
| PROP_BRAND | string | Бренд |
| PROP_CATEGORY | привязка к разделу | Категория каталога |
| PROP_TABLE_DATA | text | JSON с данными таблицы |
| PROP_MEASURE_SYSTEM | list | EU / US / UK / RU |
Данные таблицы хранятся в JSON:
{ "headers": ["Размер EU", "Размер RU", "Обхват груди (см)", "Обхват бёдер (см)"], "rows": [ ["XS", "40", "80-84", "86-90"], ["S", "42", "84-88", "90-94"], ["M", "44", "88-92", "94-98"] ] } Пример кода: получение таблицы размеров для товара
Логика получения таблицы для товара:
function getSizeTableForProduct(int $productId, int $sectionId): ?array { // Сначала проверяем свойство товара $element = CIBlockElement::GetByID($productId)->GetNextElement(); $props = $element->GetProperties(); $tableId = (int)($props['SIZE_TABLE']['VALUE'] ?? 0); // Если нет — берём из категории if (!$tableId) { $section = CIBlockSection::GetByID($sectionId)->Fetch(); $tableId = (int)($section['UF_DEFAULT_SIZE_TABLE'] ?? 0); } if (!$tableId) return null; $table = CIBlockElement::GetByID($tableId)->GetNextElement(); $tableProps = $table->GetProperties(); return json_decode($tableProps['TABLE_DATA']['VALUE'], true); } Как реализовать каскадную привязку таблицы размеров?
Привязка реализуется на двух уровнях:
Уровень категории — у раздела создаётся UF-поле UF_DEFAULT_SIZE_TABLE (привязка к элементу инфоблока размеров). Все товары категории автоматически наследуют эту таблицу, если у них не задана персональная.
Уровень товара — свойство инфоблока PROP_SIZE_TABLE с типом «Привязка к элементам». Позволяет переопределить таблицу для конкретного товара.
Этот подход лучше хранения таблицы в виде HTML-текста, так как позволяет легко изменять данные централизованно — через один элемент инфоблока, а не через все товары.
Вывод в карточке товара
Таблица размеров выводится в шаблоне компонента bitrix:catalog.element. Стандартный подход — всплывающее окно (modal) при нажатии ссылки «Таблица размеров» рядом с селектором торговых предложений.
В шаблоне подключаем данные:
// В result_modifier.php или непосредственно в template.php $sizeTable = getSizeTableForProduct( $arResult['ID'], $arResult['IBLOCK_SECTION_ID'] ); $this->SetViewTarget('size_table_data'); Важный нюанс: если товар имеет торговые предложения разных размеров, таблицу нужно показывать только при активном выборе размерного параметра (цвет менять вместе с размером не нужно — только таблица).
Мультиязычность и несколько систем мер
Для магазинов, работающих в разных регионах, одна таблица должна содержать несколько систем измерений. В JSON добавляется группировка по системе:
{ "systems": { "EU": { "headers": [...], "rows": [...] }, "US": { "headers": [...], "rows": [...] }, "UK": { "headers": [...], "rows": [...] } } } Переключатель системы мер выводится над таблицей через JS без перезагрузки страницы.
Сроки выполнения
| Объём работ | Срок |
|---|---|
| Инфоблок + свойство + базовый вывод | 1 день |
| Каскадная привязка категория/товар + modal | 2–3 дня |
| Мультисистема мер + мультиязычность | +1–2 дня |
Что входит в работу
- Проектирование структуры инфоблока и свойств под ваш каталог.
- Настройка каскадной привязки (категория → товар) с учётом наследования.
- Реализация модального окна с таблицей размеров в карточке товара.
- Интеграция с 1С для автоматической загрузки размерных сеток через CommerceML.
- Тестирование на тестовых товарах и моках возвратов.
- Предоставление документации по структуре данных и API для дальнейшего развития.
- Месяц поддержки после сдачи: исправление замечаний, помощь с контентом.
Связка «таблица размеров — торговое предложение» окупается снижением возвратов уже в первый месяц. Если хотите получить консультацию под ваш проект — свяжитесь с нами. Оценим задачу, предложим архитектуру и сроки. Закажите внедрение, чтобы сократить возвраты и повысить прибыль.