Introduction
Showing a size chart on a product page is something every EC site does. The hard part is deciding which size chart to show for which product. Jackets and pants need different charts, men's and women's items differ again, and then limited-edition models come along needing a dedicated chart even though they sit in an ordinary category.
Assigning charts by hand, product by product, means more missed settings and more mistakes as the catalog grows. So we built a set of rules — selection logic — that determines the right size chart automatically from product information.
This article walks through what information that logic uses and in what order it makes its decisions. By the end, you should have the full picture of the approach: handle normal products with bulk rules, and override only the special ones with exceptions.
The Product Information Used for Matching
Pulled from Shopify metafields
The selection logic reads its product information from Shopify metafields (extra data fields you can attach to each product). Enter the category and gender when registering a product, and that same data becomes the raw material for size chart matching — no separate setup needed.
The top three fields (category, type, gender) drive the standard matching, while the bottom two (handle and SKU) exist for pinpointing exceptional products individually.
Why the matching data lives with the product
Because chart assignments derive from the product's own data rather than a separate management sheet, the correct size chart appears the moment a product is added. Registering the product is the setup. That single idea is what removes most of the operational workload.
Four Priority Levels of Matching
Exceptions first, standard rules after
To handle special products gracefully, matching runs through the following priority order: individually specified exceptions are checked first, and only if none apply does the standard mapping table decide.
In one sentence: the system searches in the order of individual overrides → standard rules → shared charts, and uses the first chart it finds.
Why exceptions come first
If the standard rules ran first, a limited-edition model would end up with the generic jacket chart. Putting exceptions at the top makes the operating model work: automatic by default, manually overridden only where it matters.
Each Priority Level in Detail
1. Per-product exceptions (highest priority)
A dedicated size chart is assigned to a specific product URL (handle). This is for limited editions, collaboration items, and other products the normal rules can't cover.
Typical cases: a limited racing suit that needs its own measurement table, or a collaboration product whose sizing follows the partner brand's standard. These products are few in number, so specifying them one at a time is no real burden.
2. Per-SKU exceptions
A dedicated size chart is assigned to a specific SKU (product code). This handles cases where, within the same product family, only some variants use different sizing.
Examples include variants made to overseas specifications for certain sizes only, or products whose sizing system changed after a renewal. This layer catches the "only part of this product is different" cases that per-product exceptions can't express.
3. The standard mapping table
The combination of category + item type + gender determines the size chart. The vast majority of products are handled by this rule.
As the table shows, each combination — "outerwear jacket for men gets this chart" — is a single row. Keep this table maintained, and new products slot into existing rows automatically.
4. Fallback to the unisex chart
If no chart matches the specified gender, the system swaps the gender for "unisex" and tries once more. Categories like cycling gear are often made unisex, so separate men's and women's charts may simply not exist.
For example, if "cycling + jacket + men" finds nothing, "cycling + jacket + unisex" is tried next. This safety net means the mapping table doesn't have to cover every combination to avoid display gaps.
When Nothing Matches
If all four levels come up empty, the product page hides the size chart button entirely. For products with no size to choose — accessories, parts — this is exactly the right behavior.
Treating "no match" as "a product that doesn't need sizing," rather than as an error, means there's no pressure to force a chart onto every product, and mapping table maintenance stays focused on the products that genuinely need it.
Summary
The size chart selection logic works through four priority levels: per-product exceptions → per-SKU exceptions → the standard mapping table → the unisex fallback. Ordinary products are handled in bulk by the table, and only special products are overridden with exceptions. With this structure, the catalog can keep growing without adding setup work, while size chart display stays accurate.
How the data is stored and how assignments are changed from the admin screen are covered in the companion articles.