Size Table Binding in 1C-Bitrix: Reduce Returns by 15–20%
Returns of clothing in online stores reach 30–40% — and 80% of those are due to incorrect size. A size table tied to a product reduces this indicator by 15–20%. But standard Bitrix does not store or output such data. We configure infoblocks and properties to tie the size grid to the product and category. Our experience: over 8 years we have implemented this for dozens of stores — one project with a catalog of 10,000 products reduced returns from 35% to 22% within two months after implementation. Savings on logistics and repackaging with an average order of $27–39 and 10,000 orders per month amounted to over $36k–52k (approx $50,000).
Why is a Size Table Critical for a Clothing Store?
Returns of clothing in online stores reach 30–40% — and most are due to incorrect size. A size table next to the trade offer selection directly reduces this indicator. Our experience: implementing such a table reduces returns by 15–20% within the first month. This pays for development costs through reduced logistics and repackaging.
Storage Architecture
Size tables are structured data tied to products or categories. In Bitrix, there are two places for this:
Property of infoblock type 'Bind to elements' — a separate infoblock 'Size Tables' is created, each element of which contains table data. Products reference the desired table via the PROP_SIZE_TABLE property. Advantage: convenient to reuse one table for hundreds of products of the same brand.
User field of type 'HTML/text' — the table is stored directly in the product property as HTML markup. Cheaper but does not scale: when changing the size grid, each product must be edited manually.
The first option is recommended. Structure of the 'Size Tables' infoblock:
| Field | Type | Description |
|---|---|---|
| NAME | string | Name (e.g., 'Women's clothing EU') |
| PROP_BRAND | string | Brand |
| PROP_CATEGORY | bind to section | Catalog category |
| PROP_TABLE_DATA | text | JSON with table data |
| PROP_MEASURE_SYSTEM | list | EU / US / UK / RU |
Table data stored in JSON:
{ "headers": ["Size EU", "Size RU", "Chest (cm)", "Hips (cm)"], "rows": [ ["XS", "40", "80-84", "86-90"], ["S", "42", "84-88", "90-94"], ["M", "44", "88-92", "94-98"] ] } Code example: getting the size table for a product
Logic for obtaining the table for a product:
function getSizeTableForProduct(int $productId, int $sectionId): ?array { // First check product property $element = CIBlockElement::GetByID($productId)->GetNextElement(); $props = $element->GetProperties(); $tableId = (int)($props['SIZE_TABLE']['VALUE'] ?? 0); // If not, get from category 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); } How to Implement Cascading Size Table Binding?
Binding is implemented at two levels:
Category level — a UF field UF_DEFAULT_SIZE_TABLE (bind to element of size table infoblock) is created for the section. All products in the category automatically inherit this table if they do not have a personal one.
Product level — an infoblock property PROP_SIZE_TABLE of type 'Bind to elements'. Allows overriding the table for a specific product.
This approach is better than storing the table as HTML text because it allows easy centralized data changes — through one infoblock element, not through all products.
Output in the Product Card
The size table is displayed in the template of the bitrix:catalog.element component. The standard approach is a modal window when clicking the 'Size Table' link next to the trade offer selector.
In the template, we include the data:
// In result_modifier.php or directly in template.php $sizeTable = getSizeTableForProduct( $arResult['ID'], $arResult['IBLOCK_SECTION_ID'] ); $this->SetViewTarget('size_table_data'); Important nuance: if the product has trade offers of different sizes, the table should only be shown when a size parameter is actively selected (color changes with size are not needed — only the table).
Multilingual and Multiple Measurement Systems
For stores operating in different regions, one table should contain several measurement systems. In JSON, grouping by system is added:
{ "systems": { "EU": { "headers": [...], "rows": [...] }, "US": { "headers": [...], "rows": [...] }, "UK": { "headers": [...], "rows": [...] } } } The measurement system switch is displayed above the table via JS without page reload.
Timeline
| Scope of work | Time |
|---|---|
| Infoblock + property + basic output | 1 day |
| Cascading binding category/product + modal | 2–3 days |
| Multi-system measurement + multilingual | +1–2 days |
What is Included in the Work
- Designing the infoblock structure and properties for your catalog.
- Setting up cascading binding (category → product) with inheritance.
- Implementing a modal window with size table in the product card.
- Integrating with 1C for automatic size grid loading via CommerceML.
- Testing on test products and mock returns.
- Providing documentation on the data structure and API for further development.
- One month of support after delivery: fixing issues, helping with content.
The 'size table — trade offer' combination pays for itself by reducing returns in the first month. If you want a consultation for your project — contact us. We will evaluate the task, propose architecture and timeline. Order implementation to reduce returns and increase profit.