SKU Meaning: Build a Naming System That Survives Scale

SKU Meaning: Build a Naming System That Survives Scale

Direct answer

An SKU, or stock keeping unit, is a merchant-assigned identifier used to track one separately stocked product variant across inventory, orders, locations, and reports.

A durable SKU system is boring, documented, unique, and immutable. It should identify the variant without encoding information that may change, such as warehouse location, supplier, price, campaign, or stock status. Use a compact structure built from stable attributes, publish the rules in a naming dictionary, and map legacy identifiers before changing live data.

The practical rule is simple: one stocked variant receives one canonical SKU, and that SKU remains the same wherever the variant is stored or sold. Shopify also recommends short, consistent codes that avoid ambiguous characters, spaces, and most symbols. SKU guidance

Table of Contents

1. What does SKU mean in ecommerce?
2. What should and should not go in an SKU?
3. How do you design a naming dictionary?
4. How do you migrate legacy SKUs without breaking orders?
5. What should you test before rollout?
6. Sources
7. FAQ

What does SKU mean in ecommerce?

SKU means “stock keeping unit.” It is an internal inventory identity assigned by the merchant, not a customer-facing product name or universal identifier.

Every separately stocked variant should have one unique SKU. A black medium shirt and a black large shirt are different variants when they are stocked separately, even if they share one product page. A product with three sizes and two colors may therefore require six variant-level SKUs.

The important distinction is between a product and a variant. A product is the broader catalog concept; a variant is the specific sellable and countable unit. SKU design belongs at the variant level because receiving, picking, transfers, returns, adjustments, and replenishment all depend on identifying the exact item being moved.

An SKU can be readable, but readability is secondary to stable identification. Universal product identifiers and barcodes serve different purposes and may be issued outside the merchant’s own system. Stock keeping unit overview

What should and should not go in an SKU?

Include attributes that are stable and distinguish one variant from another. Exclude values that change during ordinary operations.

A practical pattern might be TSH-BLU-M. The exact structure matters less than consistent application. If BLU means blue in one category, do not use BLUE or B elsewhere without a documented rule.

Location does not belong in the identifier because inventory moves. When a unit transfers from one warehouse to another, changing its SKU makes the same variant appear to be a different item. Store location in a bin record, inventory-location relationship, or separate operational field.

Mutable attributes also do not belong in the SKU. A price change, supplier change, marketing channel, replenishment status, or warehouse assignment should not create a new inventory identity.

Use a conservative character set: short uppercase letters and numbers are easy to scan, type, export, and reconcile. Avoid ambiguous characters such as O and 0, or I and 1; avoid spaces and most punctuation. Retail identification guidance

How do you design a naming dictionary?

A naming dictionary is the source of truth for how SKU segments are created, validated, and maintained.

Begin by defining the identity boundary: one SKU represents one separately stocked variant. Then document which fields may contribute to the code and how each field is formatted.

Define what happens when an attribute is unknown, not applicable, or discontinued. Operators should use an approved token or route the record for review rather than inventing a value during data entry.

Document valid examples and counterexamples. Explain every segment in a valid SKU, then show why a tempting design—such as adding a warehouse code or receipt date—is invalid.

Assign ownership to the operating process, not to one person’s memory. Another operator should be able to create a valid SKU without asking how the original code was invented.

Keep naming separate from SKU rationalization. Naming defines inventory identity; rationalization evaluates assortment decisions. See the SKU rationalization scorecard for that adjacent workflow.

How do you migrate legacy SKUs without breaking orders?

A safe migration preserves historical references, creates one canonical mapping per variant, and prevents retired identifiers from being reused.

First inventory every place legacy SKUs appear: variant records, locations, open orders, purchase orders, returns, integrations, labels, exports, and reports. Then create a crosswalk containing:

• Legacy SKU
• Canonical SKU
• Variant identifier and description
• Location records
• Open transactions
• Integration dependencies
• Migration status and review owner

Resolve duplicates and ambiguous values before rollout. If two old SKUs refer to the same variant, select one canonical identity and retain both historical values in the crosswalk. If one old SKU refers to multiple variants, do not merge them automatically; separate the records using reliable attributes.

Where supported, retain legacy SKUs as searchable aliases. Otherwise, preserve the crosswalk in an operational reference table and prohibit reuse of retired values. Historical orders, returns, and adjustments must remain interpretable after new transactions use canonical SKUs.

Use the same canonical SKU for the same variant across all locations. Quantities by location belong in location records, not in the SKU. Migrate in a controlled sequence: freeze naming changes, validate the mapping, update master data, refresh integrations, verify labels and exports, then reopen normal entry. Keep a rollback copy of the mapping and a record of every changed field.

What should you test before rollout?

Test uniqueness, stability, readability, integrations, and historical traceability using representative records.

Confirm that every separately stocked variant has exactly one canonical SKU and that no two variants share one. Verify that the same variant retains the same SKU across locations, sales channels, purchase records, and transfers.

Include edge cases: multiple colors, numeric sizes, bundles, multipacks, missing attributes, discontinued variants, replacement suppliers, and products that move between locations.

Export and import data through every connected system. Confirm that capitalization, hyphens, leading characters, and numeric segments are preserved. Scan or type sample SKUs in the workflows operators actually use.

Finally, test historical lookup. An old order, return, adjustment, or report should still connect to the correct variant through the legacy-to-canonical crosswalk. The inventory category, inventory shrinkage controls, and stack builder provide related process context.

Sources

• SKU guidance
• Stock keeping unit overview
• Retail identification guidance