A shopper asks for a blue jacket in a particular size. The recommendation looks right, but the destination opens a different color and the default size. The system found the product family without preserving the purchase decision. For AI shopping teams, that gap deserves its own operating test.
The useful question is not simply whether the product exists in a catalog. It is whether the selected version survives the journey. A recommendation, destination page and basket can each look plausible while describing different things. Teams need to inspect that transition before treating a successful click as a successful handoff.
Separate the family from the selection
Google's product-variant documentation describes ProductGroup alongside individual Product entries, using properties such as hasVariant, variesBy and productGroupID. It includes approaches for products represented on one page and across multiple pages. This is documentation for Google Search, not a promise that every shopping assistant consumes the same representation. Google Search Central
Our operational interpretation starts with a simple distinction: shared identity belongs to the family; the customer's selection belongs to a specific variant. A common description can introduce the jacket. It should not replace the information needed to identify the chosen size and color.
Write down the expected handoff
Choose a representative customer request and record the selection before opening the destination. Include the market, product reference, requested attributes and the URL produced by the discovery experience. That record becomes the expected result for the test.
Then inspect what the customer actually sees. Does the page show the same selection? Is the photograph appropriate? Does the price belong to that version? Can the customer tell which attributes remain unselected? These questions are useful even before a team automates the check.
In a hypothetical test, a recommendation points to a green medium jacket but the landing page opens a blue small jacket. The page may be healthy and the link may be valid. The handoff still needs repair because the customer must reconstruct the selection.
Test changes, not just the default page
A default product page is an incomplete test of variant behavior. Open links for less prominent colors and sizes. Change a selection, return to the previous page and follow the recommendation again. Check whether the resulting state is understandable.
Include unavailable variants and combinations that do not exist. A system should not quietly substitute an available option when the request specified something else. If an alternative is offered, make the change visible and give the shopper a meaningful choice.
This is also a useful place to inspect saved links. A destination that works immediately after a search may behave differently in a new session. Record the test conditions instead of assuming that one successful journey proves every entry route works.
Connect ownership across teams
Variant errors often cross a boundary between catalog operations, site experience and discovery integration. Assign the issue according to the earliest point where the intended selection is lost. That keeps every team from fixing its own copy while the original mismatch remains.
A useful issue record includes the expected selection, observed selection, source reference, destination and time of the check. Attach enough visible evidence for another person to reproduce the problem. Avoid filling the report with unrelated customer information.
Agree on what closes the issue. A catalog edit is a change, not yet a verified customer outcome. Repeat the original journey and confirm that the repaired selection reaches the next step correctly.
Measure the handoff separately
Keep variant-preservation checks separate from traffic and sales totals. A campaign can attract visits while sending some shoppers to the wrong selection. A reliable handoff can also coexist with other reasons a shopper decides not to buy.
Start with one product family that matters commercially. Review its common selections and a few meaningful exceptions, fix the observed breaks, and repeat the same checks after changes. This produces a practical release criterion: the customer can recognize and continue with the item they asked for.
Source reviewed September 20, 2026. The workflow and hypothetical example are Aeris editorial analysis.
