A good SKU naming system gives each sellable or stocked item one stable internal code that people and systems can use without ambiguity. It should support receiving, picking, sales, reporting and channel mapping, but it should not attempt to describe every product fact inside the code.
This guide owns internal SKU governance beneath GPTWala’s digital product catalogue strategy. It distinguishes an internal SKU from external identifiers such as GTINs and from the barcode symbols that may encode identifiers.
- Define what the SKU must identify
- Use stable, unique and machine-safe rules
- Choose only durable attributes for code segments
- Create variant combinations systematically
- Separate SKU, GTIN, barcode and serial number
- Create a controlled SKU-assignment workflow
- Validate rules automatically and operationally
- Govern changes, retirement and exceptions
- Migrate a weak legacy scheme without losing history
- Publish the rule and monitor data quality
- Frequently asked questions
- Sources and further reading
Define what the SKU must identify
Decide whether a SKU represents a base product, each sellable variant, each packaging level, a service part or a bundle. Most product businesses need one SKU per distinct inventory or order line. A colour, size, pack or material change that affects stock, price, fulfilment or buyer choice normally needs a separate SKU.
Write the rule in business language before choosing characters. Record systems that store the SKU, field limits, case sensitivity, barcode needs, marketplace constraints and existing codes that cannot change.
| Question | Decision | Risk if unclear |
|---|---|---|
| What is one item? | Variant and packaging boundary | Stock mixes across offers |
| Where is code used? | ERP, POS, website, warehouse and feeds | Field truncation or mismatch |
| Who creates it? | Named product-data owner | Duplicate codes |
| When is it retired? | Lifecycle rule | Old code is reused incorrectly |
Use stable, unique and machine-safe rules
Prefer uppercase letters and digits with one approved delimiter if systems support it. Avoid spaces, ambiguous characters, punctuation with special meaning and codes that change when a product moves category or supplier. Keep the scheme within the strictest connected system’s length.
A code does not need to be memorable at any cost. Search, labels and product names should help people find items. Overly short codes collide; overly descriptive codes break when facts change.
| Principle | Good rule | Weak pattern |
|---|---|---|
| Unique | One code maps to one item | Code reused after discontinuation |
| Stable | Code survives editable descriptions | Category name embedded and later changes |
| Parseable | Fixed segment positions where needed | Variable free-form abbreviations |
| Compatible | Works in every connected system | Symbols rejected by one channel |
| Governed | Created by one controlled process | Each team invents codes |
Choose only durable attributes for code segments
If people benefit from meaning inside the SKU, use a limited structure such as family, model, variant and pack. Include an attribute only when it is controlled, durable, short and genuinely useful during work. Do not encode price, supplier, warehouse location, campaign, year of purchase or other facts likely to change.
Example pattern without prescribing a universal code
A hypothetical pattern could be FAM-MOD-VAR-PK, with each segment taken from a controlled code list. The correct segment length depends on the catalogue. Test for collisions before approval.
| Candidate segment | Use when | Avoid when |
|---|---|---|
| Family | Stable range groups exist | Products often move between groups |
| Model | It is an approved durable identifier | Marketing name changes frequently |
| Variant | Code list covers material, size or finish | Combinations are inconsistent |
| Pack | Packaging creates a separate order item | Pack is only a temporary promotion |
Create variant combinations systematically
Build a variant matrix before assigning codes. List all allowed dimensions and values, then generate only commercially valid combinations. A code for a non-existent variant creates errors in feeds and planning. Use the same variant labels across SKU, product name, website, data sheet and channel exports.
| Base product | Variant dimension | SKU outcome |
|---|---|---|
| One model | Three sizes | Three distinct item codes |
| One model | Two materials and three sizes | Up to six valid codes after rule check |
| Single item | Marketing image only changes | Keep same SKU if item is unchanged |
| Bundle | Contents or quantity differs | Create distinct bundle SKU and component map |
Build descriptions from approved attributes using the product-page copy template; do not force the SKU to carry customer-facing language.
Separate SKU, GTIN, barcode and serial number
An SKU is controlled inside a business. A GTIN is a globally standardised trade-item identifier issued under GS1 rules. A barcode is a data carrier that can encode an identifier. A serial number identifies an individual instance, while a batch or lot identifies a production group. Keep these in separate fields.
GS1’s standards and Google Merchant Center product data requirements help explain why a seller must not place an internal SKU in a GTIN field. Use valid externally assigned identifiers where required and follow assignment rules for packaging levels and changes.
| Identifier | Scope | Typical use |
|---|---|---|
| SKU | Internal item | Inventory, ordering and reporting |
| GTIN | Trade item in external ecosystem | Retail, marketplaces and partner exchange |
| Barcode | Machine-readable carrier | Scanning |
| Serial number | Individual unit | Warranty, traceability or service |
| Lot or batch | Production group | Quality and recall traceability |
Create a controlled SKU-assignment workflow
Require an approved product or variant request before code creation. Search current and retired codes, validate required attributes, reserve the next code or valid combination, write it to the product master, map external identifiers and publish to connected systems. The product-data owner should be the authority even when software generates the code.
| Stage | Control | Evidence |
|---|---|---|
| Request | Required product and variant fields | Approved new-item form |
| Duplicate check | Search active and retired items | No existing identity match |
| Assignment | Use controlled rule or sequence | Reserved unique SKU |
| Mapping | Attach GTIN, supplier and channel IDs | Identifier crosswalk |
| Release | Synchronise systems and labels | Channel reconciliation |
| Retire | Block new use without deletion | Lifecycle status |
Keep catalogue data consistent with the WhatsApp catalogue workflow and web product records, but never let a channel create the master SKU independently.
Validate rules automatically and operationally
Use field validation for allowed characters, segment length, required values and uniqueness. Then test labels, scanner workflows, order imports, exports, spreadsheets, leading zeros and case handling across all systems. A technically valid SKU may still be hard to read on a small label or easy to mistype by phone.
| Test | Example failure | Correction |
|---|---|---|
| Length | Marketplace truncates final segment | Shorten rule before release |
| Case | One system converts to lowercase | Treat code consistently |
| Leading zero | Spreadsheet drops zero | Store as text |
| Delimiter | ERP rejects slash | Use approved safe delimiter |
| Speech | Similar codes sound alike | Add separation or check digit approach |
Run a small pilot using real operational roles. Product data, sales, warehouse, finance and ecommerce may reveal different failure modes.
Govern changes, retirement and exceptions
Do not change an SKU merely to improve its appearance. If the physical or commercial item has not changed, update editable product attributes instead. If a material change creates a new item under business or external identification rules, create a new SKU and map the predecessor.
Never recycle retired codes. Keep status, replacement SKU, retirement reason and effective point. Exceptions should be approved, documented and rare. A temporary campaign should not create a permanent naming exception.
| Change | SKU action | Related action |
|---|---|---|
| Description correction | Keep SKU | Update controlled text |
| Supplier changes, item identical | Usually keep SKU | Update supplier mapping after review |
| Variant or pack becomes distinct stock | Create SKU | Update channels and inventory |
| Discontinued item | Retire, do not delete | Map approved replacement |
| Scheme migration | Preserve crosswalk | Freeze legacy assignment |
Migrate a weak legacy scheme without losing history
Inventory every active and retired code, detect duplicates, classify records and choose whether to preserve legacy SKUs or create new internal keys with aliases. A full renumbering can break orders, labels, history, partner files and customer references. Prefer a staged migration with a crosswalk and explicit cutover.
Reconcile open orders, stock, price lists, website URLs, marketplace feeds, documents and analytics. Product URLs should not depend solely on an SKU that may change. Follow GPTWala’s product-page SEO guide for stable page ownership.
| Migration control | Pass condition | Owner |
|---|---|---|
| Crosswalk | Every old code maps once | Product data |
| Stock | Quantities reconcile by location | Operations |
| Transactions | Open documents retain meaning | Finance and sales |
| Channels | Listings map without duplicates | Ecommerce |
| Support | Teams can search old and new | Process owner |
Publish the rule and monitor data quality
Create a short standard with purpose, scope, syntax, segment dictionary, examples, prohibited characters, request workflow, retirement rule and exception owner. Train staff through new-item scenarios. Keep the code dictionary and creation tool in one controlled location.
Monitor duplicate attempts, missing variant values, manual overrides, unmapped channel IDs, retired code use and order corrections. Use the product image rules to align asset names and identifiers without assuming that a file name itself is the product master.
| Metric | Meaning | Action |
|---|---|---|
| Duplicate attempts | Rule or search is weak | Improve validation |
| Manual overrides | Workflow does not fit | Review exceptions |
| Unmapped listings | Channel synchronisation gap | Repair crosswalk |
| Pick or order errors | Codes are hard to distinguish | Review readability |
| Retired-code use | Old files remain active | Remove distribution source |
Frequently asked questions
What is a good SKU naming system?
It creates one stable, unique, machine-safe internal code per stocked or sellable item through controlled rules, validation, ownership and retirement.
How many characters should an SKU have?
Use enough characters to remain unique and useful, but stay within the strictest connected system and label. There is no universal ideal length.
Should an SKU include product details?
Include only a few durable, controlled attributes when they help operations. Keep changing facts such as price, supplier or location outside the code.
Is an SKU the same as a barcode or GTIN?
No. An SKU is an internal item code, a GTIN is a standard external trade-item identifier, and a barcode is a carrier that can encode an identifier.
Can an SKU be changed after launch?
Avoid changing a live SKU for cosmetic reasons. Materially new items may need a new SKU, while descriptions and other editable attributes should change separately.
How do you create SKUs for product variants?
Define valid variant dimensions and code lists, generate only real combinations, assign one code per distinct inventory or order line, and map all external identifiers.