You added a custom.color metafield to every product in Shopify. You added custom.material, custom.age_group, custom.gender, custom.size, and custom.gtin while you were at it. You connected the Shopify Google channel, waited for the next sync, opened Google Merchant Center, and the color attribute on every product is still empty. Same for material, age_group, gender, and size. The metafields are sitting in Shopify, untouched, doing nothing for your Shopping ads.
This is one of the most common Shopify→GMC issues, and it is structural. Shopify metafields are not on the list of fields Shopify's own Google channel automatically sends to Google. Even when the field name in your Shopify metafield matches the Google Merchant Center attribute name exactly, no mapping happens unless you explicitly configure one — and the configuration surface for that is small, hidden, and limited.
This post covers what Shopify metafields are, why GMC doesn't auto-map them, the six mappings that cover most stores, the manual approach (and where it stops), the automated approach with a feed tool, and the value-vocabulary mistakes that get products disapproved even after the mapping is in place.
TL;DR
- Shopify metafields don't auto-map to GMC attributes. Shopify's native Google channel maps a fixed list of standard fields and ignores most of your
custom.*namespace. - The six metafields worth mapping first are
color,material,age_group,gender,size, andgtin. - Manual mapping via the Shopify Google channel works for a small set of attributes but offers no fallbacks, no value translation, and one mapping per attribute.
- Value vocabularies are strict:
genderismale/female/unisexonly;age_groupisnewborn/infant/toddler/kids/adult. "Mens" or "Kids 3-5" fail. - A feed tool replaces the manual mapping with configurable templates that translate values, support fallbacks, and validate before submission.
What Shopify metafields are
Shopify metafields are custom fields you attach to products, variants, or other Shopify objects. They store data that doesn't fit Shopify's built-in fields — material composition, country of origin, supplier SKUs, custom warranty terms.
A metafield is identified by namespace + key, like custom.color. The namespace is usually custom for fields you defined, or a vendor namespace like mm-google-shopping for app-managed fields. Each metafield has a type (single_line_text_field, list.single_line_text_field, metaobject_reference, boolean, etc.). You manage them under Settings > Custom data in the Shopify admin.
Stores use metafields instead of stuffing data into the description because metafields are queryable, filterable, and (in theory) syncable to external channels. The "in theory" is the catch.
Why GMC doesn't auto-map metafields
Google Merchant Center has its own product data specification — a list of attributes like id, title, description, link, image_link, availability, price, gtin, mpn, brand, color, size, gender, age_group, material, pattern, condition, and so on. Google publishes the full list in the product data specification.
Shopify's Google & YouTube channel — the official integration — maps a fixed set of Shopify product fields to GMC attributes. The defaults look something like this:
| Shopify field | GMC attribute |
|---|---|
product.title | title |
product.body_html | description (HTML stripped) |
product.handle | link (combined with store URL) |
product.vendor | brand |
product.product_type | product_type |
variant.id | id |
variant.price | price |
variant.compare_at_price | sale_price |
variant.barcode | gtin |
variant.sku | mpn |
variant.image | image_link |
variant.inventory_quantity | availability |
Notice what's not in that list: anything in your custom.* namespace. The default mapping covers Shopify's built-in fields. Metafields are a separate layer the channel mostly ignores until you tell it not to.
The historical reason: Shopify added metafields years before they added the metafields-to-Google-attributes UI. Stores that pre-date that UI are on a sync path where their custom data is invisible to Google. Stores that adopt the UI hit the limits of what it can do.
The six metafield mappings that matter
If you sell apparel, accessories, or any variant-rich category, these six are the high-value mappings. Get these right and the rest is incremental.
| Shopify metafield | GMC attribute | Required for | Notes |
|---|---|---|---|
custom.color | color | Apparel variants | Each variant; comma-separated for multi-color products |
custom.material | material | Apparel, furniture | Single value or comma-separated; max 200 chars |
custom.age_group | age_group | Apparel | Must be one of newborn, infant, toddler, kids, adult |
custom.gender | gender | Apparel | Must be one of male, female, unisex |
custom.size | size | Apparel, footwear | Free-text but pairs best with size_type and size_system |
custom.gtin | gtin | Branded products | UPC, EAN, JAN, or ISBN; check digit must validate |
gtin is on this list because many merchants store the barcode in a metafield rather than the standard variant.barcode field — usually because they imported from another platform or because the barcode lives at the product level, not the variant level. If your barcodes are in a metafield, the default Shopify→Google channel won't pick them up; you need an explicit mapping.
Manual approach: the Shopify Google channel
Shopify's Google & YouTube channel has a metafield mapping feature, but it's narrow. Here's what it can do and what it can't.
What it does
In the Google channel app, navigate to Settings > Product feed settings > Custom attributes (the exact path moves around; this is the 2026 placement). You'll see a list of supported Google attributes with a dropdown for each, letting you point one Shopify metafield at one Google attribute.
The supported attributes typically include:
colorsizegenderage_groupmaterialpatterngtin
For each, you select a metafield from your store's metafield definitions. The channel then includes that metafield's value in the feed it sends to Google.
What it doesn't do
- No fallbacks. If
custom.coloris empty on a variant, the field is empty in the feed. You can't say "usecustom.colorif set, otherwise pull from variant option 1." - No transformations. If your metafield stores
Mand Google wantsMedium, you have to fix it at the source. Same forgender: if your store storesMensand Google requiresmale, the channel sendsMensand Google rejects the product. - No metafield-to-multiple-attributes. You can map
custom.colortocolor, but you can't also map a parsed substring ofcustom.colorto a different attribute. - One metafield per attribute. If half your products store color in
custom.colorand the other half (an older import) store it inlegacy.product_color, you can't union them. - Variant metafields are partly supported. Product-level metafields work cleanly. Variant-level metafields are supported in newer versions of the channel but with caveats — some metafield types (metaobject references in particular) may not flatten correctly.
- Custom attributes (
custom_label_0throughcustom_label_4) for ad campaign segmentation are not exposed through the channel UI; you have to use a supplemental feed or a third-party tool.
For a store with clean, complete metafield data and Google-compliant values already at the source, the native Shopify channel is enough. For everyone else — and "everyone else" includes most stores with imported catalogs, multi-language stores, and stores with mixed data quality — the manual approach hits a ceiling fast.
Automated approach: smart-template field mapping
A dedicated feed tool replaces the fixed Shopify→Google mapping with a configurable layer that knows about both schemas. SnowPipe uses what we call a smart template: a default mapping that handles the common case automatically, with a visual mapper for the cases that need overrides.
For Shopify→GMC, the smart template applies the standard mappings (title, description, price, availability, image, etc.) and then runs through a metafield resolution step:
- Read the Shopify metafield definitions from your store's GraphQL schema.
- Suggest a default mapping for any metafield whose name matches a known GMC attribute.
custom.color→color,custom.material→material, and so on. - Apply value translation rules for attributes with controlled vocabularies (
gender,age_group,availability,condition). - Validate the resulting feed before submission against the Google product data spec — flagging missing required attributes, invalid GTINs, value-vocabulary violations.
The mapping is configurable per pipeline. If you have an apparel store where custom.gender_full stores values like Mens / Womens / Unisex Adults, you set up a translation rule:
"Mens" -> "male"
"Womens" -> "female"
"Unisex Adults" -> "unisex"
"Kids" -> "unisex" # Google's `gender` doesn't accept "kids"; pair with age_group instead
You can also build fallbacks: use custom.color if set, else parse the variant's option 1 value, else fall back to a default. The same applies to GTIN: read custom.gtin first, then fall back to variant.barcode, then mark identifier_exists: false if both are empty.
This is what stops you from playing whack-a-mole with disapprovals every time GMC tightens a vocabulary or adds a new required attribute.
Value vocabulary traps
Even with the right mapping, the values themselves have to match what Google expects. Five attributes have controlled vocabularies that trip people up.
gender: male / female / unisex
That's the entire list. Mens, Men's, Women's, Boys, Girls, Kids — all rejected. Unisex works. Lowercase is required.
If your store uses Mens / Womens / Boys / Girls, you need either to clean the data at the source or set up a translation rule. For Boys / Girls, the right answer is to pair gender: male (or female) with age_group: kids — Google models that combination explicitly.
age_group: newborn / infant / toddler / kids / adult
These are the only valid values. The Google age_group spec defines age ranges: newborn is 0-3 months, infant is 3-12 months, toddler is 1-5 years, kids is 5-13 years, adult is 13+. Custom buckets like Kids 3-5 or Junior are not valid.
size: free-text but pair with size_system
size itself is free-text — XS, Small, 38, EU 42, 7.5 all pass. But for apparel and footwear, Google expects you to pair size with size_system (US, UK, EU, JP, etc.) and ideally size_type (regular, petite, plus, tall, maternity). Without them, products show to the wrong audience.
color: comma-separated, primary first
Black, Navy, Olive for single colors. Black/White, Red/Blue for multi-color (max three values, 100 chars total). Avoid marketing names like Midnight unless you pair them with the canonical color: Midnight (Black) works; Midnight alone gets ranked poorly. See the color spec.
material: no marketing terms
Cotton, Polyester, 100% Merino Wool, Cotton/Spandex blend — valid. Soft, Premium, Luxurious — not material, flagged.
Required vs optional attributes
Not every metafield needs mapping. Google's spec splits attributes into three tiers:
- Required.
id,title,description,link,image_link,availability,price. None of these typically come from metafields. - Required for specific products.
gtin,mpn,brand; for apparel:color,size,gender,age_group,item_group_id. These are the metafields most often worth mapping. - Recommended.
material,pattern,multipack,is_bundle. Improves filter coverage but isn't enforced.
A reasonable order: cover the required-for-apparel attributes first (color, size, gender, age_group), then gtin if your barcodes live in metafields, then material and pattern for filter exposure. Skip the recommended attributes until the required ones are clean.
Common pitfalls
- Storing values in the wrong type. A
metaobject_referencemetafield doesn't serialize to a string the way Google expects. Usesingle_line_text_field(orlist.single_line_text_fieldfor multi-value) for fields you plan to send to Google. - Mixing variant-level and product-level metafields. Color and size are usually variant-level; material and gender are usually product-level. If your store has color stored at the product level and Google sees the same color for every variant, that's a data-model mismatch, not a mapping bug.
- Empty strings vs missing. A metafield set to
""is different from a metafield that doesn't exist. Some sync tools treat them the same and pass an empty value to Google, which gets disapproved. Validate that your metafields are either filled in or absent. - Stale data from a manual import. If you imported from another platform, your metafields may have inconsistent casing (
BlackvsblackvsBLACK), trailing whitespace, or non-Latin characters. Normalize before mapping. - Duplicate mapping with the native Shopify channel still on. If you run both the Shopify Google channel and a third-party tool against the same Merchant Center account, you can get conflicting data. Pick one writer per destination.
Summary
Shopify metafields are powerful for storing product data that doesn't fit Shopify's built-in fields, but Google Merchant Center doesn't auto-map them. The default Shopify Google channel covers about a dozen standard fields and exposes a narrow UI for mapping a small set of metafields to GMC attributes. For most stores, that UI is enough only if your metafield data is already clean, consistently typed, and uses Google's controlled vocabularies.
For everything else — value translation, fallbacks, multi-source unification, validation before submission — a feed tool with smart-template mapping replaces the manual configuration with a layer that understands both schemas and applies the rules automatically.
The six metafield mappings that pay back the fastest are color, material, age_group, gender, size, and gtin. Get those right and the apparel side of your catalog stops generating new disapprovals. Add pattern and a few custom_label_* for ad segmentation and you're past the point where the bottleneck is data; from there it's about ad performance, not feed health.
Stop manually fixing Shopify metafield drift to GMC? Try SnowPipe free — connect your store and get accurate Google/Facebook syncs in minutes. Or, book a 15-min demo and I'll walk you through your specific setup.