Product sizing data: Build a model that travels

Product sizing often arrives as one label: M, 32, EU 42, or 500 ml. A label is not a complete product record. Systems need to know which size system produced it, what was measured, in which unit, for which sellable variant, and how the value was verified.

A durable sizing model keeps those facts separate, then maps them to each channel without changing their meaning. The result is sizing data that a storefront, Merchant Center, structured data, and AI shopping surface can read consistently.

Product sizing is four separate facts#

Treat product sizing as a group of related fields rather than one text attribute. The minimum model separates the customer-facing label, the measurement, the fit description, and the sizing system.

Add size_type when a category needs a controlled fit group, such as regular, petite, tall, plus, or maternity. Keep this field separate from a fit note. A controlled value supports filtering and feeds. A note can explain a product-specific cut.

The same pattern works outside apparel. Footwear can carry foot length and width. A ring can carry inside diameter and the brand’s ring system. A chair can carry seat height and width. The measurement point and method change by category. The separation does not.

Research from NN/G on size guides shows why the distinction matters: shoppers need local and original labels, measurements, and enough context to understand what a number means. A conversion label cannot explain whether a value describes a body, a garment, or the product itself.

Put sizing on each sellable variant#

A product group describes the family. A variant describes the item a customer can actually select, price, reserve, and add to a cart. A jacket in navy and size M needs a different variant record from the same jacket in navy and size L, even when both share a product page.

This is the same parent-versus-variant boundary used in our product variants guide. It keeps inventory, URLs, offers, and sizing facts joined to one sellable ID.

A practical variant-level field dictionary looks like this:

A measurement needs a scope. chest: 100 cm could mean a body range, a garment circumference, or a flat measurement. Store body, garment, product, or another category-approved scope. Store the method too, such as a manufacturer chart, flat lay, inside length, or measured with packaging excluded.

Here is an illustrative record for one apparel variant. The values are examples, not product claims:

{
  "product_group_id": "northline-commuter-jacket",
  "variant_id": "northline-commuter-jacket-navy-m",
  "sku": "NL-JKT-NVY-M",
  "attributes": {
    "size_label": "M",
    "size_system": "brand-Northline",
    "size_type": "regular",
    "measurements": [
      {
        "point": "chest",
        "scope": "body",
        "min_value": 96,
        "max_value": 101,
        "unit": "cm",
        "method": "brand_size_chart"
      },
      {
        "point": "body_length",
        "scope": "garment",
        "value": 72,
        "unit": "cm",
        "method": "flat_measure"
      }
    ],
    "fit_note": "Relaxed cut; designed for a mid-layer"
  },
  "provenance": {
    "source_ref": "supplier_spec:NL-JKT-v4",
    "source_type": "manufacturer_specification",
    "verified_at": "2026-09-12",
    "verification_state": "approved"
  }
}

This is a Catalog recommendation, not an industry standard. ISO 8559-1 describes anthropometric body measurements and how they can support clothing size and shape profiles. It does not provide a universal table that converts every brand’s label between countries. Use standards to define measurement concepts, then govern your own category and brand rules.

Convert physical units; map size systems separately#

Unit conversion and size mapping look similar in a spreadsheet. They are different operations and need different controls.

Physical-unit conversion is deterministic#

A physical value can be converted when the quantity and unit are known. NIST defines the standard inch as exactly 25.4 mm. For a source value of 32 inches, a normalized value is 812.8 mm:

source_value:       32
source_unit:        in
normalized_value:   812.8
normalized_unit:    mm
conversion_rule:    in_to_mm_v1

Keep the source value and unit. Store the normalized value separately. Record the conversion rule and precision. Round only when formatting a display or a destination payload, not while calculating. The NIST length guidance provides the underlying unit definitions and conversion basis.

A useful unit policy is:

1. Accept only recognized units for each measurement point.
2. Normalize into one internal unit for comparison and validation.
3. Retain the original number and unit for auditability.
4. Convert range endpoints independently.
5. Apply display rounding once, at the channel or locale boundary.

Do not run a unit formula over M, EU 42, or 32/34. Those are labels with a system, not physical quantities.

Size-system mapping is an approved interpretation#

A regional size mapping adds meaning. It may say that a brand’s source label should be displayed in a target market as another label. The result depends on the brand, category, product cut, and source chart. It is not a physical conversion.

Store mappings with their context:

source_label:       M
source_system:      brand-Northline
product_scope:      northline-commuter-jacket
 target_system:     US
 target_label:      M
mapping_basis:      approved_brand_chart
mapping_version:    northline-us-map-v2
mapping_status:     approved

Keep the original label alongside the mapped display value. Record the mapping’s scope, source, version, approval state, and effective date. If no approved mapping exists, preserve the source value and hold the regional output rather than inventing an equivalent.

NN/G notes that sizing varies by brand and that conversions are approximate. That is why a single universal conversion table is a poor source of truth. A product-specific chart, body range, or product measurement gives the system evidence it can expose without pretending that two labels are identical.

Validate sizing before publication#

Validation should run at the canonical record, variant join, and destination-output boundaries. Our product data quality guide describes completeness, validity, consistency, and freshness checks. Apply those dimensions to sizing with category-specific rules.

Do not use a generic numeric range as proof that a measurement is correct. A plausible number can still use the wrong measurement point or belong to the wrong variant. Compare against the category method and source document.

Keep a review state such as approved, needs_review, or rejected. A derived mapping or extracted measurement should carry its evidence and confidence. If the source is unclear, keep the value out of a published output until an owner resolves it.

Map variants to Merchant Center feeds#

A feed is a destination output, not the canonical sizing model. Google’s Merchant Center product data specification warns that missing or incorrect variant attributes can cause disapprovals, limited eligibility, or incorrect displays. Publish each sellable variant as its own item and use a shared group identifier to express the relationship.

Google marks size as required for apparel products in certain clothing and shoe categories and target markets, and for products available in different sizes. Its specification also requires the same item_group_id across variants while the variant values differ. Requirements depend on category and target country, so generate the feed from destination rules rather than hard-coding one global checklist.

If a size has multiple dimensions, represent the complete variant label in the destination’s allowed form. Keep the component values in your canonical record so a downstream system can still filter or explain them. A feed row should never force another system to infer whether 16/34 Tall means neck, sleeve, and fit dimensions.

Keep feed transformations versioned. A change to a size mapping should produce a reviewable diff in the affected rows, not a silent rewrite of the source record. Our product feed management guide covers the broader lifecycle of generating, validating, delivering, and monitoring channel outputs.

Map the same model to product-variant structured data#

For product pages, Google recommends grouping related variants with ProductGroup and connecting the group to Product entities. The group can declare productGroupID and variesBy; each variant can carry its own identifier, size, offer, and selected URL. The product-variant structured data documentation describes the supported single-page and multi-page patterns.

An illustrative single-page mapping looks like this:

{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "@id": "https://store.example/products/commuter-jacket#group",
  "name": "Northline commuter jacket",
  "productGroupID": "NL-JKT",
  "variesBy": [
    "https://schema.org/size",
    "https://schema.org/color"
  ],
  "hasVariant": [
    {
      "@type": "Product",
      "@id": "https://store.example/products/commuter-jacket#variant-navy-m",
      "isVariantOf": {
        "@id": "https://store.example/products/commuter-jacket#group"
      },
      "sku": "NL-JKT-NVY-M",
      "name": "Northline commuter jacket, navy, M",
      "size": "M",
      "color": "navy",
      "offers": {
        "@type": "Offer",
        "url": "https://store.example/products/commuter-jacket?variant=NL-JKT-NVY-M",
        "priceCurrency": "USD",
        "price": 148.00,
        "availability": "https://schema.org/InStock"
      }
    }
  ]
}

The values above are illustrative. In production, the offer, URL, image, availability, and identifiers must come from the current variant record. Each variant needs a unique ID. The group needs a stable group ID. For a single-page product, the base page is the group URL and the variant URL must preselect the right state. That state should show the matching image, price, availability, and add-to-cart variant.

Structured data and feed rules are separate channel outputs. Keep richer measurements and fit notes visible on the product page and in the canonical model. Add schema properties only when they describe the content a shopper can see and the vocabulary supports the value. Validate markup with the Rich Results Test and inspect a sample of rendered variant URLs after template changes.

Keep one normalized sizing layer#

Sizing data is often distributed across supplier sheets, a PIM, a storefront, and channel feeds. Each system may use a different field name or unit. Copying charts from one destination to another creates drift.

Catalog’s normalized product-data layer gives those systems one governed representation:

1. Ingest: Collect variant records, source charts, specifications, and product-page facts without losing the source reference.
2. Normalize: Separate labels, measurements, fit notes, and systems. Normalize units while retaining the originals. Resolve parent and variant IDs.
3. Validate: Apply category rules, provenance checks, mapping approvals, and destination contracts before publication.
4. Publish: Map the canonical record to Merchant Center rows, product-variant structured data, storefront content, APIs, and AI shopping surfaces.
5. Monitor: Track freshness, rejected outputs, stale mappings, and parity between the selected variant and each published representation.

This layer complements the source system. Catalog is not a size-recommendation tool and does not replace a PIM, ERP, or storefront. It keeps live, normalized product data available to the channels and builders that need machine-readable product objects. Our complete ecommerce product-data guide explains how the same layer connects source ownership, identifiers, feeds, structured data, and AI commerce.

Product sizing implementation checklist#

Use this sequence for a category launch or a cleanup of an existing catalog:

1. Define the category’s measurement points, scopes, methods, units, controlled systems, and required fields.
2. Assign a stable parent ID and unique variant ID to every sellable combination.
3. Preserve each source label and source measurement before normalizing or mapping it.
4. Store body, garment, and product measurements as different scopes.
5. Keep physical-unit conversion rules separate from regional size mappings.
6. Version every mapping and record its basis, scope, approval, and effective date.
7. Validate joins, controlled values, units, ranges, provenance, and destination payloads.
8. Render selected variant URLs and compare the page, feed row, and structured data.
9. Monitor freshness and hold outputs when a required fact or approved mapping is missing.

FAQs#

Is product sizing the same as a size-conversion table?#

No. A conversion table is one possible channel representation. Product sizing data also includes the original label, size system, measurements, scope, method, fit note, variant identity, and provenance. Keep the source facts so a destination mapping can be changed without rewriting the record.

Does the Merchant Center size field replace a measurement chart?#

No. Use size for the variant’s size value and use size_type, size_system, and other supported variant fields where they apply. Keep a measurement chart as structured canonical data and clear product-page content. A label alone cannot tell a system what was measured or how.

Should every category use the same sizing fields?#

No. Use a shared identity and provenance model, then add category extensions. Apparel may need body and garment points. Footwear may need foot length and width. Furniture may need product dimensions and clearance. The schema should be consistent enough to map, specific enough to validate, and honest about what the source provides.

When sizing facts are split across your storefront, PIM, supplier files, and feeds, see how Catalog can structure and publish the normalized product data.