This is the least interesting guide in this series and the most important one. Nothing here will increase revenue this week. Everything here determines whether the things that do increase revenue can be built at all.
Product data is the substrate. Forecasting runs on it. Product feeds are generated from it. Back-in-stock alerts are keyed to it. Multi-location transfers depend on it. Every automation a store ever builds reads it. When it is inconsistent, each of those systems fails in a slightly different way, none of the failures announce themselves, and the diagnosis is expensive because the symptom never appears where the cause is.
Stores that struggle most at £2m are rarely the ones that chose the wrong apps. They are the ones whose product data was never structured properly, which makes every subsequent automation expensive to build and unreliable once built.
What Shopify actually stores
Worth being precise, because the vocabulary gets used loosely.
- Product — the thing with a title, description and URL. Merino Crew Neck.
- Option — an axis of choice. Size. Colour. You get three per product, and that limit has not changed.
- Option value — a point on that axis. Medium. Navy.
- Variant — one combination of option values, and the thing that actually holds stock, price and SKU. Medium / Navy.
- SKU — your identifier for that variant. Yours, not Shopify's.
- Barcode — the external identifier (GTIN, EAN, UPC). Different job entirely.
Two points that matter.
Stock lives at variant level, not product level. This is the single fact from which most of Guides 03 and 04 follow. Shopify knows the medium navy is at zero. Your dashboard, your alerts and your ad platforms mostly do not, because they were configured to watch products.
Shopify raised the variant limit to 2,048 per product in October 2025, up from 100, across all plans. The three-option limit is unchanged.
That increase is a trap as much as a gift. The fact that you can put 2,048 variants under one product does not mean you should. A product with 400 variants is unmanageable in the admin, produces a punishing product page, and makes every report you pull harder to read. Use the headroom where the combinations are genuinely one product. Split into separate products where they are not.
What is a SKU for?
A SKU exists to identify one variant, uniquely and permanently, across every system you will ever use.
That is the whole job. Everything else people try to make SKUs do — encode price, record the season, indicate the supplier, flag a discount — makes them worse at the only job that matters, because every additional meaning is a reason the SKU might need to change. And a SKU that changes has failed.
Five rules.
Unique. No two variants share a SKU, ever, including discontinued ones. Reusing a retired SKU for a new product corrupts every historical report that keys on it.
Permanent. Once a variant has been sold under a SKU, that SKU is frozen. Order line items in Shopify record the SKU as it was at the time of the order. Rename it and your historical data now refers to something that no longer exists, which breaks reporting in most third-party tools even though Shopify itself will not complain.
Machine-safe. Uppercase letters, digits and hyphens. No spaces, no slashes, no ampersands, no accented characters, no apostrophes. These break CSV exports, feed generation and URL parameters, and they break them intermittently, which is worse than breaking them consistently.
Sortable. A SKU that sorts sensibly alphabetically is a SKU you can scan in a spreadsheet. Fixed-width segments do this; variable-length ones do not.
Short enough to read aloud. If someone in a warehouse cannot read it over the phone without repeating themselves, it is too long. Sixteen characters is generous. Twenty-four is too many.
A convention worth copying
Three or four segments, fixed width, hyphen-separated.
CATEGORY - STYLE - COLOUR - SIZE
KNT - MCN - NVY - M- Category — three letters.
KNTknitwear,TSHt-shirts,ACCaccessories. - Style — three or four characters identifying the specific product.
MCNmerino crew neck. - Colour — three letters, drawn from a fixed list you maintain.
- Size — one to three characters, drawn from a fixed list.
KNT-MCN-NVY-M. Thirteen characters, readable, sortable, unambiguous, and it tells a human what it is without a lookup.
The convention itself matters far less than three things: that it is fixed width, that the colour and size segments come from closed lists, and that it is applied consistently. A worse convention applied rigorously beats a better one applied loosely.
Do not encode price, cost, season, collection, supplier, or year. All of these change or become irrelevant, and none of them belong in an identifier. Shopify has tags, metafields and the vendor field for exactly this, and they can change without consequence.
Option value discipline: the part everyone gets wrong
This is where real stores actually fall apart, and it is not the SKU.
Across a catalogue built over three years, the same navy appears as Navy, navy, NAVY, Navy Blue, Midnight Navy and Dark Navy. Sizes appear as M, Medium, med, M / UK 10 and Medium (10). Each was reasonable at the moment it was typed. Collectively they are a catalogue that cannot be analysed.
Why it costs money.
You cannot see across products. "Which colours sell best?" is unanswerable when navy exists under six labels. So nobody asks it, and buying decisions get made without the one piece of analysis most likely to improve them.
Filters fragment. Shopify builds storefront filters from option values. Six navies produce six filter entries, so a shopper filtering for navy sees a fraction of your navy products.
Feeds behave unpredictably. Google and Meta use option values to understand variants. Inconsistent values produce inconsistent matching, and the failures are silent.
Alerts and automation break. Any rule written against an option value — a back-in-stock trigger, a Flow workflow, a bundling rule — works on the products that happen to use the spelling in the rule and silently ignores the rest.
The fix. Maintain a closed list of colour names and a closed list of size names. Every new product draws from those lists. Adding a genuinely new colour means adding it to the list deliberately, not typing it into a product form at eleven at night.
One list, one spelling, one capitalisation. It is an unglamorous discipline and it is worth more than most apps.
Which SKU errors are the most expensive?
1. Blank SKUs. Shopify permits it. Everything downstream then identifies the variant by an internal ID that means nothing to you and appears in no report you can read. Every variant needs a SKU, including free gifts and samples.
2. Reused SKUs. A retired SKU applied to a new product merges two products' histories permanently. There is no clean recovery.
3. Renaming SKUs on live products. Breaks the link to historical orders in third-party tools. If you must re-code a catalogue, do it at a clean break — a new season, a new range — and keep the old codes on the old variants.
4. One product where there should be several. A product carrying four unrelated colourways with different photography, different price points and different audiences is usually four products. The 2,048-variant ceiling has made this error easier to commit.
5. Several products where there should be one. The inverse. Each size listed as its own product destroys variant-level reporting, fragments reviews and inventory, and produces a storefront nobody can navigate.
6. Colour or size as free text. Covered above. The most common and the most quietly expensive.
How do you audit your SKUs in an hour?
Export your products from Shopify admin — Products → Export → CSV, all products.
Open it and run five checks.
Blank SKUs. Filter the SKU column for empty cells. Count them.
Duplicate SKUs. Sort by SKU and look for adjacent identical values. Any duplicate is a live problem.
Colour values. Build a unique list of every value in your colour option column. Read it. The number of near-duplicates is usually the most sobering output of this exercise.
Size values. Same again. Look for M and Medium coexisting.
Format consistency. Sort by SKU. Inconsistent conventions become visible immediately, because they fail to sort into blocks.
An hour of this produces a specific, countable list of problems. That list is worth more than any estimate anyone could give you.
How do you fix SKUs without destroying sales history?
Do not bulk-rename SKUs on products with sales history. The cost usually exceeds the benefit.
A sequence that works:
- Freeze the standard. Write the convention and the closed lists down, in one document, before touching anything.
- Apply it to everything new from today. This alone stops the problem growing.
- Fix blanks and duplicates immediately. These are live faults, not legacy untidiness, and blanks have no history to preserve.
- Normalise option values on your A-tier products. This is safe — changing a colour value from
Navy BluetoNavydoes not break order history the way a SKU change does — and it delivers most of the filtering and reporting benefit for a fraction of the work. - Leave the long tail alone until those products are naturally retired or re-listed.
Most of the benefit sits in the new products and the top sellers. The dormant 2019 range can stay as it is.
The App Ceiling
This section appears in every one of The Operational Guides. It describes where the advice above stops working.
Everything above holds to roughly £1m–£1.5m in annual revenue. Past that point the constraint changes, and it changes in a way that adding further apps does not address.
Apps are built to be sold to many stores. That is what makes them affordable, and it is also what limits them: an app can only act on the data inside its own boundary. Your forecasting tool does not know what your ad platform is spending. Your ad platform does not know what is out of stock. Your back-in-stock tool does not know what your supplier lead times are. Each app is correct within its own scope and blind outside it.
Below roughly £1m, a person bridges those gaps. Someone looks at the stock report, notices a line is running low, and adjusts. The bridging is invisible because it is absorbed into the founder's day.
Above roughly £1m, three things happen at once. SKU count rises, so there is more to bridge. Order volume rises, so the consequence of missing something rises with it. And the founder's time is now spent on growth rather than operations, so the bridging stops happening reliably. Nothing breaks visibly. Revenue keeps climbing. What changes is that a percentage of it begins to leak in places nobody is looking — advertising spend running against unavailable variants, stock accumulating in the wrong location, returns sitting unprocessed for a week and a half while the item they contain is out of stock and being advertised.
That is not an app problem, and no app solves it, because the solution has to sit between systems rather than inside one. It requires something built for your specific stack, your specific SKU structure, and your specific supplier terms.
There is one asymmetry worth naming here rather than in the other guides. Every other problem in this series can be solved later at roughly the same cost as solving it now. This one cannot. Product data compounds — every month of inconsistent entry is another month of remediation, and remediation is charged at the same rate as the automation you actually wanted. It is the only item in the series where acting early is materially cheaper than acting well.
Where to start
Export the CSV. Run the five checks. Write down the counts.
Then write your convention and your two closed lists on a single page and apply them to everything you list from tomorrow. That page is the highest-return document a store at this size will ever produce, and it takes twenty minutes.