ReferenceUpdated 2026-07-06

The 20 enriched fields

A reference to every product field Optimise can enrich, what each attribute is for, what Google expects in it, and where it affects your Shopping performance.

Plain-English summary

Optimise can rebuild up to 20 fields per product to match Google's specification, the identifiers, titles, categories and attributes that decide which searches you show for. This is a reference for each one: what it means, what Google wants, and why it matters. Every field is written to a supplemental layer, never back to your store.

How to read this reference

Each field below is a Google Shopping product attribute Optimise can enrich. "Google expects" is the specification requirement; "Why it matters" is what it costs you when the field is wrong or missing. Every value Optimise writes lands in the supplemental layer described in How enrichment works: your platform data is never overwritten.

Identifiers

Field What it is Google expects Why it matters
gtin The barcode number (UPC, EAN, ISBN, ITF-14) Present and valid whenever the product has a barcode; passes check-digit validation Matched products win richer placements and convert better; missing or invalid GTINs suppress visibility
mpn Manufacturer part number Submitted when there's no GTIN but there is a manufacturer Fallback identity for OEM/spare parts; helps catalog matching
brand The brand shoppers know the product by Present for all branded goods Feeds catalog matching and brand-name search eligibility
item_group_id Groups variant offers into one family Shared, stable string across a product's variants Keeps colour/size variants together; broken groups fragment performance

See GTIN, MPN and brand for the full identifier rules.

Text fields

Field What it is Google expects Why it matters
title The product name shoppers see and Google matches Up to 150 chars; key attributes front-loaded; no fluff The single biggest lever on which searches you show for
description Longer product detail Spec-compliant, policy-safe, no HTML junk or promo text Supports matching and eligibility; policy trips cause disapprovals

See Product titles that win Shopping searches for structure.

Categorisation

Field What it is Google expects Why it matters
google_product_category Google's own taxonomy value The most specific matching category, not a top-level guess Drives which auctions you enter; vague categories bleed relevance
product_type Your own category path Your store's taxonomy, as granular as you keep it Powerful for campaign segmentation and internal filtering

See Google Product Category mapping for the distinction.

Variant attributes

Field What it is Google expects Why it matters
color The variant's colour Consistent, Google-friendly value Powers attribute-filtered searches ("red midi dress")
size The variant's size Normalised, category-appropriate value Required in apparel; drives size-specific matching
size_type Cut/fit of the size e.g. regular, petite, plus, maternity Refines apparel matching
size_system Sizing standard e.g. UK, EU, US Prevents size mismatches across regions
material What it's made of The primary material Matches material-led searches; some categories expect it
pattern Visual pattern e.g. striped, floral, plain Supports pattern-led apparel and homeware searches

See Colour and size normalisation.

Audience attributes

Field What it is Google expects Why it matters
gender Intended gender male, female or unisex Required in apparel; wrong values cause disapprovals
age_group Intended age band newborn, infant, toddler, kids or adult Required in apparel; affects eligibility and matching

Custom labels

Field What it is Google expects Why it matters
custom_label_0 Your segmentation tag Free-text value of your choosing Feeds Google Ads campaign structure
custom_label_1 Your segmentation tag Free-text value e.g. margin band, price band
custom_label_2 Your segmentation tag Free-text value e.g. seasonality, lifecycle
custom_label_3 Your segmentation tag Free-text value e.g. bestseller flag
custom_label_4 Your segmentation tag Free-text value e.g. clearance/stock status

See Custom labels in Optimise for how these get populated.

Deep dive Why "up to 20" and not "always 20"

Google's specification is conditional: an attribute is only expected when the product's category or type calls for it. That's why Optimise fills up to 20 fields rather than forcing all of them onto every product.

A worked example across three products from the same store:

Product Fields Optimise fills Fields it correctly leaves Reason
A silk cocktail dress title, description, gtin, brand, google_product_category, color, size, size_type, size_system, material, pattern, gender, age_group, item_group_id, custom labels mpn Apparel demands the full audience/variant set; identity comes from GTIN, not MPN
A hardback novel title, description, gtin (from ISBN), brand, google_product_category, custom labels color, size, gender, age_group, material, pattern None of the apparel attributes apply to a book
An OEM brake pad title, description, mpn, brand, google_product_category, product_type, custom labels gtin, color, size, gender, age_group No consumer barcode exists, so MPN carries identity

Forcing an irrelevant attribute is itself a quality problem: a gender on a brake pad or a size on a novel is noise that can confuse matching. Optimise applies the fields each product's category demands and stops there. The Feed Health Score weighs completeness against what each product should have, not a flat count of 20.

The short version

The identifiers and title do the heaviest lifting on visibility; category decides which auctions you enter at all; the variant and audience attributes unlock attribute-filtered searches; custom labels turn a healthy feed into a segmentable one for bidding. Optimise fills the ones each product needs, writes them to the supplemental layer, and scores the result.

Frequently asked questions

Does Optimise fill all 20 fields on every product?

No, it fills the fields each product needs and each product's category demands. A book doesn't need gender or size; a dress does. Optimise applies the fields that are relevant and leaves the rest alone.

If I've already set a field correctly, does Optimise overwrite it?

Enrichment targets gaps and problems. Where your value already matches Google's spec, it's kept. Where it's missing, vague or malformed, an override is written to the supplemental layer, your source value is retained behind it, so nothing is lost.

Put this into practice. /tools rebuilds messy product data into Merchant Center-ready feeds. Connect a store and see your Feed Health Score in minutes.
Try /tools →