Identifiers

Every code that identifies your product is in one list on the variant, and each integration you connect takes the ones it needs from that list.

An identifier is a value that lets something outside the PIM recognize your product. A scanner reads a barcode, Amazon matches an ASIN, and every integration you connect finds your variant by its SKU. Your own spreadsheets and labels use them too.

The PIM keeps all of a variant’s identifiers in one list. You type each value once, and every connected integration with a field for it gets it from that same list. You never paste the same barcode into 3 places.

You will find the list in the product editor. From Catalog, open Products and click a product: the Identifiers section is between Taxonomy and Assets. Once a product has options, that section is gone, and each variant keeps its own list instead, which you open through the Variants section one variant at a time.

The section moves because identifiers are set on your variant, not on your product. A red shirt and a blue shirt are 2 different things to scan, so each variant needs its own barcode and its own SKU. The page on variants explains options and variants themselves.

Before you start

You need the Editor role or above to change a product, and identifiers are part of the product. Roles are set in team, roles and permissions.

How to add an identifier

1. 1

   Open the product

   From Catalog, open Products and click the product you want. The Edit Product dialog opens over the page.

2. 2

   Find the Identifiers section

   Scroll to Identifiers, between Taxonomy and Assets. If the product has options, open the Variants section instead and click the variant you want: the Edit Variant dialog opens with Identifiers at the top.

3. 3

   Add a row

   Click Add at the bottom of the section. A row appears with a Type dropdown and a Value box. Your first row arrives as SKU, and after that new rows arrive as Barcode.

4. 4

   Pick the type and enter the value

   Set Type to the kind you are adding and type into Value. An ASIN row also asks for a Marketplace, and a Custom row also asks for a Custom Label.

5. 5

   Save

   Click Update. While any row shows an error, the button stays off, so fix the row or remove it.

That is the whole job. Each row checks its value as you type, and a moment after you stop typing the PIM also checks that the value is not already taken elsewhere in your catalog. Once every row is clean, your save goes through, and the next sync sends your new values out.

Everything below is detail: what each type is for, which values have to be unique, and what each of your integrations does with them. You do not need any of it to give a product a SKU and a barcode.

Every option in detail

The six types

The Type dropdown gives you six kinds of identifier, and the type decides what you can put in Value.

Your manufacturer’s part number goes in Part Number. If you are reading down the Type list for UPC or EAN, Barcode is your row.

A barcode or an ISBN has to be real. The PIM checks a barcode’s last digit the way a scanner would, and an ISBN against the published ISBN rules. A value with one digit mistyped is rejected, which is the point: you catch the typo here instead of on a printed label.

Let the PIM write the SKU for you

Every SKU row has a generate button at the right end of its Value box. Click it and the PIM fills in a value for you, shaped like ABC-234-XYZ, 3 letters, 3 digits, 3 letters, guaranteed unused in your organization. The alphabet leaves out characters people misread, so you never get an I, L, or O, and never a 0 or 1.

If the row already has a value, the PIM asks before replacing it, with Replace and Cancel. A short SKU generated message confirms it worked.

Put the rows in the order you want them sent

Once a variant has 2 or more rows, a drag handle appears on the left of each one, and you can drag the rows into any order. The order you set here is the order your integrations see.

Where an integration has room for only one value of a type, the PIM sends your first row of that type and the rest stay in the PIM. Where it has room for a list, your rows go out in your order. So dragging a row to the top is not tidying: it changes what leaves the PIM.

SKU is the one type where order never matters, because your variant only ever has one.

The uniqueness rules

Some identifiers have to be unique, and the PIM rejects a save that breaks a rule instead of warning you. Each type answers two questions its own way: how many rows of it your variant can have, and where the value must be unique.

Because your variant has only 1 SKU, the Type dropdown stops showing SKU on your other rows once one exists. The row that has it keeps it.

Part Number collides only inside a brand. Two products conflict only when they share at least one brand. You can use the same part number under two different brands, and a product with no brand conflicts with nothing. The rule runs in both directions: you also cannot attach a brand to a product while that brand already has one of the product’s part numbers elsewhere. That is the same conflict arriving from the brands side.

Custom rows watch the label, not the value. Any number of variants can share a value, and nothing checks it. What one variant cannot have is two custom rows with the same label, capitals or not. Nothing flags that while you type, so it arrives at save time as a general message about a value that already exists. If you get that message and every value looks unique, compare your custom labels.

The same value twice on one variant is rejected for every type, and both rows are marked the moment you type the second one.

Duplicating a product copies almost everything and deliberately leaves the identifiers behind, because every value with a uniqueness rule would collide the moment you saved the copy.

Add an ASIN for each Amazon marketplace

An ASIN tells the PIM which Amazon listing your offer goes on. The marketplace is part of the answer, because the same product is a separate listing on amazon.com and on amazon.ca. So every ASIN row has a Marketplace dropdown beside its value, with 22 Amazon marketplaces in it, and a new row starts on United States (amazon.com).

A variant you sell in the United States, Canada, and Mexico has 3 ASIN rows, one per marketplace. A second row on a marketplace that already has one is rejected before you can save.

Every ASIN in your catalog is typed by a person. There is no ASIN lookup and no Amazon catalog search in the PIM. Your imports and exports move the other identifier types by file and leave ASINs out. Reading your Amazon account in does not add any either: the PIM only uses the ASIN rows you typed to recognize offers you already have. Copy the ASIN from the listing page on Amazon and paste it in.

Find a product by an identifier

The search box above the products table, marked Search..., matches what you type against product titles, identifier values, and custom labels. Pasting a SKU or a barcode into it is usually the fastest way to your product.

The table also has an Identifiers column, which shows you up to 3 of each variant’s values. To search one type alone, filter that column. Click Filters above the table, set Filter by to Identifiers, and pick a condition such as contains or equals. Then start your text with a type prefix: sku:ABC-123 matches SKUs only. The prefixes are sku:, gtin:, pn:, isbn:, and custom:, there is no ASIN prefix, and you cannot sort the column.

Limits

What identifiers cannot do

What your integrations get

What goes out depends on the fields each of your integrations keeps. Every integration gets a SKU, because the SKU is how it recognizes your variant. Most keep one barcode field, and everything else goes out only where there is somewhere to put it.

Which barcode goes where one fits. Square and BigCommerce read your Barcode and ISBN rows top to bottom and take the first value they accept: 12, 13, or 14 digits. An ISBN-10 is converted to its 13-digit form on the way. An 8-digit barcode is skipped instead of sent, so a longer row further down still goes out. Google takes up to 10 of your values and accepts 8-digit codes. Shopify takes exactly your first Barcode row, and later barcode rows stay in the PIM.

What Shopify gets

Shopify keeps the widest set. Its own SKU and barcode fields take your SKU and your first Barcode row. Your ISBNs, part numbers, and custom rows go out whole, in your order, into three fields the PIM creates in your store and manages.

Those three fields are filled from here and nowhere else. Somebody can still edit one in the Shopify admin, because Shopify offers no way to lock a field like that, and your next push writes your version back over the edit. The Shopify integration covers the rest.

What Square gets

Square’s own fields take your SKU and one barcode. Square also gets two named attributes the PIM creates on each variation, SKU and Part Number. The SKU attribute always has your own SKU row, even when the SKU field setting below sends something else as the SKU, so your original never disappears from Square. The part number is your first row only.

If your variant’s only barcode row is 8 digits, with no ISBN below it, Square gets no barcode at all.

What Google gets

Google finds a listing by its SKU, so a variant with no SKU is not sent, and the product tells you so. With the SKU go up to 10 barcodes, your first part number, and the brand. A variant with no barcode and no part number is still published: the PIM tells Google your product has no standard identifiers instead of keeping it back.

Google never writes identifiers into your catalog. On first connect it uses your SKUs, part numbers, and barcodes to recognize listings you already have, and that is all.

What Amazon gets

Amazon gets an offer, not a product page. With the SKU-to-ASIN link go the condition, the price, and, for offers you ship yourself, the quantity. It never gets your titles, descriptions, images, brands, categories, or specifications, in either direction. That is why the integrations section describes an ASIN as a link to a listing Amazon already has.

An offer goes out once your variant has all three of a SKU, an ASIN for that marketplace, and a price the account’s settings can produce. With no SKU or no ASIN, nothing is sent and nothing is flagged. With no price, the product is flagged, with a message naming the gap.

Send a different identifier as the SKU

Shopify, Square, Google, and BigCommerce accounts each have a SKU field setting, in the Identity section of the account’s settings page under Integrations. It gives you SKU, Part Number, and Barcode, and it decides which of your identifiers that account gets as its SKU. It is per account, so one integration can run on your part numbers while another runs on your SKUs. Amazon has no such setting, because Amazon treats the first SKU it gets as the offer’s permanent name.

Two things happen behind that choice:

• A duplicate is made unique for you. When the chosen value is not unique across your organization, the PIM puts the product’s brand in front, as BRAND-VALUE. The integration still gets something unique. If even that collides, the product does not sync, and tells you so.
• A variant missing that identifier does not sync at all. The product is flagged with a message naming what is missing. There is no quiet fallback to your SKU, because a silent replacement would publish two different names for the same variant.

Your own SKU row never changes: the setting only decides what the integration is told. Integration settings has the rest of the per-account settings.

What a read writes into your list

Connecting an integration can also write identifier rows, so a variant’s list is not only what you typed.

A barcode from an integration always arrives as Barcode, whatever it really is. A store keeps one barcode field, and nothing in it says whether the value is a UPC or an ISBN. So the PIM files them all under Barcode and leaves the judgment to you. If one is really an ISBN, open the product and set that row’s Type to ISBN once, and the next sync sends it to the right field.

A variant with no SKU in the store gets a placeholder, because nothing can be matched without one. A Shopify variant arrives with a SKU built from _shopify- plus the product’s handle and the variant’s own number. A Square variation arrives as _square- plus its own number, and a BigCommerce variant starts with _bigcommerce-. Replacing placeholders with your own SKUs is normal work, not a repair.

A value your catalog already uses is dropped, not merged. On a Shopify first sync, a duplicated barcode or ISBN is skipped, and the product is flagged so you can settle the collision yourself. A duplicated SKU stops that whole product from importing. Square drops a barcode that fails the digit check, and nothing tells you it happened.

When something goes wrong

Reading the error on a row

A row with a problem tells you under its Value box as you type. The messages name the type on the row, so SKU below stands in for whichever type yours is.

The checks run while you type, so a longer code flashes a check-digit error at the lengths it passes through. Type your whole number before you read the message.

The check you do not see

A moment after you stop typing, the PIM checks whether your value is already taken elsewhere in your catalog, and answers on the row.

Your Custom and ASIN rows are never checked this way, because neither has a value that must be unique.

While any of your rows shows an error, or that check is still running, the save button stays off. Fix the row, or remove it, and the button comes back.

When the save itself is rejected

Two people can claim the same value in the same few seconds, and whoever saves second finds out then. The message you get is worded from the product instead of the row.

The messages in this table and the previous one show in English even when you use the app in Spanish.

The generate button has one failure of its own, Could not generate a unique SKU. Try again or enter one manually., which means it kept hitting values that were already taken and gave up, so you type one in yourself.

Messages from a sync

When a sync cannot use your identifiers, the product’s sync status for that integration says so.

Where to go next