The Ecommerce Product Data Model: Variants, Options And The Three Option Wall
Platforms come and go. Your product data outlives all of them.
That is worth sitting with, because teams routinely spend nine months selecting a platform and about a week deciding how their catalogue is structured. Then they spend the next five years working around the consequences of that week.
This piece is about the modelling decisions underneath a catalogue: what an option is, what a variant is, why almost every mainstream platform stops you at three option axes, and what to do when your business genuinely needs four. It is also about the moment those decisions send a bill, which is usually the middle of a migration.
The vocabulary gets used loosely, and the looseness causes real confusion in requirements documents. Fix it once.
An option is an axis of choice. Colour is an option. Size is an option. Material is an option. Options are the questions you ask the customer.
A variant is one specific combination of answers across every option. Blue, Large, Cotton is a variant. If you have three colours, four sizes and two materials, you have twenty four possible variants, whether or not you stock them all.
A SKU is the identifier for a thing you can hold in a warehouse and count. In simple catalogues one variant equals one SKU. In practice they diverge more often than people expect, which is where a lot of inventory pain originates.
And a product is the thing a customer thinks of as one item, which is a merchandising judgement rather than a technical fact. This is the part that trips teams up, because the platform makes you commit to it early and it is expensive to change later.
The relationship between these four is the data model. Everything else, including search facets, inventory sync, pricing rules and feed generation, is downstream of getting it right.
Most mainstream platforms cap you at three option axes per product. Shopify does. Several others do the same or something close to it.
In October 2025 Shopify raised its variant ceiling from 100 to 2,048 per product, across every plan rather than only the top tier. That was a genuinely useful change and it removed a real constraint for catalogues with deep size runs.
It also did not touch the option limit, which remains three. Two separate ceilings, constraining two different things, and a lot of coverage has treated the first as though it fixed the second.
The distinction matters enormously if you sell apparel. Consider trousers with colour, waist, inseam and fit. That is four axes. The number of resulting combinations might be well under 2,048, so the variant ceiling is nowhere near being a problem. You still cannot model it, because you have run out of option slots. Raising a limit you were not hitting does nothing for a limit you are.
There is a further constraint worth knowing about on Shopify specifically: the theme layer caps product.variants at 250 in Liquid for performance reasons, so a product with 2,000 variants needs a different frontend pattern rather than a straightforward loop. The ceiling being available in the data does not mean the storefront renders it without work.
Footwear runs into the same wall with size, width and colour, then a style attribute. Furniture hits it with fabric, frame, configuration and orientation. Industrial parts hit it hardest of all. This is not an edge case; it is the normal shape of several large categories.
Every workaround is a trade. Know which one you are making.
Split into multiple products. Model colour as a separate product, so each colour becomes its own product page with three remaining axes for waist, inseam and fit.
The cost: your catalogue count multiplies, and colour becomes invisible to filtering within a product. Customers lose the colour swatch on the product page unless you build linking between the sibling products yourself. Reviews, and any ratings you have earned, fragment across the siblings. On the plus side, each colour gets its own indexable URL, which some merchants genuinely want for search.
Combine two axes into one option. Make a single "Size" option holding values like 32/30, 32/32, 34/30.
The cost: filtering dies. A customer who wants a 32 waist in any inseam cannot express that, because the platform sees one flat list of opaque strings rather than two axes. It is the cheapest workaround to implement and the most damaging to the shopping experience, which is a bad combination because it is also the most commonly chosen.
Use a customisation or personalisation layer. Add the fourth axis as line item properties or through an app.
The cost: the fourth axis stops being real inventory. You cannot hold stock against it, you cannot report on it cleanly, and your warehouse system may not receive it in a usable form. Fine for engraving text. Not fine for a physical dimension you stock.
Change platform. The honest option when the model genuinely needs four or more axes.
The cost: everything covered in a full replatform, which is substantial. Worth it when the constraint is permanent and central to what you sell. Not worth it for one seasonal product line.
There is a fifth path that deserves a mention because it is underused: keep the storefront platform, usually decoupled from the backend, and move the authoritative catalogue somewhere that can represent the real model, then project a simplified view into the storefront. You accept the three option limit as a presentation constraint while keeping your true data intact for operations, feeds and reporting. It is more work than a workaround and much less than a migration.
Before reaching for a workaround, check that the model is right, because a surprising number of option limit problems are self inflicted.
A useful test: does the customer decide it, or does the business? Options are customer decisions. If a shopper picks it on the product page, it is an option. If the business picks it before the shopper arrives, it probably belongs somewhere else, as an attribute, a category or a separate product.
A second test: would a customer expect to find these on one page? Nobody expects a 32 waist and a 34 waist to be different products. Most people do expect a raincoat and a parka to be different products even if they share a fabric.
Three specific things that are commonly modelled as options and usually should not be.
Pack size for the same item. A six pack and a twelve pack often have different GTINs, different weights, different shipping profiles and different margins. They behave like separate products with linked identity, not like a colour.
Anything with its own barcode and its own reorder cycle. If procurement treats it as a separate line, your catalogue probably should too.
Attributes used only for filtering or reporting. Sleeve length, care instructions, country of origin, sustainability marks. These are attributes and facets, not options. Filing them as options burns a scarce slot on something the customer never selects. This is the single most common cause of a store hitting the wall without needing to, and it is often fixable in an afternoon.
The audit is mechanical and takes about an hour on most catalogues.
Export every product with its option names and the distinct values under each. Then look for three signatures.
An option with exactly one value across every product that uses it. A colour option where every product is "Black" gives the customer nothing to decide. It consumes a slot and renders a dropdown with one entry, which also clutters the buy box.
An option whose values are never independently in stock. If choosing Fit never changes availability, price or barcode, it is describing the product rather than selecting a version of it.
An option that duplicates a category. If "Type" holds values that match your navigation tree, the taxonomy is doing that job already and the option is a second copy that will drift out of sync.
Any option matching one of those signatures is recoverable. Move it to an attribute, keep it in your facets so customers can still filter on it, and you have a slot back without touching the platform or the storefront. On the catalogues where this works, it turns a migration conversation into a data cleanup, which is a substantially better outcome for everyone except whoever was quoting the migration.
Bundles look like a merchandising feature and behave like an inventory problem.
The core question is whether a bundle has its own identity. Two very different answers.
A virtual bundle is a presentation of components. It has no stock of its own. Its availability is computed from its components, and selling one decrements each of them. Ordinary stock arithmetic, and reporting stays clean because revenue attributes to the components.
A physical bundle is assembled ahead of time. It has its own SKU, its own barcode and its own shelf location. Stock is held against the bundle itself, and the components inside it are no longer available individually until somebody breaks it apart.
Most platforms handle one of these well and the other badly. The failure is quiet and expensive: a store that models a physical gift set as a virtual bundle will oversell it, because the system believes the components are still available separately when they are physically sealed in a box in a warehouse.
Ask two questions early. Does this bundle exist as an object somebody can pick up, and can it be assembled or broken apart after it is created? If it can be assembled and disassembled, you need conversion logic between the bundle and its components, and that logic belongs in inventory, not in the storefront.
Returns are where the modelling choice sends its second bill. A customer returns a three item gift set with one item missing. Against a virtual bundle the answer is straightforward, since you restock the two components you received and refund accordingly. Against a physical bundle there is nothing sensible to restock, because the sealed unit no longer exists and the remaining pieces are loose stock that your system does not believe it has. Somebody has to decide, per return, whether to break the bundle down in the system, and if nobody has designed that path it gets done through manual stock adjustments. Those adjustments are invisible to reporting and they are how inventory accuracy quietly degrades over a season.
Decide it before launch. The cost of getting it wrong does not appear on day one; it appears in the first returns cycle, by which point the workaround is already habit.
Here is where the data model sends its bill.
Teams estimate a migration by estimating the build. The build is rarely what slips. What slips is the discovery, usually in week seven of a replatform, that the catalogue contains four spellings of "Colour", weights recorded in three units, and a size attribute holding L, Large, large, L/G and 42 for what is, in the warehouse, the same thing.
None of that mattered before, because the old system enforced nothing. The new one will. And every one of those inconsistencies has to be resolved by a person who knows the products, because no script can safely decide whether 42 is a European size or a waist measurement.
Normalisation is slow, manual, and mostly resists being parallelised, since the decisions have to stay consistent across the catalogue. It is also the work that determines whether search, filtering and merchandising function after launch. A migration that hits its date with unnormalised data has not saved time. It has moved the cost onto the merchandising team and made it permanent.
Two things make it survivable. Start the data work before you choose the platform, because it is valuable regardless of where you land and it tells you what the platform actually has to support. And treat the export as a product with acceptance criteria that run automatically: every product has a category, a primary image, a normalised attribute set and a stable identifier mapping to the old one. Run those checks nightly so the trend is visible on a chart rather than discovered in user acceptance testing.
Product information management gets sold as an enterprise necessity, which is not helpful when you are trying to decide whether you need one. Some concrete thresholds.
A dedicated PIM starts earning its cost when you sell the same products through more than two channels, each demanding a different data shape. Your website, a marketplace, a retail partner's feed and a print catalogue all want different fields, different image ratios and different category taxonomies. Maintaining that from the storefront platform means one channel is authoritative and the rest drift.
It earns it when more than a handful of people edit product data, because you then need workflow, permissions and an audit trail for who changed the price.
It earns it when enrichment is a bottleneck, meaning products sit unpublished waiting for copy, images or attributes, and nobody can see which ones or why.
And it earns it when your catalogue is genuinely large, somewhere past roughly fifty thousand SKUs, at which point spreadsheet driven maintenance stops working regardless of team size.
One channel, one editor, five thousand SKUs, no enrichment queue? You do not need a PIM. You need consistent attribute values, which is a discipline rather than a purchase.
If you are designing rather than repairing, work through this before anyone opens a platform admin.
List your option axes and count them. Only the ones a customer actually chooses. If you land above three, you know now rather than in month four, and it becomes a platform selection criterion rather than an emergency.
Decide where identity lives. Which level carries the barcode, which level carries the price, which level carries stock. In apparel these are often three different levels, and writing that down early prevents a lot of argument later.
Separate options from attributes explicitly. Two lists, on paper. Attributes drive facets, feeds and reporting. Options drive the buy box. Anything on both lists needs a decision, not a compromise.
Decide bundle identity for every bundle type you sell. Virtual or physical, and whether conversion between them is possible.
Name the one identifier that never changes. Everything else can be renamed, restructured or re-merchandised. One stable key per sellable unit is what makes every future migration, feed and integration possible. Losing it is the single most expensive catalogue mistake available.
Half a day of this saves months later, and it costs nothing but the argument.
The data model outlives the platform. Most of the expensive constraints in an ecommerce build trace back to a catalogue decision made quickly by whoever was available, on a Tuesday, four years ago.
If you are hitting a three option wall right now, check the model before you check the workarounds, and before you scope any ecommerce app development around it. A meaningful share of stores at the limit are spending a slot on something the customer never selects, and getting it back is an afternoon of work rather than a migration.
An option is an axis of choice, such as colour or size. A variant is one specific combination across every option, such as blue in large. Three colours, four sizes and two materials give you three options and up to twenty four variants. Platforms usually limit both, and the two limits constrain completely different things.
No, and this is widely misreported. The variant ceiling rose from 100 to 2,048 per product in October 2025, across all plans, which helped catalogues with deep size runs. The limit of three options per product did not change. If you sell trousers with colour, waist, inseam and fit, you have four axes and perhaps a few hundred combinations, so the variant ceiling was never your problem and raising it changes nothing for you.
Four workarounds, each with a real cost. Split into multiple products, which multiplies your catalogue and fragments reviews. Combine two axes into one option, which is cheapest to build and destroys filtering. Use a personalisation layer, which means the fourth axis is no longer stockable inventory. Or change platform. There is also a fifth path: keep the storefront and hold the authoritative catalogue in a system that can represent the real model, projecting a simplified view into the store.
A variant, in almost every case, because customers expect to find sizes of the same item on one page. The useful test is who decides. If the shopper picks it on the product page, it is an option. If the business decides it before the shopper arrives, it is likely an attribute, a category or a separate product. Pack sizes and anything with its own barcode and reorder cycle usually behave like separate products.
Not by default. A PIM starts paying for itself when you sell through more than two channels that each need a different data shape, when more than a handful of people edit product data and you need workflow and an audit trail, when enrichment is a visible bottleneck, or when the catalogue runs past roughly fifty thousand SKUs. One channel, one editor and a modest catalogue means you need consistent attribute values, which is a discipline rather than a purchase.
Because bundles come in two kinds that behave differently. A virtual bundle has no stock of its own and computes availability from its components. A physical bundle is pre-assembled with its own SKU and barcode, holds its own stock, and its components are not separately available until somebody breaks it open. Modelling a physical gift set as a virtual bundle causes overselling, because the system still believes the components are on the shelf.
Vikas has around fifteen years of experience building software and now builds generative AI systems at Zyneto. His work covers retrieval augmented generation, agentic AI, knowledge graphs, AI memory, and the evaluation and guardrails that decide whether any of it is safe to put in front of customers. He has shipped enterprise copilots, document AI, chatbots and predictive analytics for e-commerce, fintech and marketing teams, and works day to day in Python, JavaScript and SQL. He follows multimodal models, business process automation and enterprise AI security closely, and mentors engineers moving into AI. He writes about architecture, inference cost and the failure modes that only show up at production scale.
Share your details and we will talk soon.
Be the first to access expert strategies, actionable tips, and the trends actually shaping the digital world. No fluff - just practical insights delivered straight to your inbox.
Dive into our blog and stay ahead of the curve with expert perspectives, future-ready trends, and tech tips written for decision-makers and doers alike.
