A SKU naming convention is a contract with your future self: every product gets exactly one identifier, structured enough that a human can read it at the packing bench and a system can join on it across every channel. Good conventions are boring and survive a decade; clever ones collapse at the first exception. Everything below optimizes for the boring kind.
The structure that works
CATEGORY-PRODUCT-VARIANT, with fixed-width segments:
WAL-BIFOLD-BRN- wallets, bifold model, brownTSH-CREWNK-BLU-M- t-shirts, crewneck, blue, mediumMUG-CLASSIC-11OZ- mugs, classic, 11oz
Rules that keep it readable and machine-safe:
- Uppercase letters, digits, hyphens. Nothing else, no spaces (they break exports), no
O/0andI/1ambiguity if you can avoid those characters in codes, no special characters that some marketplace field will reject. - Fixed segment widths (3-4 chars for category, consistent variant codes) so SKUs sort and scan predictably.
- Short enough to say aloud. Under ~20 characters; the packing bench reads these all day.
- A code sheet, one page mapping segment codes (BRN = brown, CRW = crewneck), maintained like the asset it is.
What to encode, and what to leave out
Encode: the stable attributes you actually filter and pick by, category, product line, and the variant dimensions (size, color, capacity). These earn their characters daily.
Never encode:
- Price or cost, it changes; the SKU cannot.
- Supplier, you will re-source, and the SKU outlives the relationship.
- Channel, the same product must carry the SAME SKU on your store, Amazon, eBay, and Etsy; that identity is what cross-channel matching joins on. Channel-suffixed SKUs (
-EBAY) reintroduce the identity problem sync exists to solve. - Sequential meaning you will regret, purely sequential SKUs (
0001,0002) are unreadable at the bench; purely descriptive ones run out of room. The hybrid above is the compromise that lasts.
Variants: the part most conventions fumble
Every sellable variant is its own SKU, sharing the parent stem: TSH-CREWNK-BLU-M, TSH-CREWNK-BLU-L, TSH-CREWNK-RED-M. The stem groups the family; the suffix identifies the unit. Keep variant dimension ORDER fixed (always color before size), because BLU-M and M-BLU as coexisting styles is how duplicates and mispicks breed. Stock truth lives at the child level, per-variant counts are what sync moves.
The cardinal rules
- One product, one SKU, forever. Retired SKUs stay retired; reuse poisons history and every system that remembers the old identity.
- Same SKU on every channel. The entire multichannel stack, matching, sync, per-SKU forecasting, joins on it.
- Assign at creation, not at listing. Products without SKUs accumulate exceptions; the convention applies from the first spreadsheet row.
- Document the code sheet where the next person will find it.
Migrating a messy catalog
Existing chaos is fixable in one deliberate pass: design the convention, generate new SKUs for the catalog, update the source of truth first, then mirror to channels (most marketplaces let you edit the seller SKU on a live listing without relisting). Do it BEFORE connecting sync tooling, clean identity makes the connection an afternoon; dirty identity makes it archaeology.
Common questions
Should SKUs be meaningful or random?
Meaningful-lite, the structure above. Fully random codes work for warehouses with scanners everywhere; small teams read SKUs with human eyes constantly.
SKU versus barcode (GTIN) - the same thing?
No. The SKU is your internal identity; GTINs are global product codes. A product can carry both; the SKU is the one you control and join on.
How do I handle bundles?
Bundles get their own SKU (BND- prefix works), with components tracked so a bundle sale decrements component stock, a mapping your inventory layer should own.
What about one-of-a-kind items?
Same convention, unique per item (ART-PRINT-0042). Identity discipline matters most exactly where quantity is one.
Identity is infrastructure
Clean SKUs, matched once, synced everywhere in seconds, from $49/month with unlimited orders. See pricing.