Metafields for Google Shopping
How Shopify metafields can hold the Google Shopping attributes Shopify has no native field for, GTIN, category, gender, age group, material, including namespace/key conventions and how each maps to the feed.
Several Google Shopping attributes, google_product_category, gender, age group, material and others, have no native home in Shopify. Metafields are the standard place to store them: custom fields attached to a product or variant, addressed by a namespace and key. This reference covers which metafields map to which Google attributes, where to attach them, and why maintaining them by hand across a large catalogue is harder than it looks.
Why metafields exist in this story
Shopify's built-in product fields cover the obvious attributes: title, price, vendor, barcode, weight. But Google Shopping asks for several attributes Shopify has no box for: google_product_category, gender, age_group, material, pattern and others. For apparel categories, some of these aren't optional; missing gender or age_group on clothing limits serving or gets items disapproved.
Metafields are Shopify's answer to "I need to store data the platform didn't anticipate". A metafield is a custom field attached to a product (or variant, collection, etc.), addressed by two parts:
- a namespace: a grouping label, e.g.
mm-google-shopping - a key: the field name within it, e.g.
age_group
So mm-google-shopping.age_group names one specific value on one product. Many Shopify Google-feed integrations read a conventional namespace like this, so setting the right namespace/key is what makes a metafield actually reach the feed rather than just sit on the product.
Common Shopping metafields and where they map
| Metafield (namespace.key) | Google attribute | Level | Notes |
|---|---|---|---|
mm-google-shopping.google_product_category |
google_product_category |
Product | A Google taxonomy ID or full path: see collections and category |
mm-google-shopping.gender |
gender |
Product | male / female / unisex: required in apparel |
mm-google-shopping.age_group |
age_group |
Product | newborn / infant / toddler / kids / adult |
mm-google-shopping.material |
material |
Product or variant | e.g. cotton; variant-level if material varies |
mm-google-shopping.color |
color |
Variant | Usually better sourced from the variant option |
mm-google-shopping.size |
size |
Variant | As above |
mm-google-shopping.custom_label_0–4 |
custom_label_0–4 |
Product | Free-text buckets for campaign segmentation |
mm-google-shopping.condition |
condition |
Product | new / refurbished / used |
global.harmonized_system_code |
(shipping/customs) | Variant | HS code used for cross-border shipping |
Namespaces vary between integrations: some use mm-google-shopping, some use custom or a store-specific namespace. What matters is that the pipeline reading your feed knows which namespace/key to look at for each attribute. A metafield in the wrong namespace is invisible to the feed.
Product-level vs variant-level
Attaching a metafield to the wrong level is a quiet source of bad data:
- Product-level attributes:
google_product_category,gender,age_group. These describe the whole product, so one value per product is correct. - Variant-level attributes:
gtin,color,size, sometimesmaterial. These differ per sellable unit. Store them on the product and every variant inherits one value: so all your sizes claim to be a size Small, or all your colours share one barcode.
GTIN is the sharpest example: a product-level GTIN metafield would assign one barcode to every variant, which is exactly the "one GTIN across variants" disapproval. GTINs belong on the variant (natively, in the barcode field): a metafield for it should be variant-scoped too.
Deep dive The hidden cost of hand-maintained metafields
Metafields are the accurate way to supply the no-native-home attributes: you're stating each fact explicitly rather than guessing. The catch is maintenance, and it scales badly.
Consider a 4,000-SKU apparel catalogue that needs google_product_category, gender, age_group and material populated. That's four metafields across ~1,500 products (assuming variants share the product-level ones): roughly 6,000 individual values to set correctly. Then:
- Every new product arrives with those metafields empty, so the coverage decays the moment you stop watching.
- A default is worse than a blank. Setting
gender: unisexacross the board to "fill the field" is a misrepresentation on a women's range: Google cross-references titles and images and can flag it. Blank-but-honest beats filled-but-wrong. - Category drift. A metafield holding a Google category ID becomes stale when Google revises its taxonomy (it does, periodically), and a retired category ID silently stops matching.
- Bulk edits corrupt quietly. A CSV re-import that doesn't include the metafield columns can wipe them without any error surfacing in Shopify.
This is why hand-maintained metafields work for small, stable catalogues and quietly rot on large or fast-moving ones. The alternative is to derive these attributes in the feed layer from evidence the product already carries (the title, description, images and category context) and write the result to a supplemental layer rather than back into Shopify metafields. That keeps your Shopify data untouched, fills gaps the moment a product appears, and never leaves a stale value in a namespace no one is watching. Where you do maintain metafields deliberately, /tools reads them as an input; where they're absent, it fills the gap. See how enrichment works.
How /tools handles this
/tools reads any Shopping metafields you maintain as trusted inputs: if you've set google_product_category or gender deliberately, that value is respected. Where metafields are empty (which, on most catalogues, is most of them), the missing attributes are supplied in /tools' own supplemental feed layer, derived from the product data already present. Nothing is written back into your Shopify metafields; your store data stays exactly as you left it, and the completed attributes serve through the feed. Coverage of these no-native-home attributes feeds directly into your Feed Health Score.
Frequently asked questions
What's a metafield namespace and key?
A metafield is addressed by two parts, a namespace (a grouping, like mm-google-shopping) and a key (the field name, like age_group). Together they uniquely identify the field, so mm-google-shopping.age_group is one specific value on a product.
Should metafields be on the product or the variant?
It depends on the attribute. Category, gender and age group are usually product-level. GTIN, colour and size are variant-level because they differ per sellable unit. Putting a variant-level attribute on the product means every variant inherits the same wrong value.
Do I have to fill metafields myself?
You can, per product, which is accurate but slow at scale. The alternative is deriving those attributes in the feed layer from the data you already have, titles, descriptions, images and category, so the gaps fill without hand-editing thousands of products.