Variants and item_group_id

A shirt in four colours and six sizes is twenty-four rows in the feed and one product to a buyer. Getting Google to agree with the buyer is what item_group_id is for, and doing it wrong is expensive in a way that is hard to see.

How variants work

Each buyable variant is its own item with its own id, its own price, its own availability and, importantly, its own image. What ties them together is a shared item_group_id, plus the attributes that distinguish them: colour, size, material, pattern, age group, gender.

What goes wrong

• No item_group_id. Twenty-four unrelated products, competing against each other in the same auction, splitting performance data twenty-four ways.
• Group id with no differentiating attributes. Google cannot tell the variants apart and may treat them as duplicates.
• Shared images across colours. The blue variant shows the red photograph, which hurts conversion and risks an accuracy disapproval.
• Unstable ids. Regenerating variant ids on every catalogue export destroys the performance history of every variant, every time.
• Only the parent submitted. A single row for "shirt" with no sizes cannot answer a size-filtered query at all.

Should every variant be submitted

Generally yes. Variant-level submission is what lets a buyer filtering for "size 42" find you at all, and it is what makes out-of-stock handling honest, since one sold-out size does not take the whole product down.

The exception is catalogues where variants are numerous and near-identical in a way buyers do not filter on. Submitting every one then adds feed weight and reporting noise without adding queries you can win.

Reporting with variants

Per-product reporting on a variant catalogue is per variant, which makes category and item-group aggregation essential before drawing conclusions. A product that looks unprofitable at variant level is often profitable at group level, with the volume concentrated in two sizes.