Illustrative review summary
The synthetic data contains three issue classes: links that open the default variant, stale sale prices and inconsistent grouping. The table separates row-level patterns from manual page observations. The counts do not predict what a real store’s diagnostic would find.
| Finding | Scope of evidence | Suggested priority |
|---|---|---|
| VD-001 · Variant link | 6 of 20 sampled pages open the wrong option | First |
| VD-002 · Sale price | 12 submitted rows contain the ended sale; 2 pages checked | First |
| VD-003 · Item grouping | 8 rows across 2 product families use inconsistent group IDs | Next |
Priorities describe a proposed work order, not measured revenue impact. Findings may overlap; counts should not be added as unique affected items.
VD-001 · Variant selection
A valid product link opens the wrong option.
Observed in the example: the row for TEE-NV-M describes navy / medium at $38. Its submitted link opens charcoal / small at $34. The product page exists, but the selected option does not match the row.
| Field | Submitted row | Page observation |
|---|---|---|
| Item | TEE-NV-M | TEE-CH-S selected |
| Price | 38.00 USD | 34.00 USD |
| Link | /products/cotton-crew | Default option opens |
Working hypothesis: the source link omits the variant selection. A real investigation would also check redirects and theme behavior before assigning the cause.
Proposed repair: update the source mapping to send the correct variant-specific URL, then regenerate the affected items. Owner: feed implementer, with theme developer support if selection does not persist.
Verification checklist
- Open the new submitted URL in a fresh session and confirm navy / medium is selected.
- Compare visible price, currency and stock state with the submitted row.
- Check the page’s published product data for the same selected variant.
- Confirm the updated source was processed, then recheck the reported issue after Google has reprocessed the item.
Completion of the technical checks does not guarantee that Google will approve the item.
VD-002 · Ended promotion
The export still carries yesterday’s sale.
Observed in the example: twelve rows contain a $29 sale price while the promotion has ended. Two manually checked product pages display the regular $38 price.
Working hypothesis: the data source did not refresh after the promotion ended. The sample does not establish the state of the ten unchecked landing pages.
Proposed repair: verify the authoritative promotion dates and feed-generation timing. Remove or correct the expired sale attributes at the source, and review refresh scheduling.
Verification: inspect the regenerated twelve rows, check representative URLs again and record when Merchant Center processed the update. Owner: store operator for promotion truth; feed implementer for the export.
VD-003 · Product families
Variants do not share a consistent group ID.
Observed in the example: eight rows in two synthetic product families use inconsistent item_group_id values. Color and size values still exist, but the group mapping does not follow the product-family structure.
Proposed repair: confirm which items are true variants, then map their group ID consistently at the source. Preserve the unique item ID of each variant.
Verification: compare the regenerated rows against the product-family mapping and confirm that unrelated products were not grouped together. Owner: feed implementer, with the store operator confirming the catalog structure.
What the real handoff adds
Your actual report includes your source, item IDs, full URLs, observation times, evidence and access dependencies. The repair proposal states which issue classes are included, what your team needs to supply and how the result will be checked.
The diagnostic is $299. Up to 2,500 variant rows and 20 manual URL checks. If you choose a repair pilot, the diagnostic counts toward its $750 total.
Reference: Google’s product data specification. Requirements depend on product, destination and market; we check the applicable requirements during a diagnostic.