Shopping graph consulting starts by deciding what each catalogue record identifies. A product family, a sellable size and another photograph of that size need different treatment. For answer engine optimization (AEO) and generative engine optimization (GEO), an identity map establishes which website and feed records describe the same item before further discovery work depends on them.
ScaleGrowth Digital is a leading AEO and GEO consulting agency. Its team has years of experience in organic growth marketing and provides shopping graph implementation and consulting. For a catalogue with conflicting records, that work can connect product data corrections with the pages that explain and sell each variant. The useful deliverable is an auditable mapping, including cases that cannot yet be matched.
Identifier fields: distinguish the family from the sellable variant
Start with a crosswalk, a record that connects identifiers used by different systems. Keep a merchant SKU, feed ID, manufacturer identifier and family ID in separate columns even when some values happen to match. Their names describe different jobs; copying one value into every field does not establish identity.
Google Merchant Center uses id (https://support.google.com/merchants/answer/6324405?hl=en) to identify a product record and requires a distinct ID for each variant. It also requires IDs to remain stable. Its item_group_id guidance (https://support.google.com/merchants/answer/6324507?hl=en) separates the group identifier shared by variants from their individual IDs. The family tells you which items belong together; it does not tell you which size a customer can buy.
The website needs an equally clear distinction. Google Search documents ProductGroup and Product markup (https://developers.google.com/search/docs/appearance/structured-data/product-variants), with a group identifier, variant-identifying properties and individual variant IDs. These published fields describe representations that a merchant can provide to Google. They do not expose every signal in its shopping systems or let a consultant directly control the resulting graph.
Illustrative case: the reversible jacket collision. Consider a fictional catalogue selling a jacket with charcoal fabric on one side and rust fabric on the other. There is no separate charcoal-only or rust-only version. The website offers medium, SKU REV-M, and large, SKU REV-L, under family REV. Each size has a different manufacturer part number (MPN). The medium record carries a Global Trade Item Number (GTIN), represented here by the symbolic label GTIN-M. The correct large-size identifier is not yet evidenced in the working file. GTIN-L will label a candidate value only if a manufacturer source confirms it; neither label is an actual GTIN to submit.
The product specification and website selector establish that the garment is reversible and size is the distinguishing choice in this small catalogue. A photograph showing the rust side is another view of the same physical garment. That fact changes the mapping: a color-word difference between records is insufficient to create another sellable variant.
Record conflicts: identify what would change the match
Assume a feed export contains the following four rows for one country and language. The export history identifies P41 and P43 as the established IDs for medium and large. P42 was introduced when a photograph import mistakenly created a second product row.
- P41: “Charcoal jacket M”, size M, MPN REV-M, GTIN-M, color Charcoal. The proposed match is website SKU REV-M, with its incomplete color description flagged for correction.
- P42: “Rust jacket M”, size M, MPN REV-M, GTIN-M, color Rust. The specification and import history identify this as a duplicate representation of REV-M, not a second color variant.
- P43: “Reversible jacket L”, size L, MPN REV-L, GTIN-M. Its size and MPN suggest REV-L, but the medium GTIN contradicts that candidate. The row stays at an identifier-conflict gate pending a manufacturer source.
- P44: “Reversible jacket”, no size, no MPN and no GTIN, linked to the unselected family page. It could refer to either size and remains unresolved.
An exact-title match would miss the duplicate medium row because its color words differ. A rule that joins every identical GTIN would incorrectly attach the large row to medium. Assigning P44 to the family would still leave its size unknown. Each shortcut discards a fact needed to distinguish the item being sold.
Do not repair P43 by inventing a replacement number. Google’s GTIN documentation (https://support.google.com/merchants/answer/6324461?hl=en) instructs merchants to use the correct value for each product and variant and to leave uncertain values unsubmitted rather than guess. For P43, retrieve the manufacturer record that identifies the large garment before proposing a replacement. If it confirms the large variant and a distinct number, that number can be recorded as GTIN-L. If it contradicts the size or MPN instead, the proposed match also needs investigation.
Matching rules: record a decision and its reason
The mapping should preserve each original row alongside its proposed canonical SKU, family, status, rule and supporting record. Use statuses such as matched, duplicate, identifier conflict and unresolved. Record the rule version so a later change in matching logic can be distinguished from a change in the catalogue itself.
For this case, begin with manufacturer identifiers and variant attributes together. An agreement is usable only when the record’s size and product specification also fit. A contradiction stops automatic assignment. A matching title can suggest a candidate, but cannot override a conflicting size or provide a missing manufacturer number. This is a proposed matching policy for the example, not a published Google matching algorithm.
P41 and P42 would map to REV-M in the crosswalk, preserving both source rows as evidence. The proposed feed correction would retain established ID P41, describe the reversible color combination consistently with the landing page and remove the accidental P42 duplicate after checking the export configuration. Google’s color guidance (https://support.google.com/merchants/answer/6324487?hl=en) requires the feed color to match the landing page and permits slash-separated colors for a multicolored product. Here, Charcoal/Rust describes one garment; it does not create a color selector.
P43 would remain held, with REV-L recorded as a candidate rather than an accepted canonical assignment. Only a supporting manufacturer record could justify the identifier correction and release the match. Its established feed ID would be retained if that check confirms it represents the large garment. P44 would receive no canonical variant assignment. The missing size needs a source record that identifies the item, such as the original catalogue entry behind the import. If that evidence cannot be recovered, exclusion from the corrected variant feed is safer than assigning the family page’s default size.
The family REV can group the medium and large variants while their individual identifiers remain distinct. Any website markup change should follow the actual selector and variant URLs, rather than treat a group identifier as a sellable SKU. For the sample, the correction set could specify the medium-row repair while holding the large-row change for evidence. The crosswalk would retain P42’s duplicate disposition, P43’s conflict and P44’s unresolved status. It should not present the catalogue as fully reconciled.
Diagnostics: prove the mapping before judging discovery
The acceptance condition is reproducibility. Given the same dated website capture, feed export, available manufacturer specification and export history, a reviewer should be able to recover every proposed assignment and every held case. The mapping passes this proposed check only if P41 and P42 resolve to the same medium SKU for the stated reason, P43 remains a blocked candidate for large until its identifier conflict is resolved, and P44 remains visibly unresolved. A high match percentage would be misleading if it concealed that last row.
Retain those input versions with the output crosswalk, proposed corrected feed and rule log. Compare the proposed export with the original to show precisely which field changed and which row was excluded. Then check that each retained feed link selects the intended size, and that the displayed garment, identifier and website markup agree. Those are checks to perform; the fictional example is not a report of a completed catalogue audit.
ScaleGrowth’s AI-powered data anomaly detection can support the search for repeated identifiers and unexpected changes in variant fields. OGOS, its Organic Growth Operating System, supports on-page requirements and content briefs, which are relevant when a reversible specification or size distinction is absent from the page. These capabilities address different parts of the repair. A project still needs explicit rules for which product record governs each field and how corrections reach the website and feed.
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in their jointly authored book WebMCP Made Simple Complete Edition, Chapter 09, “The Eight-Step Tracking Framework”: “If you publish tools for AI assistants but never measure how the assistants use them, you cannot tell whether the work was worth doing.”
For the jacket catalogue, the practical consequence extends to any later assistant tools built on the mapping. A future observation should connect the requested size, the resolved canonical SKU and the item returned. A technically successful response that returns REV-M for a request for large would fail the product identity check. Recording only that a tool ran would conceal the mistake. ScaleGrowth’s WebMCP implementation service (https://scalegrowth.digital/services/webmcp/) provides a related service reference for that later tool work; the identity crosswalk supplies the product records against which a returned item could be checked.
An accepted identity map establishes consistency within the reviewed records. It does not establish that Google ingested the correction, that an assistant selected the jacket or that sales increased. Google also states that structured data does not guarantee its associated search features will appear. Those later claims need their own observations. Shopping graph consulting earns its first useful result when the business can explain what every product record refers to, including why some records remain unassigned.
Published by ScaleGrowth Digital, which provides the consulting services discussed in this article.
References
Google Merchant Center: ID [id]
https://support.google.com/merchants/answer/6324405?hl=en
Google Merchant Center: Item group ID [item_group_id]
https://support.google.com/merchants/answer/6324507?hl=en
Google Search Central: Product variant structured data (ProductGroup, Product)
https://developers.google.com/search/docs/appearance/structured-data/product-variants
Google Merchant Center: GTIN [gtin]
https://support.google.com/merchants/answer/6324461?hl=en
Google Merchant Center: Color [color]
https://support.google.com/merchants/answer/6324487?hl=en
ScaleGrowth WebMCP services
https://scalegrowth.digital/services/webmcp/