Fix “Duplicate id” on Google Merchant Center

Duplicate IDs in the feed are silently destructive. Google keeps the first match and drops subsequent rows with the same id — no error report, the items just disappear from the catalog. The hidden inventory gap can persist for months without anyone noticing because the diagnostic doesn't fire. This is why duplicate-id is particularly damaging: there's no surfaced symptom, just unexplained inventory gaps in Shopping that look like "products aren't appearing" when really the products were silently dropped.

The most common cause is multi-region feeds combining the same SKU under one id across regions. The same SKU sold in US, UK, and EU markets ends up appearing three times in a combined feed with identical ids. Google keeps one and drops the other two. The fix is region-suffixed ids: `SKU-001-UK`, `SKU-001-US`, `SKU-001-EU` — three unique ids representing the same SKU sold across three markets. Each gets its own listing with regional pricing, shipping, and availability; the algorithm treats them as separate products even though they share an underlying SKU.

The variant-level case is the second most common. The rule is variants share an item_group_id but each has its own unique id. Catalogs that mistakenly use the parent product's id across all variants lose all but the first variant. A dress in 5 sizes × 3 colours = 15 variants, but only 1 (the first one processed) appears in the catalog. The other 14 are silently dropped. The fix is unique ids per variant — typically constructed as `{parent-id}-{variant-suffix}` like `DRESS-001-S-BLUE`.

The bulk-import-error case catches catalogs migrating from one platform to another. A CSV import where rows accidentally got duplicated produces visible duplicate ids when imported. The first occurrence wins; later occurrences silently drop. Audit by sorting the feed by id and looking for duplicates — the duplicates are obvious in a sorted list; harder to spot in normal browsing.

The platform-migration case is harder to debug. Shopify catalog migrated to a new feed-generation tool; the new tool generates ids differently from the old one; the new ids happen to collide with old ones in some cases (different products getting the same id). The diagnostic shows "many products missing" but the cause is silent ID collisions, not missing data.

The case-sensitivity dimension can catch surprising duplicates. `SKU-001` and `sku-001` are different items to Google's classifier, so they don't trigger duplicate-id. But `SKU-001` and `SKU-001` — exact case match across different products — gets caught. Pipelines that strip or change casing in some flows but not others sometimes produce these collisions accidentally.

The audit approach: extract the id column from the feed, sort, count occurrences per id. Anything appearing more than once is the issue. For platforms with feed-generation logic you don't control, the fix may require working with the platform vendor or building a post-processing step. For platforms with feed-generation logic you do control, enforce uniqueness at the generation step — fail loudly when duplicates appear rather than silently producing them.

AI Shopping Feeds' Audit feature catches duplicate ids across the feed before submission, with reason codes pointing at the specific duplicate pairs and the resulting dropped items. This is the kind of silent failure that audit-before-submit prevents better than audit-after-submission (since Google's diagnostics don't flag duplicates loudly).