Is my product-family ID the same thing as each variant SKU?

Map what the buyer can purchase

A fictional store sells the same travel cup in blue and sand, each in two capacities. Write four saleable options before creating any image metadata. The travel-cup family can have one group identifier, while each option retains its own SKU and approved picture. Reusing the blue-small SKU for the entire family makes later media and offer mapping ambiguous.

Google documents ProductGroup relationships for product variants. The practical ledger below is our editorial method for preparing those relationships; it is not a feed upload format or a complete structured-data example.

Build the identity ledger

Do not invent commercial identifiers to fill empty cells. Use your actual inventory system’s stable values. A family ID should survive an image redesign, while a new image file may need a new revision reference. Neither identifier can be inferred reliably from a rendered label.

Check the page and offer relationship

Open each intended option from its link and confirm the selected color, capacity, image and offer correspond. A valid group relationship does not excuse an incorrect variant destination. Give the implementation team the actual URL strategy and ask them to validate its markup against Google’s current examples. Theme and feed changes happen in your store, outside Itemlume.

Keep shared claims at family level only when they are true of every member. A feature available only on the large cup belongs to that variant’s record.

Use the map during creative approval

Attach the variant SKU to each generated candidate before publication. Compare it with the source photograph and the selected page, not merely the family name. If the image shows a blue 500 ml cup, reject it for the blue 350 ml option even when the style matches. This prevents one attractive family image from silently becoming evidence for all variants.