How to Structure SKUs: SKU Naming Convention Best Practices

By the Plytix Team · Updated May 4, 2026

TL;DR

• What it is: A SKU is your internal product identifier. It helps your teams and systems refer to the same product consistently across your catalogue.
• Why it matters: A clear SKU structure helps prevent duplicates, simplify mapping, support automation, and keep product data stable as your catalogue grows.
• Best approach: For most growing catalogues, following SKU best practices, like a short, codified SKU structure is the most practical option. Keep it unique, consistent, readable, and separate from external identifiers like UPCs, EANs, GTINs, ASINs, or MPNs.
• When it matters: SKU structure matters most during PIM setup, imports, integrations, variant management, and channel expansion.

What is a SKU?

A SKU is simply your internal product code. It's the shorthand your business uses to refer to a product across all your different systems and teams, whether that's your PIM, ERP, ecommerce platform, warehouse, or a humble spreadsheet.

Each system shows the same product connected via the SKU.

Think of it as the shorthand your business gives each product so your PIM, ERP, ecommerce platform, warehouse, and spreadsheets all know they are talking about the same thing.

SKUs are used to:

• Track inventory
• Connect systems
• Identify products across channels
• Support imports, exports, and automation

Unlike barcodes such as UPCs or EANs, SKUs are created by you. That is helpful because it gives you flexibility and control. It is also where things can go sideways if no one agrees on the rules.

SKU vs. other product identifiers

A SKU is not the only code attached to a product. Most businesses end up dealing with several identifiers at once, and they are easy to mix up.

The simplest way to think about it is this: your SKU is internal. Most other identifiers are external, standardized, or assigned by someone else.

UPC / EAN

A UPC or EAN is the number behind a retail barcode. These are used for physical retail, point-of-sale systems, and many marketplace requirements. You do not invent the format yourself.

GTIN

A GTIN is the umbrella term for standardized product identifiers issued by GS1, including UPCs and EANs. When a retailer or marketplace asks for a GTIN, they usually mean the barcode number used to identify the product externally.

ASIN

An ASIN is Amazon’s own identifier. If you sell on Amazon, your product will have one whether you asked for it or not. Useful to store, not useful as your main internal identifier.

MPN

An MPN is the manufacturer’s part number. It often matters in industries like electronics, automotive, and industrial goods. It can be important for matching and channel requirements, but it still should not replace your own internal SKU.

The practical takeaway: your SKU is the spine of your product data. Everything else should connect to it, not replace it.

What makes a good SKU naming convention?

When you start to think about how to structure SKUs, there is no universal SKU standard, which is both liberating and mildly annoying.

You are not trying to invent the perfect code. You are trying to create one that stays useful as your business gets bigger, your catalogue gets messier, and your systems get more connected.

A good SKU is:

• Unique so each product or variant has its own identifier
• Consistent so the same logic applies across the catalogue
• Stable so it does not change every time marketing updates a product name
• Readable so a human can still work with it
• Scalable so it keeps working when your catalogue is much larger than it is today

A common structure is to move from general to specific:

[Category]-[Key Attribute]-[Key Attribute]-[Unique Number]

Example: TSH-COT-BLU-1042

That could mean:

• T-shirt
• Cotton
• Blue
• Product 1042

Not every business needs this exact setup. But the logic holds up well: start broad, add only the details that matter, and finish with something that makes the SKU unique.

The most common ways companies structure SKUs

There is no single right way to build a SKU. But there are a few common patterns people actually use, for better or worse.

Sequential numbers

This is where a lot of companies begin. It is easy. Product one gets 1001, product two gets 1002, and everyone moves on with their day.

That works for a while. Then you have thousands of products, five spreadsheets, two imports, and no one can tell what anything is by looking at the SKU. At that point, simple starts to become expensive.

GTIN-based identifiers

Some businesses try to use GTINs as SKUs because they are already unique. Fair idea in theory. Less great in practice.

GTINs are made for external identification, not internal product logic. Best practice is to store them as attributes and keep a separate SKU for your own operations.

Supplier or manufacturer SKUs

This is common when companies are starting out because the code already exists and no one wants to do extra work.

The problem is that now your internal system depends on someone else’s logic. If a supplier changes a code or you switch vendors, your catalogue can get messy fast.

Alphanumeric or codified SKUs

This is the most practical option for growing catalogues. It combines short codes with a unique number.

Example: TSH-COT-1042

This format is easier to scan, easier to troubleshoot, and more useful in a PIM. It gives you structure without turning the SKU into a full biography of the product.

How to build a SKU system that scales

For most growing catalogues, the alphanumeric or codified approach is usually the best fit. It gives you enough structure to make SKUs readable and scalable, without relying on external standards or someone else’s numbering system.

1. Decide what the SKU actually needs to communicate

Before you create anything, decide what belongs in the SKU and what belongs somewhere else as an attribute.

Usually, the SKU only needs the details that help identify the product quickly, such as:

• Category or product type
• One or two important distinguishing traits
• A unique number or base code

This is where people often get overambitious. If your SKU is trying to hold every detail about the product, you defeat the primary purpose of an SKU: to serve as a fast and simple reference.

2. Standardize your abbreviations

If you use short codes, make them easy to recognize and use consistently.

Examples:

• BLK = Black
• BLU = Blue
• SML = Small
• LRG = Large

Keep a shared reference list. Otherwise one person writes BLU, another writes BLE, and suddenly your tidy structure has trust issues.

3. Keep the structure short and stable

A SKU should be informative, not exhausting.

If it starts to look like a compressed sentence, it is probably doing too much. Shorter structures are usually easier to maintain, easier to read, and less likely to break across systems.

4. Build one repeatable template

Create one structure your team can follow every time.

Example:
[Category]-[Material]-[Color]-[Number]

That might produce:
TSH-COT-BLU-1042

Your exact format may differ, but the important thing is that it becomes a rule, not a suggestion.

5. Test it before full rollout

Before applying a new SKU structure across your whole catalogue, test it on real products.

Look for:

• places where the format becomes awkward
• edge cases that do not fit cleanly
• moments where different team members would make different choices

A good SKU system is not just logically sound. It is something real people can apply without improvising every third product.

SKU best practices and common mistakes to avoid

Most SKU problems are not dramatic. They are just annoying, recurring, and surprisingly expensive over time.

Best practices

• Keep it alphanumeric: Use letters and numbers only. This keeps the SKU easier to read, easier to type, and less likely to break in imports or connected systems.
• Use dashes or underscores instead of spaces: Spaces tend to cause trouble in exports, integrations, and data handling. Separators like - or _ are much more reliable.
• Move from general to specific: Start with the broadest identifier, such as category or product type, then add narrower details after that. This makes the SKU easier to scan and sort logically.
• End with something that ensures uniqueness: A sequential number or stable unique ending helps guarantee that each SKU is distinct, even when products share similar attributes.
• Use fixed abbreviations: Choose one code for each recurring value and stick to it. If one person uses BLK and another uses BLA for black, the structure starts falling apart fast.
• Keep it stable over time: A SKU should not need to change because a product name, description, or marketing label changes. It should remain a dependable internal identifier.
• Test it against the systems it needs to connect with: Before rolling it out, make sure the format works cleanly in your PIM, ERP, ecommerce platform, warehouse tools, and any import/export workflows. A SKU that looks good on paper can still fail in the real world.

Common mistakes

Using product names as SKUs
Names change. SKUs should not.

Relying on supplier SKUs
You lose control of your own identifier strategy.

Overloading the SKU
A SKU is an identifier, not a full product description with aspirations.

Using inconsistent formatting
Mixing spaces, dashes, underscores, or different abbreviation styles creates import and mapping issues very quickly.

Using easily confused characters
Characters like O and 0, or I and 1, seem harmless until someone reads them over the phone or types them in a hurry.

Why SKU logic matters in your PIM

In a PIM, the SKU usually acts as the shared identifier across systems. It is the thread that helps your product data line up cleanly between your catalogue, channels, ERP, warehouse, and feeds.

That matters more than people expect.

It prevents duplicates

When a SKU follows a clear structure, it becomes much easier to spot when a product already exists. That alone can save a surprising amount of cleanup work.

It simplifies mapping

Most integrations rely on a shared identifier to match records. Clean SKUs make that process much more reliable and a lot less nerve-wracking.

It enables automation

Structured SKUs can support rules and formulas inside your PIM.

For example, a PIM may be able to:

• identify product families based on a shared base
• support variant grouping more cleanly
• help generate names, tags, or internal labels
• make imports easier to validate

The SKU does not need to do everything, but a logical structure gives your systems more to work with.

It supports scale

A fixed, understandable structure gets more valuable as your catalogue grows. The more products, teams, and systems involved, the less room there is for guesswork.

A note on future-proofing

Future-proofing your SKU structure is not really about guessing what your business will need in five years. It is about making sure your product data is easy for systems to work with.

That matters more now because AI and automation are becoming part of everyday catalogue operations. Structured, consistent SKUs can help support variant grouping, product matching, validation, and other rule-based workflows inside your PIM and connected systems.

A SKU should not try to hold your entire data model. But when it follows a clear pattern, it becomes one more stable signal your systems can rely on.

Final Thought

A SKU is not just a code. It is part of the structure that keeps your product data stable.

A clean SKU system makes imports easier, reduces duplicates, supports automation, and helps your PIM act like a reliable source of truth instead of a very expensive meeting point for confusion.

The best time to set up a solid SKU structure is before your catalogue gets unruly. The second best time is now.