item_group_id is the feed attribute that groups product variants — the different sizes, colors, or styles of one base product — so ad networks treat them as a single product a shopper can pick options from. Each variant is its own catalog item with its own ID, and a shared item_group_id ties them together.
Why variants have to be separate products#
Ad networks want one catalog item per thing a shopper can actually buy. A "Merino Crew" jumper in three sizes and two colors isn't one product to a shopper — it's six buyable things. If your feed packs all six into a single item, the network can only advertise it as one product: a shopper who searches for the medium can't be shown the medium, and an out-of-stock size can't drop out on its own.
Splitting each size or color into its own product fixes that. Every variant gets its own price, availability, image, and identifier — and when you give them all the same item_group_id, that shared value tells the network those separate items belong together, so it shows them as one product with selectable options instead of six unrelated listings. That grouping is also what lets the network rotate to whichever variant is in stock and relevant to the shopper.
What item_group_id actually does#
Think of item_group_id as a family name that every variant of the same base product carries:
- It's the same value across the whole group. Every variant of the "Merino Crew" shares one item_group_id, so the network knows they're one product.
- Each variant still needs its own unique product ID. The IDs must differ between variants; the item_group_id is what they have in common. Two variants that share an ID collide into one item — see Add missing GTINs, brands, and identifiers for how product IDs work.
- It's a recommended feed field, not a required one. Google, Meta, and TikTok all use an item_group_id attribute to group variants, but a product without one still imports — it simply won't be grouped into a variant family. So a store with no variants doesn't need it at all.
The exact rules for which attributes a network expects each variant to carry — the distinguishing attributes like size, color, pattern, or material — live in each network's own product-data spec: [VERIFY: the required variant-distinguishing attributes (size/color/pattern/material) across Google Merchant Center, Meta, and TikTok].
How Renable produces variants#
Renable turns variant data into separate products with the Split into variants rule action on your catalog's Rules tab. Point it at the column or list that holds the variants — a repeated feed element, or a single cell listing sizes or colors — and it fans one feed row out into one product per variant, each resolving its own ID, price, and availability.
Splitting — together with the per-variant ID mapping it requires — gives each variant its own unique ID, but it does not set the shared item_group_id for you. To group the variants back into one product, you map the item_group_id field [VERIFY: exact Mapping-tab label for the item_group_id field] to the value the whole family shares — typically the base product's identifier — on your catalog's Mapping tab (see Mapping your feed fields). Without that shared value you're left with separate products that have unique IDs but no group linkage, so the network shows them as unrelated listings instead of one product with options.
The full walkthrough, including how each variant gets its own stable ID and the fact that a feed can be split only once, is in Splitting variants into products. Because splitting is a rule, it stays in a draft until you Publish, like every other catalog change.
Or ask Aimée#
You don't have to set the split up by hand. Tell Aimée in plain language — "split my feed into one product per size, using the variant SKU as the ID" — and she can build the split rule and the per-variant ID mapping, then publish once you approve.
FAQ#
What's the difference between the product ID and item_group_id?
The product ID is unique to each variant — it identifies one exact buyable item. The item_group_id is shared across all variants of the same base product — it's what tells the ad network those separate items are one product with options. Every variant carries both: its own ID, and the group's item_group_id.
Do I need item_group_id if I don't sell variants?
No. item_group_id only matters when a base product comes in several variants that should be grouped. A catalog of standalone products doesn't need it, and Renable won't call a product out for missing it — it's a recommended field, not a required one. See Required vs. recommended feed fields for what "recommended" means for reach.
My feed already lists each size as its own row — do I still split?
No. Splitting is only for feeds that pack several variants into one row. If your feed already has one row per variant sharing the same variant-family id, those are already separate products and just need to reach your catalog as they are.
What that shared id is useful for is the opposite operation. A Group products rule can collect the rows that share it and either put facts about the whole family onto every variant — how many sizes exist, the family's lowest price, a list of all its colors — or reduce the family to a single product, so you advertise only the cheapest variant instead of all of them.
Related articles#
- Splitting variants into products — turn one feed row into a product per size or color.
- Grouping products — the reverse: compute values across a variant family, or keep one product per family.
- Add missing GTINs, brands, and identifiers — the unique ID each variant needs, plus GTIN, brand, and MPN.
- Fixing your feed data with rules — how rules, conditions, and actions work.