Introduction
When you hear "generate the product feed yourself," you might think, "Isn't it just turning Shopify product data straight into XML?" But this is actually where the real craft lies.
EC product data and the feed specification that Google Merchant Center (GMC) demands are different worlds — different field names, different formats. The conversion rules that bridge these two worlds are what mapping design is all about.
This article explains how we thought about converting the key attributes — titles, GTINs, categories, availability — into the GMC spec.
Nailing the required attributes GMC demands
Don't drop the "required" fields first
GMC has attributes that every product must include. If one is missing, the whole product is disapproved and won't be listed. As a foundation, reliably filling in the required attributes is the starting point.
Emit one product per variant
In Google Shopping, the basic unit is one product per variant — per color, per size. Not "Jacket A," but "Jacket A / Black / Size M."
So we expand one Shopify product into as many XML blocks as there are variants. Variants born from the same parent product are bound together with item_group_id, so Google understands "these are color and size variations of the same product."
Handling identifiers and categories
Use GTIN and brand to say "what product this is"
GTIN (an international product identifier such as a JAN code) and brand are important clues for Google to match "which real-world product is this." When they're in place, matching accuracy against searches goes up.
Fetch the GTIN from the variant's barcode field
If the value has the correct digit count, set it in the gtin attribute
For products with no GTIN, set identifier_exists to false explicitly
Some products have no GTIN. In that case, the right move is not to force a value but to honestly state "no identifier exists." Stuffing in a half-baked value only invites disapproval.
Assigning google_product_category
google_product_category is Google's own product taxonomy. Using a hierarchy like "Apparel & Accessories > Clothing > Outerwear," you specify where your product belongs.
We keep rules that map from our own collections and product types to this taxonomy. When the category is appropriate, Google surfaces products according to search intent — a quiet but effective part of the work.
Avoiding format pitfalls
Price, currency, and stock-status formatting
Even the same "price" differs subtly between internal EC data and the GMC format. GMC requires a currency code alongside the price, and stock status must be one of a fixed set of values, not free text.
Price is a bare number, stock is display text like "3 left." GMC can't interpret it and disapproves
Price becomes "12000 JPY," stock is converted to in stock / out of stock from quantity. Approved smoothly
Stripping HTML and noise from descriptions
Product descriptions often contain HTML tags, and passing them straight through means the tags display literally or unwanted styling creeps in.
At the mapping stage, we strip HTML tags and tidy up excess whitespace and line breaks. GMC descriptions also have a character limit, so we trim overly long text while preserving the key points. It's mundane work, but skip it and you get an ugly listing.
Conclusion
Mapping design is a translation job that bridges two separate worlds: EC product data and the GMC spec.
- Don't drop required attributes: reliably fill id, title, price, availability, and so on
- Expand per variant and bind them with item_group_id
- Use GTIN, brand, and category to accurately convey "what product this is"
- Match formats to spec: currency notation on price, stock-status conversion, HTML stripping in descriptions
Only with this mapping as the foundation do feed caching and health checks and quality control come into their own. The big picture is in the automated product feed hub article.