Why a shoe size chart breaks on a catalog
A shoe catalog is dozens of brands, each with its own size grid: European, American, British, Japanese in centimeters. While there are only a few items, the size chart on the site survives on manual edits — a manager opens a product card and enters the mappings.
As soon as the assortment exceeds several hundred models, manual edits stop keeping up with deliveries: some cards go out with someone else's grid, some with empty fields, and the customer sees one number on the page and another at the fitting.
The first typical failure is mismatched grids. Size 42 for one brand corresponds to a 27 cm foot, for another — 26.5 cm, and without a single reference of mappings, this data diverges already at the loading stage.
The second is data loss during catalog updates: an import from 1C overwrites product properties entirely, and the size chart assembled manually is reset along with them.
The third is edits that bypass the structure: sizes are appended directly into the product description, and they stop being filtered, exported to feeds, and included in size-based selection.
The cost of each failure is returns due to a pair that didn't fit and lost orders at the selection stage. Let's break down how this is closed at the catalog structure level, rather than with yet another manual edit.
What a correct size chart provides
A correct size chart is not a decorative block in a product page, but part of the catalog logic. When the development of a shoe size chart relies on actual last measurements rather than figures copied from someone else's site, the buyer stops guessing between two adjacent values.
The size is selected in one or two clicks, rather than after a conversation with a manager — and it is precisely at this step that a noticeable share of those who were already ready to place an order are lost.
Reducing returns begins with honest correspondence: if the product page specifies insole length and width, rather than just an abstract "42", the share of exchanges due to "size didn't fit" drops many times over.
This is especially noticeable where the catalog is assembled from several suppliers: each has its own last, and without bringing them to a common logic, the same size at different brands means a different foot.
A unified size grid solves this through a correspondence reference: we create normalized values, link suppliers' SKUs to them, and display to the buyer an already recalculated range.
Product page conversion grows not because of the block itself, but because of the doubt removed — a person sees that the size is confirmed by measurement, rather than taken at random.
Size automation removes manual labor: when a new batch is uploaded, values are pulled from the reference rather than entered manually in each product page.
Next, we break down how this is structured at the catalog level and what is needed from the supplier so that the grid remains reliable with every assortment update.
Methods for Displaying the Size Chart
Displaying a size chart on Bitrix is solved in three ways, and the choice between them is determined by how often sizes change and how deeply they are tied to the catalog. Let's examine each option from the standpoint of limitations, not just convenience.
Static Template
The table markup is stored directly in the component template or in a separate include file. It is suitable when there is a single chart for the entire catalog and it changes rarely — for example, standard footwear with a fixed lineup.
Limitation: any change to sizes requires editing the code and deploying to production, and a specific model cannot be tied to its own chart. On the other hand, this option does not create extra entities in the database and works the fastest.
Size Infoblock
We create a separate infoblock where each row is a size with parameters: foot length, correspondence to European and American sizing. Through a binding property, a product references the required set of sizes, and the table is assembled by a component on the detail page.
This is a workable option when different categories have their own charts: sneakers, boots, and children's footwear follow different lineups.
Limitations — a well-structured set of properties and thoughtful output are needed, otherwise extra database queries appear on large catalogs.
External Size Service
The data lives on the side of an external provider, while the site keeps a block that pulls the chart by model identifier. It is suitable for stores with a wide range of brands where lineups are updated centrally.
Limitations: dependence on the availability of a third-party service, loading delay, and the need to cache the response so the table does not slow down the page.
| Option | When it is suitable | Limitations |
|---|---|---|
| Static template | One chart per catalog, changes rarely | Edits via code, no binding to product |
| Size infoblock | Different lineups by category | Requires property structure and query optimization |
| External service | Many brands, centralized updates | Dependence on service, cache needed |
In practice, an infoblock is most often taken as the primary source, while the static template is kept for service pages. The external service is connected selectively — where the assortment truly requires it.
How we develop a size chart
Developing a size chart starts not with layout, but with analyzing what is already in the catalog.
At this stage, it is important to understand how product offers are structured, where characteristics are stored, whether products are linked to size grids, and how much the data in 1C matches what the customer sees on the website.
- Catalog audit. We export the structure of information blocks and product offers, compare size attributes with the nomenclature in 1C, and find products without sizes, duplicates, and discrepancies between the product card and the offer. The result is a data map: where the size is currently stored and what will need to be normalized.
- Structure design. We determine how the grid will be structured: a separate size information block, linkage to shoe type, a reference of correspondences between measurement systems. Here we also decide how the table will behave on the product card and in the catalog.
- Size setup. We create properties and linkages, configure exchange with 1C so that sizes are pulled from the accounting system rather than edited manually. For complex cases — correspondence between the sizing systems of different manufacturers.
- Verification. We run through product cards with different product types, check output on mobile devices, behavior when a size is missing, and the correctness of the size filter in the catalog.
- Documentation handover. We provide a description of the structure, a diagram of linkages, and instructions for adding new size grids — so that edits do not require a developer.
Each stage ends with approval, so there are no reworks at the final stage. Describe the task — we will come back with an estimate and a plan.
What the client receives after implementation
After implementing the size chart, the client receives not a "file with sizes" but a working catalog unit: a set of artifacts that can be handed over to their team and maintained without us. Below is what exactly stays in the project.
- Size grid configurations — linking sizes to products, categories, and brands, inheritance rules for new items so that a product page never ends up without a table.
- Data schemas — a description of entities and relationships between size, product, and inventory stock: it is clear where a value comes from and what will happen when it changes.
- Update regulations — the procedure for when a new model appears or a supplier changes: who changes what and in what sequence, so that the grid does not diverge from the catalog.
- Instructions for content managers — step-by-step scenarios with examples: how to add a size, how to fix an error, how to check the result before publishing.
- Validation rules — checks for duplicates, gaps, and incompatible values that catch an error at the input stage rather than in a customer's order.
- Output templates — display options for the table on the product page and in the mobile version, aligned with the current design.
- Integration documentation — how sizes are connected to 1С and data exchange, what to do when there is a discrepancy, and where to look when synchronization fails.
Each item is verified at acceptance: we show how the artifact works on a real product and hand over access. After that, your team manages sizes independently — our engineers step in when the logic changes or a new sales channel is added.
Case study: how a size chart accelerated shoe selection
The client is an online shoe store on 1C-Bitrix with an assortment of several brands. Size charts lived in three places: in the product description as text, in PDF attachments, and in the manager's correspondence with the supplier.
The buyer could not find the right number and left, while support spent up to a third of inquiries on the question "what is my size."
What it was like before implementation
Measurements at the start revealed three bottlenecks. Size selection took an average of 4-5 minutes: a person opened the product page, looked for the chart, did not find it, and wrote to chat. The share of returns due to "size did not fit" held at around 18% of all orders.
Manual chart edits — from 40 to 60 per month: the manager manually changed values in descriptions because each brand has its own numbering, and some suppliers sent data in different formats.
What was changed
We moved sizes into a separate information block linked to the brand and model, and on the product page we displayed an interactive chart: selecting fullness and foot type recalculates the recommended size.
Data from supplier price lists is loaded through exchange with 1С, and manual entry remained only for new brands. Additionally, we added a "your size in other brands" block — conversion between charts.
What it became after
Size selection time was reduced to 40-60 seconds — the buyer sees the recommendation right on the product page. The share of returns due to size dropped to 7%. Manual chart edits decreased to 5-8 per month: the exchange with 1С covers most updates automatically.
Support inquiries about size decreased by roughly three times, and conversion to order on product pages with the new chart grew more noticeably than on the rest of the catalog.
What is the difference between a size table and a size chart?
A size table is a reference of correspondences tied to a specific model: SKU, brand, scale (EU/UK/US), width, insole length. A size chart is a broader concept: a set of rules by which the catalog maps scales to each other and selects a size based on the customer's measurement.
The table answers the question "what size is this pair," while the chart answers "how do I convert my size between brands and scales."
In practice, the difference shows up in the catalog structure. A table lives as a property of a product offer: one model may have its own layout, another may inherit one from the product line.
A chart is designed at the level of an infoblock or a separate reference and links size scales, width, and last type. If these entities are mixed into a single property, then when adding a new brand or scale you will have to rewrite the product cards rather than the mapping rule.
For the customer, the difference is visible in the selection scenario. The table shows the available sizes of a specific model with an availability marker.
The chart provides a tool: entering foot length, converting to the desired scale, and a recommendation that accounts for width. Without a chart, the table remains a static image that the customer checks manually and often gets wrong.
When designing a catalog, this determines the scope of work. First we describe the scale reference and conversion rules, then we link tables to models and display them in the product card.
This way, adding a new product line or brand does not break existing cards but expands the reference. Separating the concepts at the start saves you from reworking the catalog when the assortment grows.
Common technical concerns
Before starting work, clients usually check not the table itself, but how it will coexist with an already running catalog: trade offers, stock balances, exports from 1C. Below are answers to the concerns that most often come up during the evaluation stage.
How will the size table integrate with current trade offers and stock balances?
Sizes are linked to trade offers, not to the product card as a whole. If you already have offers by color or width, we add size as another property and configure the link — existing stock balances and prices are not rebuilt from scratch, only the output logic changes.
For catalogs where sizes are stored in a separate information block, we match by external code to avoid duplicating items.
What happens when the supplier updates the size chart?
The chart is moved into a separate reference, not hardcoded into the template. An update is just loading a new export file or editing the reference: the table on the site pulls the current values without rebuilding catalog pages.
If the supplier changes the matching logic itself (for example, switches to a different scale), one matching rule is edited — the rest of the products continue to work as before.
Will the catalog load increase when the table is displayed on every card?
The table is assembled from the reference and cached at the component level: on repeated requests, a ready-made fragment is served rather than recalculating the size matching.
On catalogs with tens of thousands of items, this does not cause a noticeable increase in response time — the bottleneck remains where it was before implementation.
How will the table behave during export from 1C and in the mobile version?
Export from 1C follows the standard exchange: sizes and their matchings go into the reference in the same packages as the rest of the catalog.
On mobile, the table is restructured into a compact view with horizontal scrolling or selection by parameters — the layout does not break the card and does not require a separate page.
If you still have concerns about your specific catalog — describe how sizes are currently stored and where the export comes from, and we will get back to you with an estimate and a work plan.
Let's discuss your sizing challenge
So that developing a shoe size chart doesn't turn into a catalog overhaul, we start by breaking down the task: which product categories are affected, where the sizing data comes from, and how it should look on the product page and in the filter.
At this stage, the engineer leading the project gets involved — they ask clarifying questions about your specifics, not from a template.
Next, you receive a work estimate and an implementation plan with stages, timelines, and areas of responsibility. The plan records what we do, what's required from your side, and at what point the interim result can be reviewed.
What the task discussion includes:
- reviewing the current catalog structure and product properties that the size chart is tied to;
- clarifying data sources: manual entry, export from an accounting system, or an external reference;
- customer scenarios — size selection on the product page, filtering in the catalog, comparing models;
- checking compatibility with the current template and modules so existing pages aren't broken;
- display options: a pop-up table, a separate page, or a block inside the product page;
- a preliminary estimate of timelines and scope of work for each option;
- an implementation plan with checkpoints and the order of rollout to the live site.
The task discussion comes with no obligation: after the conversation, you're left with a clear picture — exactly what needs to be improved, in what order, and with what risks.
If the solution can be handled with the platform's standard tools, the engineer will say so directly, without pushing unnecessary custom work.
Describe your task — we'll come back with an estimate and an implementation plan.