item_group_id

Without `item_group_id`, every variant is a separate item in the channel's view, competing for impressions independently. Five blue dresses, five red dresses, five green dresses — fifteen items competing for the impression slot when really they should be one item with fifteen variants. The user experience is broken too: searching "blue dress" returns five duplicate-looking tiles from the same product family, which suppresses click-through across all of them because users discount listings that look duplicated.

The required structure: all variants under one `item_group_id`, each with its own unique `id`, all sharing the same `title` (with variant attributes differing), the same `brand`, the same `google_product_category`. Each variant differs on at least one of: colour, size, material, pattern, age_group, gender. Different products with similar names — a t-shirt and a long-sleeve t-shirt — are not variants and need separate `item_group_id` values. The rule of thumb: if a customer would consider these the "same product" with different options at checkout, they're variants. If they'd consider them different products, they're not.

For apparel especially, getting this right is the difference between a catalog that performs well and one that just exists. Channels reward correctly-grouped variants with better placement and lower CPCs because grouped variants signal a well-managed catalog. Ungrouped variants signal data quality issues even when each individual item is fine. The performance lift from correct variant grouping in apparel catalogs typically runs 15-30% on conversion rate alone.

Within a variant group, channels pick which variant to surface per impression based on the user's signals — past purchases, demographics, search history, regional preferences. A medium blue dress is more likely to be shown to a user whose history suggests medium sizes; the same item_group serves all variants but picks the right one per impression. This is why ungrouping variants destroys performance: you forfeit the variant-selection intelligence and replace it with random first-listed-wins behaviour.

The image-per-variant question matters. Best practice is each variant has its own image_link showing that specific variant's colour or style — the medium blue dress's image_link is a blue dress, not a generic dress. Falling back to one shared image across variants is accepted but suppresses conversion noticeably (typically 15-25% drop in apparel and home goods) because customers see "blue dress" but the image shows red. Variant-specific imagery is one of the higher-ROI investments for variant-heavy catalogs.

For Amazon, parent_sku is the equivalent of item_group_id. The relationship is the same: child SKUs share a parent SKU; the parent has its own ASIN (the "group ASIN" that's the public product page URL); each child has its own ASIN nested under the parent. Amazon's variation themes (Size-Colour, Size-Colour-Material) dictate which attributes vary across the children. Mixed themes within one parent fail validation.

The mistake that catches catalogs migrating from one platform to another: variant relationships in the source platform don't always survive feed export. A Shopify catalog with proper variant relationships might export to a feed that flattens them — each variant becomes a top-level item with no item_group_id. The fix is at the feed-generation step: preserve the variant hierarchy and translate it into item_group_id correctly. Many feed tools handle this automatically for major platforms; custom integrations sometimes miss it.

The bundle / multipack distinction is sometimes confused with variant grouping. A six-pack of socks is not six variants of one sock — it's one product (the six-pack) declared via multipack: 6. A gift set with shampoo + conditioner + soap is not three variants — it's one bundle declared via is_bundle: true. Item_group_id is specifically for size/colour/material variants of one underlying product, not for bundled compositions.