size_type and size_system in Google Shopping: apparel sizing done properly
How size_type and size_system work in Google Shopping, covering regular, petite, plus and big-and-tall cuts, US/UK/EU size systems, and why they cut returns and mismatches.
The size attribute alone is ambiguous: a size 10 is a different garment in UK and US sizing, and a plus-cut 16 differs from a regular 16. size_system says which country's scale the size uses; size_type says which cut it is (regular, petite, plus, big and tall, maternity). Together they make apparel sizes unambiguous, which improves filtered-search matching and reduces size-driven returns.
The three-part sizing picture
| Attribute | Question it answers | Example values |
|---|---|---|
size |
What size is it? | 10, M, 32x34 |
size_system |
On whose scale? | UK, US, EU, JP, AU, BR, CN, DE, FR, IT, MEX |
size_type |
Which cut? | regular, petite, plus, big and tall, maternity, oversize |
The size value on its own (covered in colour, size, gender and age_group) is only meaningful with context. "10" is a UK 10, a US 10 (a UK 14-ish) or an EU 10 (a child's size) depending on the scale, and the same number cut for petite, regular or plus proportions is three different garments. These two attributes supply the context.
size_system: which country's scale
Set it to the scale printed on the garment's label, not the country you're selling to. A US-sized dress sold in the UK submits size: 8 with size_system: US, and Google can then present it correctly to UK shoppers, converting or labelling the size rather than letting a UK shopper read a US 8 as a UK 8 (two sizes smaller than she expects).
If omitted, Google assumes the target country's system. That default is exactly right for domestic brands and silently wrong for imports, which is why the attribute matters most for merchants selling US or EU-labelled stock into the UK, or anyone selling cross-border with one feed per country.
size_type: which cut
Accepted values:
regular: the default assumption when omitted.petite: proportioned for shorter frames.plus: plus-size cut.big and tall: the menswear extended-fit equivalent.maternity: maternity cut.oversize: deliberately oversized fit.
Up to two values can be combined where genuinely true (petite + maternity). The attribute matters because cut is a filter shoppers actively use: someone filtering the Shopping tab to plus-size dresses only sees products that declared it. A plus range submitted without size_type sits in the default regular pool: present, approved, and invisible to the exact shopper searching for it.
Why bother: matching, returns, and mismatch risk
- Filtered-search eligibility. Size, cut and system feed Shopping's apparel filters directly. Undeclared cuts and systems mean unmatched filters, which means queries you never enter (see how listings work).
- Fewer size-driven returns. Apparel's return problem is mostly a sizing-expectation problem. Every ambiguity removed before the click (right scale, right cut) is a return that doesn't happen and a margin hit avoided.
- Fewer data mismatches. If your landing page says "US sizing" and your feed implies UK sizing by omission, the offer and the page disagree in a way that confuses shoppers now and invites trouble whenever Google compares the two.
Deep dive Mapping platform size options into the three attributes
The engineering problem underneath this: almost no ecommerce platform stores size as three fields. It stores one variant option string, and merchants encode everything into it: UK 12, 12 Petite, M (EU), XL Tall, US8/EU38. Getting from those strings to clean attribute triples is a parsing job with predictable traps:
- Compound strings must be split, not passed through.
12 Petitesubmitted as thesizevalue is technically accepted (size is free-ish text) but defeats the structure: the petite half never reachessize_type, so the petite filter never matches. The mapping issize: 12,size_type: petite. - Dual-labelled stock needs one system chosen.
US8/EU38labels carry two scales; the feed should submit one size in one declared system per country feed (typically the target market's nearest label), not the raw dual string. - Consistency across the variant group. All variants under one
item_group_idshould use the same system and consistent types; a group where half the sizes parsed as UK and half defaulted is worse than either alone, because the size run stops making sense as a set. See item_group_id and variants for how the group works. - The silent-default audit. Because both attributes have defaults, errors here never appear in Diagnostics: nothing is "missing", it's just wrong. The check has to be proactive: find every product whose title, size string or product type mentions petite/plus/tall/maternity or a foreign size scale, and verify the corresponding attribute is set. That audit is trivial to automate at the feed layer and effectively never done by hand.
The payoff scales with catalogue breadth: a merchant with regular UK-cut stock loses nothing to the defaults, while an importer with mixed-cut ranges can have a third of their apparel effectively mislabelled without a single Diagnostics warning.
How this works in /tools
Enrichment parses your variant option strings into clean size, size_type and size_system values, splitting compound labels, normalising scales and keeping variant groups consistent, and writes the results to the supplemental layer, so your platform's option names stay exactly as you set them. Sizing completeness and consistency feed your Feed Health Score. For the base sizing attributes see colour, size, gender and age_group; for how size variants group into one product, see item_group_id and variants.
Frequently asked questions
What is the difference between size_type and size_system?
size_system identifies the sizing scale the size value belongs to (UK, US, EU, JP and so on). size_type identifies the garment's cut: regular, petite, plus, big and tall, maternity, or oversize. A UK plus-cut 18 submits size 18, size_system UK, size_type plus.
Are size_type and size_system required?
They're optional in most cases, defaulting to regular and the target country's system. But whenever you sell non-regular cuts or sizes labelled in a different country's scale than the one you're targeting, omitting them makes your size data wrong in practice, since Google assumes the defaults.
What are the accepted size_type values?
regular, petite, plus, big and tall, maternity, and oversize. Up to two can be combined where a garment genuinely is both, petite and maternity, for example.
Do these attributes really reduce returns?
Indirectly but measurably. Sizing confusion is the largest single driver of apparel returns, and ambiguous listings (a US-sized import shown to UK shoppers without a system label) generate exactly that confusion. Precise size data means the shopper who lands on your page ordered the garment they thought they were ordering.