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

Fictional inventory exercise: family CUP-TRAVEL has blue and sand cups, each at 350 mL and 500 mL. The following four rows are sample local identifiers, not assigned GTINs, a feed upload, or complete structured data.

In Google’s variant markup model, ProductGroup groups related Product variants using properties such as productGroupID and hasVariant. Every variant needs its own identifier in the markup, for example an actual sku or gtin. This does not mean that the group ID is the GTIN for every member.

Use stable values from the real catalog. An image redesign can change the media revision without changing which inventory option is sold. Conversely, a new saleable configuration may need its own catalog decision; changing an image filename cannot decide that. Keep missing identifiers unresolved until the catalog owner confirms them.

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 CartVisual. For each ledger row record the actual destination URL and open it in a fresh session: the expected color, capacity, image and offer must be selected without a previous shopper’s state. A single page with preselected option URLs and separate variant pages are different supported designs; do not invent a new URL scheme merely to match this example.

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. If the missing value is a barcode identifier, use the GTIN provenance check; if the URL selects the wrong image, use the selected-variant alignment check.