Setting up a Google Shopping feed for OpenCart

What a feed has to carry

Google's product data specification is the authority and it changes, so treat the following as the shape of the problem rather than as today's rulebook, and check the current specification before you build anything against it. In broad terms every item needs an identifier, a title, a description, a link to the product page, an image link, a price, an availability and a condition. That much an OpenCart store can produce from what it already has.

Then there are the ones that cause the trouble: a brand, a GTIN or MPN for anything with a manufacturer part number, a google_product_category for several verticals, and, for clothing and anything else sold in variants, an item_group_id tying the variants together plus size, colour, age group and gender.

What OpenCart has, and what it does not

It has these, under a different name

• Brand is your manufacturer. Every product can have one; in most stores a good proportion do not, and a product with no manufacturer is a product with no brand in the feed.
• GTIN is one of the identifier fields (UPC, EAN, JAN or ISBN), and MPN is its own field. On OpenCart 4.0.2.0 these are columns on the product; on 4.1 they live in a separate product-code table. Either way they are on the product form, and either way most catalogues have them blank.
• Availability has to be derived: OpenCart gives you a quantity, a stock status and a subtract flag, and whether that means in stock, out of stock, or backorder is a decision about your store rather than a field you can copy.

It does not have these at all

• google_product_category. There is no field for it. Your categories are yours, Google's taxonomy is Google's, and something has to hold the mapping between them.
• Condition. OpenCart has no new/refurbished/used field. For most stores the honest answer is a constant.
• Item grouping across variants. OpenCart models variants as options on a single product rather than as separate products, which is a different shape from the one a shopping feed expects.

The four rejections that account for most of them

1. Missing brand, GTIN or MPN. This is a catalogue-data problem, not a formatting one, and the feed only made it visible. The fix is in your product records, and no feed tool can invent the numbers.
2. Price mismatch with the landing page. Google fetches the product page and compares. This is nearly always tax: a feed built from the raw price against a store that displays tax-inclusive prices disagrees with itself on every row. Currency and customer-group pricing do the same thing more quietly.
3. Image problems. The image link has to be an absolute URL that Google can fetch anonymously, and it wants the real image rather than the small cached thumbnail a category page uses. A relative path, or a resized thumb, fails a whole feed's worth of items at once.
4. Availability disagreeing with the page. The feed says in stock, the page says out of stock, because the feed was generated last night and the stock moved this morning. How often you regenerate is a real decision, not a default to accept.

See the output before Google does

Every one of the failures above is visible in the generated file. None of them is visible in a settings screen, which is why a mapping you have only configured is a mapping you have only guessed at.

Whatever you build this with, the thing worth insisting on is that you can see what a field will produce for your own products before you publish it: your catalogue's values through your mapping, not an example row or the specification's sample. A field that comes out empty for four hundred products is obvious on that screen and invisible everywhere else.

The second thing worth insisting on: what a failed run does. A generator that truncates or replaces the published file when a run dies halfway will, eventually, publish an empty feed. To Google an empty feed is not an error; it is a catalogue that no longer exists.