item_group_id and variant attributes
How item_group_id groups the variants of one product in Merchant Center, which attributes must differ between variants, and how the grouping affects Shopping serving.
item_group_id is the string that tells Google 'these separate offers are all one product'. Every variant is still its own offer with its own ID, price and stock, item_group_id just threads them into a family so Google can show one tile and let the shopper pick colour or size. The variants must share the group ID and differ on at least one variant attribute.
What item_group_id does
| Attribute | What it is | Example |
|---|---|---|
item_group_id |
A shared string grouping all variants of one product | DRESS-8842 |
id |
The unique ID of each individual variant offer | DRESS-8842-NAVY-10 |
In Google Shopping there are no "products with options": only flat offers, each one a single buyable thing. item_group_id is the thread that ties those offers back into one product, so Google can show a single tile and let the shopper choose colour and size on the page. Every variant is still a full offer in its own right; the group ID is what stops Google treating 24 dress variants as 24 unrelated products.
What variants share, and what differs
Shared across the group (the same on every member):
item_group_idbrand,google_product_category- the title stem and description (the variant-specific words aside)
Unique per variant (its own value on each member):
id: the offer's own identifierprice/sale_price: size-based pricing is commonavailability: the sold-out size goes out of stock while the rest keep servinglink: with the variant preselected, so the crawler lands on the right price and stockimage_link: the variant's own colour, not the shared hero shot- the variant attributes:
color,size, and where relevantsize_type,material,pattern,gender,age_group gtin: each variant's own barcode (see identifiers)
Which attributes must differ
Members of a group should differ only on the recognised variant attributes: color, size, size_type, material, pattern, age_group, gender. Two members that are identical on all of these aren't really two variants; two members that differ on something outside this list (a different product entirely) don't belong in the same group. The clean values on these attributes are what make the shopper's on-page picker work: which is why colour, size, gender and age and item_group_id are two halves of the same job.
Deep dive How grouping affects serving
Getting the grouping right, or wrong, changes how the whole family performs:
- A correct group consolidates strength. Reviews, click history and demand signals pool across the family, and Google shows the best-matching variant for each query while offering the shopper the rest on the page. One healthy tile competes with the accumulated weight of every variant behind it.
- Splitting a family fragments it. If a re-import assigns new IDs, or someone lists "same dress, new season" as a duplicate, the variants scatter across different group IDs. Google treats them as unrelated products, the performance history splits, and the variants start competing against each other in the auction: the worst of both worlds.
- Merging unrelated products suppresses the group. Throwing everything ("all mugs") under one item_group_id breaks Google's expectation that members differ only on variant attributes. It confuses serving and can suppress the whole group.
- Unstable IDs are a silent tax. Because a changed
item_group_idresets accumulated performance, using an editable value (the URL handle, the title) means every casual feed rebuild quietly costs you history. Anchor the group ID to the immutable product ID. - Missing variant attributes hollow out the group. A grouped family whose members don't carry clean
color/sizecan't present a picker and loses attribute-filtered impressions: the group exists on paper but does nothing for the shopper.
The Shopify-specific mechanics of all this (how the Product → Variants model maps onto offers, and the failure modes ranked by damage) are covered in depth in Shopify variants and item_group_id; this article is the platform-neutral attribute reference.
How this works in /tools
Enrichment derives item_group_id from the immutable product ID, ensures each variant carries its own price, stock, link, image and normalised color/size, and checks variant relationships so a broken or split group surfaces in your Feed Health Score before Google notices. For catalogues whose variant structure is itself messy (duplicate listings per colour, families split across products) the Variant Builder defines the correct relationships at the feed layer, without touching your source data. None of this overwrites what your store produces.
Frequently asked questions
What value should item_group_id be?
A stable, unique string shared by every variant of one product, ideally the immutable product ID from your store, never the title or URL handle, which can change. When the group ID changes, the group's accumulated performance history resets.
Do variants share attributes or have their own?
Both. Variants share the group-level facts (item_group_id, title stem, brand, category, description) and carry their own for the fields that differ, id, price, availability, link, image_link, and the variant attributes like color and size.
Which attributes are allowed to differ within a group?
The recognised variant attributes, color, size, size_type, material, pattern, age_group, gender. Members of a group should differ only on these. Products that differ in anything else aren't variants of one product and shouldn't share a group ID.