Size

In a product feed, size is the attribute that records which size of an item a given row represents, sent as g:size in XML or a size column in a CSV feed to Google Shopping, Meta Catalog, and marketplace integrations. It exists to let one physical product with multiple size options appear to shoppers as a single listing with size choices, while still letting each size carry its own price, stock level, and identifier behind the scenes. Unlike a dimension field, size here is almost always a short label — a letter, a number, or a measurement string — rather than a full spec sheet entry.

Why it matters

Without a size value, a platform has no reliable way to group a run of otherwise-identical rows into one buyable listing with a size selector, so shoppers end up seeing five separate, near-duplicate results instead of one product with options — a confusing experience that also splits review counts and click data across listings. Google Merchant Center requires size on Apparel & Accessories items whenever the product comes in more than one size and item_group_id is used to link them; get the format inconsistent between variants (mixing "M" with "Medium" on a sibling row, for instance) and Google may fail to merge them correctly or flag the group. On the ad side, missing size data blocks the size-filtering and size-based retargeting that Google and Meta both support, which tends to depress click-through rate for exactly the shoppers who abandoned a cart over a sizing question.

How it works

Size accepts free text, so a clothing brand might use "S," "M," "L," a shoe brand might use "9," "9.5," "10," and a pants brand might use a waist-and-inseam string like "32x34." Google also supports two companion fields for cases where size alone is ambiguous: size_type (regular, petite, plus, big and tall, maternity) and size_system (US, UK, EU, and other regional standards), both optional but recommended whenever a retailer sells across markets with different sizing conventions. Size is one of the attributes Google explicitly allows as a variant-defining dimension alongside color, pattern, material, gender, and age group, meaning it's a valid — and for apparel, usually necessary — reason to give two rows the same item_group_id while keeping them as distinct, separately purchasable entries.

Example

<item>
  <g:id>TEE-8820-S</g:id>
  <title>Merino Wool Base Layer Tee - Graphite, S</title>
  <link>https://example-shop.com/products/merino-base-layer-graphite-s</link>
  <g:item_group_id>TEE-8820</g:item_group_id>
  <g:size>S</g:size>
  <g:color>Graphite</g:color>
  <g:price>54.00 USD</g:price>
  <g:availability>in stock</g:availability>
</item>
<item>
  <g:id>TEE-8820-L</g:id>
  <title>Merino Wool Base Layer Tee - Graphite, L</title>
  <link>https://example-shop.com/products/merino-base-layer-graphite-l</link>
  <g:item_group_id>TEE-8820</g:item_group_id>
  <g:size>L</g:size>
  <g:color>Graphite</g:color>
  <g:price>54.00 USD</g:price>
  <g:availability>out of stock</g:availability>
</item>

Notice the two rows differ only in g:size, g:id, and availability — the shared item_group_id is what lets a platform show one product page with a size picker, while quietly marking the large as sold out.

Related Concepts

Size usually shows up on the same row as color, and both need a consistently applied item group ID before a platform will treat differently-sized rows as one variant set rather than separate products competing against each other in search results. For a deeper look at restructuring a catalog around size and color variants without fragmenting performance data, see Winning with Variants: How to Structure Product Feeds for More Conversions.