SKUs and barcodes (the GTIN field)
How Shopify's variant barcode field maps to Google's gtin, why the SKU is not a GTIN, when SKU can serve as mpn, and the exact places merchants put the wrong value.
Shopify gives each variant two identifier fields: SKU (your internal stock code) and Barcode (meant to hold the product's real GTIN). Google reads the barcode as gtin, its single most important matching signal, and treats the SKU as, at most, an mpn, and only when the SKU genuinely is the manufacturer's part number. Mixing these up is the most common defect in Shopify-sourced feeds, and it causes disapprovals that spread beyond the affected products.
Two identifier fields, two very different jobs
Every Shopify variant has two identifier fields, and they are constantly confused:
- SKU (Stock Keeping Unit): your internal code for tracking stock. You invent it. "DRESS-RIO-RED-10", "SS24-0047", whatever your warehouse uses. It means something to you and nothing to anyone else.
- Barcode: meant to hold the product's real GTIN: the globally registered number printed under the barcode on the packaging (a UPC, EAN, JAN or ISBN). It means the same thing to every retailer on earth.
Google reads these completely differently:
| Shopify field | Google attribute | Condition |
|---|---|---|
| Barcode | gtin |
Should always be filled when the product has a barcode |
| SKU | mpn |
Only when the SKU genuinely is the manufacturer's part number |
| SKU | : | If the SKU is your own invented code, it maps to nothing |
gtin is Google's strongest matching signal: it's how your offer gets pooled with every other merchant selling the identical item, unlocking richer placements and better click-through. mpn is a weaker fallback used mainly when no GTIN exists. And your internal SKU, in the common case where you invented it, has no Google home at all.
Why the SKU is not a GTIN
A GTIN is not just "a code": it's a validated number:
- It's a fixed length: 8, 12, 13 or 14 digits.
- Its final digit is a check-digit: a checksum of the preceding digits.
- Its leading digits encode a registered GS1 member prefix.
Your SKU satisfies none of this. "SS24-0047" isn't a valid length, has no check digit, and belongs to no prefix. So when a feed maps SKU → gtin, Google's validation rejects it as an "incorrect product identifier": and the failure isn't isolated. Enough incorrect identifiers and the account picks up a warning that can suppress far more than the offending items. The full validation rules are in the product identifiers reference.
When SKU legitimately is an MPN
There's one honest case for using the SKU as an identifier: you resell manufacturer parts and adopted the maker's own part number as your SKU. If Bosch's part number is GBH-2-28-F and that's literally your SKU, then SKU → mpn is correct: for products with no GTIN. But this is the exception. Most stores' SKUs are their own scheme, and for those, SKU maps to nothing and mpn should stay empty (with identifier_exists: false if there's no GTIN either).
Where merchants put the wrong value
The mistakes cluster in a few predictable spots:
- Empty barcode fields. Shopify never requires a barcode, so most catalogues are riddled with gaps: and barcode is the only native source for
gtin. No barcode, no GTIN, no catalog match. - SKU pasted into the barcode field. A bulk import maps the wrong column and every "barcode" is actually an internal code. This is worse than empty: empty is a gap, but a fake GTIN is a validation failure.
- GTIN typed into the SKU field, barcode left blank. The real GTIN is in the catalogue (just in the wrong box) so the feed reads an empty barcode and reports no GTIN while the number sits one field over.
- One barcode shared across variants. Assigning the same barcode to every size or colour, because a barcode was only entered once at product level. Each sellable variant needs its own GTIN; sharing one is a disapproval magnet.
Deep dive How the SKU-as-GTIN error spreads at catalogue scale
The single-product version of this mistake is annoying. The catalogue-scale version is what actually damages accounts, and it almost always originates in a bulk operation.
The typical sequence: a store migrates platforms or onboards a new supplier via CSV. The import template has a column literally headed "Barcode", and someone maps the supplier's internal article number to it: because it looked like the closest match. Now thousands of variants carry internal codes in the barcode field. The feed faithfully maps barcode → gtin, exactly as designed, so thousands of offers submit invented GTINs at once.
Google validates each on submission. Most fail the check-digit test outright. The account crosses the threshold where "incorrect product identifiers" becomes an account-level warning, and Google's response isn't limited to the bad items: trust in the whole feed drops, and clean products alongside them can lose visibility. The merchant sees Shopping performance fall off a cliff with no single obvious cause, because Shopify itself reported no error: it stored exactly what the import told it to.
Two defences matter, and they're different:
- Validation, not presence. Checking that barcode is non-empty is worthless here: the fake codes are non-empty. The check has to be length + check-digit + prefix legitimacy, i.e. "is this a real GTIN", per variant.
- Reading before writing. Because /tools reads your Shopify barcodes and evaluates them rather than trusting them, it can flag the fakes, tell you which variants and which SKUs they came from, and (where a confident match exists) fill genuine GTINs by matching your products against external barcode databases. All of that lands in /tools' supplemental layer; your Shopify barcode fields are never overwritten, so if a match is wrong you've lost nothing. See GTIN enrichment.
Validate before you submit, not after Diagnostics lights up: the account-level damage is far cheaper to prevent than to recover from.
How /tools handles this
/tools maps the variant barcode to gtin and validates it properly (length, check digit and prefix) rather than just checking it isn't blank, so SKUs-in-the-barcode-field and other fakes surface before Google sees them. Where a barcode is missing, GTIN enrichment can match the product against external barcode databases and supply a real GTIN where a confident match exists, telling you which products still need a human answer. SKU is mapped to mpn only where it genuinely is a manufacturer part number, never blindly. Everything is written to /tools' supplemental feed layer: your Shopify SKU and barcode fields are read, never changed. Identifier coverage is the heaviest-weighted input to your Feed Health Score.
Frequently asked questions
Which Shopify field becomes Google's gtin?
The variant Barcode field, nothing else. If your barcodes are empty or hold internal codes, your gtin attribute inherits that gap. It's the most common single defect in Shopify feeds.
Can my SKU be used as the gtin?
No. A SKU is your own internal stock code; a GTIN is a globally registered barcode number with a check digit. Submitting a SKU as gtin fails Google's validation and causes incorrect-identifier disapprovals.
When is a SKU an mpn?
Only when the SKU genuinely is the manufacturer's part number for the item, common when you resell OEM parts and use the maker's code as your SKU. If your SKU is your own invented code, it is not an mpn.