Mapping Product Data to the Feed Specification

How to decide the rules that turn product names, GTINs, categories, and stock status into a format Google can read

Data MappingGTINProduct AttributesCategoryShopifyGoogle Merchant Center
8 min read

Introduction

"Just hand your product data to Google" sounds like a simple job. Once you actually start, it turns out to be the part of automated feed generation that takes the most time.

The product data an EC site holds and the fields Google Merchant Center (GMC for short — the console where you register product information with Google) expects don't line up, either in naming or in formatting. Take "price": our side holds a bare number, while GMC wants the currency unit attached. Working through that mismatch field by field is what mapping design is.

This article covers how we thought about converting the main fields — product name, identification number, category, stock status — into GMC's format. There are no programming details here. What matters is the decision behind each line: which piece of our data goes into which of Google's fields.

Don't leave a single required field empty

One missing field takes the whole product off the listing

GMC has fields that every product must include. Leave even one of them blank and the product is disapproved — it appears neither in the Shopping panel nor in free listings. However carefully the rest of the fields are filled in, the whole product drops out.

So mapping starts with getting the required fields reliably filled. Before any clever refinements, this is the part to lock down. The table below shows what GMC asks for and which of our data we assigned to it.

On the left, what Google wants; on the right, what we can supply. Deciding that table row by row is what mapping design actually consists of.

Each colour and size goes out as its own item

Google Shopping treats every variation — each colour, each size — as a separate product. Not "Jacket A" but "Jacket A / Black / Size M." That level of detail matches how people search: they're looking for one specific item with a photo and a size attached.

So each product on our side is expanded into as many feed entries as it has variations. A product in 3 colours and 4 sizes becomes 12 entries. That expansion is exactly why the catalogue reaches several thousand SKUs — the unit you get when you count down to individual colours and sizes.

Tell Google those 12 entries are the same product

Listed on their own, though, those 12 entries look like 12 unrelated products. So variations born from the same parent product all carry a shared marker, item_group_id, that ties them together.

With that in place, Google understands they're colour and size variations of one product. That's why search results can show colour options side by side, or surface a different colour when one sells out. It's an unglamorous field, but it visibly changes how the listing behaves.

Telling Google exactly which product this is

Identification numbers and brand names are the matching clues

A GTIN (an international identification number, such as the barcode printed on the packaging) and a brand name are what Google uses to work out which real-world product it's looking at. With both in place, searches from people looking for that product land on it much more reliably.

Without those clues, Google is left judging from the text of the product name alone, and matching accuracy drops. It's a small field in the product record, but it makes a measurable difference to how the listing performs.

When there's no number, say so honestly

Not every product has a GTIN. Own-brand items, or products whose barcodes were never registered, often don't.

How the identification number is handled
Check the barcode field

Read the GTIN from the record for that colour and size

Pass it if the digits check out

If the value has a valid digit count, set it in the GTIN field

Otherwise declare it missing

For products with no number, state explicitly that no identifier exists

Pass the number if you have it; declare its absence if you don't. Keeping it to those two options is the point.

Leaving the field blank, or filling in something that looks plausible, invites disapproval instead. Saying "we don't know" gets through review far more smoothly than guessing.

Fitting products into Google's category taxonomy

Google maintains its own product category taxonomy. Using a hierarchy such as "Apparel & Accessories > Clothing > Outerwear," you state where each of your products belongs.

We keep a set of rules that map from our own collections and product types into that taxonomy. When the category is right, Google can surface products according to what the searcher meant. A feed will pass review with this field empty, but it changes which searches you show up in, so it's worth filling.

Closing the gaps in formatting

Price and stock status have to be rewritten to a fixed form

Even a field as basic as "price" is formatted differently in an EC system than in GMC. GMC wants a currency code alongside the number, and stock status has to be one of a fixed set of values rather than free text.

Passing data as-is vs. formatting it to spec
BEFORE
Raw EC data

Price is a bare number and stock is display copy like "only 3 left." GMC can't interpret it, so the product is disapproved

AFTER
Formatted to GMC's spec

Price becomes "12000 JPY" and the stock count becomes in stock / out of stock. It passes review as-is

The point being that what a person reads on screen and what a machine reads from a file are two different things. The feed carries the second kind.

Strip styling tags and stray whitespace from descriptions

Product descriptions usually carry styling tags so they look right on the site. Pass those through unchanged and the tag text itself shows up in Google's display.

So at the mapping stage we remove styling tags and tidy up runs of spaces and line breaks. GMC also caps description length, so anything too long is trimmed while keeping the key points near the front. Fiddly work, but skip it and the listing visibly suffers.

Conversion rules get refined against real data

Try to finish the conversion rules on paper and you will miss things. Look through a few hundred real product records and you'll always find product names written in an unexpected style, prices with a unit baked into the text, or an empty category.

So we built a first feed with straightforward rules, looked at what came out, and added the exceptions from there. Even without an engineering background, describing a conversion rule in plain words to an AI agent (a development assistant you direct through conversation) and having it adjust the implementation keeps that loop short. The rules themselves aren't complicated logic — once the decision is made, turning it into something that runs is the easy half.

Summary

Mapping design is a translation job between two systems that write things differently: the EC site's product data and GMC's specification.

  • Don't drop required fields: one blank field takes the whole product off the listing
  • Expand per colour and size, then tie them together so Google knows they're one product
  • Use identification numbers, brand, and category to say exactly which product this is — and declare honestly when a number doesn't exist
  • Match the formatting: currency on the price, converted stock status, styling tags stripped from descriptions

Only once this is settled do feed caching and health checks and quality control start to mean anything. The whole flow is laid out in automated product feeds.