Google Shopping ID Attribute: Requirements, Best Practices & Examples

What is the id attribute?

The id attribute is the unique identifier for each product in your Google Merchant Center feed. It is the primary key that Google uses to track your product across every system: feed processing, auction participation, click and conversion attribution, Smart Bidding signals, campaign targeting, and performance reporting. Every piece of data Google accumulates about a product is anchored to its id.

Unlike most other feed attributes, the id attribute does not affect what shoppers see — it’s never displayed in Shopping ads or product listings. Its impact is entirely structural and operational. That invisibility makes it easy to underestimate, but it is arguably the most consequential single field in your feed. The rule is simple: assign it correctly once, then never change it.

Technical specifications

Where it displays

• Merchant Center feed management — The ID is the row key shown in feed diagnostics, product lists, and issue reports. When investigating a disapproval or data quality issue, you look up the product by its ID.

• Google Ads campaign interface — In Shopping campaigns, product-level reports, bid adjustments, and exclusions all reference the Merchant Center ID. Product group targeting in Standard Shopping and Performance Max uses the ID as the product reference.

• Dynamic Remarketing tags — Your website’s remarketing tag must pass the same ID values that exist in your Merchant Center feed so Google can match user behaviour (product views, add-to-cart, purchases) to specific products for audience building and ad personalization.

• Conversion tracking — For Shopping campaigns, conversion data is attributed at the product level using the ID. This is the foundation for product-level ROAS reporting and Smart Bidding signals.

The ID is never shown to shoppers in any Google surface — it is purely an internal system identifier.

Rules

• Must be unique within your Merchant Center account — Two products with the same ID in the same feed will cause one to overwrite the other. Across multiple feeds within one account, IDs must still be unique.

• 50-character maximum — IDs exceeding 50 characters will be truncated or cause feed errors. Design your ID schema to stay well within this limit.

• Case-sensitive — Maintain consistent casing throughout your feed and across all systems that reference product IDs (Google Ads, remarketing tags, analytics). Mixed casing is a common source of attribution failures.

• Must match remarketing tag values — If you implement Dynamic Remarketing, the ecomm_prodid (or equivalent) value in your website’s tag must exactly match the Merchant Center id, including case.

• Stable across feed uploads — The same physical product must have the same ID in every feed upload. Generating new IDs on each upload (e.g., using timestamps or auto-increment) is a critical anti-pattern.

Best practices

Use your SKU as the ID

The single best practice for product IDs is to use your internal SKU — the identifier your business already uses to refer to specific product variants in your inventory, ERP, or order management system. SKUs are stable (they don’t change when prices, descriptions, or images change), unique per variant (each size/color combination has its own SKU), and meaningful to your operations team (useful when debugging feed issues).

ID schema design for large catalogs

For catalogs with thousands of SKUs, a structured ID schema improves manageability:

Variant ID strategy

For product variants (different sizes, colors, or configurations of the same base product), each variant needs a unique ID. A consistent naming scheme avoids confusion:

• Base product: DRESS-WRAP-MIDI (do not submit the base — submit variants)

• Floral / S: DRESS-WRAP-MIDI-FLORAL-S

• Floral / M: DRESS-WRAP-MIDI-FLORAL-M

• Solid Navy / S: DRESS-WRAP-MIDI-NAVY-S

Group these with a shared item_group_id (e.g., DRESS-WRAP-MIDI) to tell Google they are variants of the same product.

Impact on performance

• Smart Bidding continuity — Smart Bidding strategies (Target ROAS, Maximize Conversion Value) accumulate conversion signals per product ID. A stable ID with 6 months of conversion history gets much better bid decisions than a new ID starting from scratch. ID changes directly set back Smart Bidding performance.

• Auction signals — Google’s auction uses historical product-level performance signals (CTR, conversion rate, quality) anchored to the ID. These signals take 4–8 weeks to rebuild after an ID reset, causing higher CPCs and lower impression share during that period.

• Dynamic Remarketing accuracy — If remarketing tag IDs don’t match feed IDs, audience lists are misattributed or empty, breaking retargeting campaigns entirely. Getting IDs right from day one prevents this class of problems.

• Reporting and attribution — Product-level ROAS reports, impression share data, and conversion path analysis all depend on stable IDs. Changing IDs mid-campaign makes historical comparison impossible and typically requires manual data reconciliation.

Common mistakes

• Using auto-generated sequential IDs that change when products are re-imported or the database is migrated

• Using product URLs as IDs — URLs change when site structure changes

• Using product titles or names as IDs — titles change for SEO or merchandising reasons

• Inconsistent casing between feed IDs and remarketing tag values, breaking Dynamic Remarketing attribution

• Reusing IDs from discontinued products for new products — old auction signals from the retired product contaminate the new one

• Submitting the parent/base product ID instead of individual variant IDs

• Using special characters or spaces that cause parsing errors in TSV/CSV feeds

Pro tips

• Add a feed ID validation step to your feed pipeline — Before every feed upload, run a check that verifies: no new IDs have appeared for products that already have IDs in the previous feed, no IDs exceed 50 characters, and no IDs contain prohibited characters. This catches accidental ID changes before they reach Merchant Center and destroy performance history.

• Maintain a product ID registry — Keep a canonical mapping of your internal product identifiers to their Merchant Center IDs. This is especially important during platform migrations (re-platforming your e-commerce site) where internal IDs may change but Merchant Center IDs must stay identical.

• If a forced ID change is unavoidable — Plan for a 2–4 week performance recovery period. Temporarily increase bids on affected products to maintain impression share while Smart Bidding re-learns. Monitor auction signals weekly and reduce budget protection as performance stabilises.

• Use ID as the cross-system product key — Align your Merchant Center ID with the product ID in Google Analytics 4 (the item_id in e-commerce events), your remarketing tags, and your ad reporting. A single, consistent product identifier across all systems enables end-to-end product performance analysis without ID reconciliation.