What the workaround actually costs
The operators who have tried to solve this with separate listings know what happens next.
You create two products: SKU123 for men, SKU124 for women. Same physical item. Different listings. Different content. And then a women's version sells. The men's stock does not move. They are separate records. One sale does not update the other. Operators in Shopify Community describe exactly this: "when someone purchases a women's t-shirt, the men's t-shirt inventory doesn't decrease, even though they're the same underlying product." No platform-native solution confirmed. Workarounds: third-party bundle apps, tags, accepting fragmented stock. None work cleanly.
At small catalogue sizes this is manageable. At scale, the gap between SKU123 and SKU124 stops being visible to anyone except the person who created them. Which products are actually the same item? Specialist knowledge. SKU-number hacks. Conventions that live in one person's head. When that person leaves, the understanding goes with them.
How alias products work
An alias product is a listing that inherits its inventory identity from a parent SKU while carrying its own content, images, and channel assignments. The listing system sees a separate product. When correctly integrated with an order management system, orders map back to the original SKU for fulfilment. Inventory tracks to one record. Listings are independent. This is one of several product types supported by OneSila built specifically for multi-channel ecommerce operations.
In practice: SKU123 is the sunglasses (the parent). You create SKU123b as a women's alias and SKU123c as a men's alias. You can keep the unisex listing too, or retire it. Each alias has its own title, its own images, its own audience targeting. From the outside (the marketplace, the website, the OMS) they look like three separate products. Inside OneSila, the relationship is always visible.
Creating an alias in OneSila takes two paths: open a product and duplicate it as an alias, or create a new product and select the alias type. At creation you choose what to inherit from the parent (attributes, media, content) and after that the alias manages its own data independently. It has its own EAN code, so it looks like a complete independent product to any external system. Navigation is bidirectional: from the parent you can see all aliases; from any alias you can navigate back to the parent. Attributes do not auto-propagate from parent to alias after creation: this is by design. If they did, you could not manage the differences that make each alias useful.
More than audience targeting
The audience targeting use case is the obvious one. But there is a second pattern that comes up repeatedly.
Many marketplace attribute fields accept only one value. A listing can have one theme. One gender target. One age group. If your product legitimately belongs to more than one (a costume for both Halloween and St Patrick's Day, a bowl that works for dogs and cats) you are forced to choose which audience to sacrifice in a single listing.
Aliases remove that forced choice. The parent SKU is the inventory anchor. Each alias carries a different single-value attribute and targets a different audience. Halloween costumes show up in Halloween searches. The same product, as a different alias, shows up in St Patrick's Day searches. The physical item and the stock are unchanged. Only the positioning differs.
We have seen operators run six or seven aliases from one parent. In some cases this appears to be used for Amazon listing management in ways beyond the original design: the pattern is observable even when the mechanism is not fully understood. Products find uses their creators did not plan for.
What it takes to set up
The PIM side is straightforward. The OMS side requires attention. When an alias SKU is sold, the order management system must translate it back to the parent SKU so inventory is deducted correctly. Some systems handle this out of the box: Linnworks, for example, handles the mapping when the alias SKU is sold for the first time. Other OMS and ERP systems may need custom integration work. Assess OMS compatibility before going live with aliases, not after.
When to reach for it
Alias products are not a day-one decision. The typical pattern: complete the original product first. Publish it. Sell from it. And at some point, when the single listing can no longer serve all the audiences, all the category positions, all the attribute values the product legitimately occupies, that is the trigger. The mold no longer fits. That is when an alias makes sense.
Starting with aliases before you feel that constraint adds complexity without benefit. Growing into them when the constraint appears is how operators find the model naturally.
The unisex listing was the data model talking. Now you have a data model that can do more than that.
If you want to see alias products in practice, book a demo or explore the OneSila Academy to see how product types work in the platform.
Frequently Asked Questions
What is an alias product in ecommerce?
An alias product is a distinct listing that inherits its inventory identity from a parent SKU. It has its own content, images, and audience targeting, visible externally as an independent product, while all inventory and fulfilment traces back to the parent. It allows the same physical product to appear in multiple audience-specific positions without creating separate inventory records.
How do I manage inventory for unisex products on different marketplaces?
The cleanest solution is an alias product model: one parent SKU for inventory, with alias listings for each audience (men's, women's, or both plus the unisex original). Each alias is independent for content and targeting; inventory deducts from a single record. Platform workarounds like separate SKUs or third-party bundle apps tend to produce fragmented stock or specialist knowledge dependencies at scale.
Can I have the same product listed differently for men and women without breaking inventory?
Yes, with an alias product model. The parent SKU holds the inventory. Each alias (men's version, women's version) has its own listing content and appears as a separate product to marketplaces and customers. When either alias sells, the order maps back to the parent SKU for fulfilment. The inventory record is shared; the listings are independent.
What happens to inventory when an alias product is sold?
The OMS or ERP translates the alias SKU back to the parent SKU at the point of order processing. Inventory is deducted from the parent record, not the alias. This requires SKU mapping in the OMS: some systems (Linnworks confirmed) handle this out of the box with first-time mapping; others may require custom integration work.
How many alias listings can I create from one product?
There is no fixed limit. In practice, two or three aliases per parent is common (for example, keeping a unisex listing while adding men's and women's versions). We have seen operators run six or seven aliases from one parent for more complex positioning requirements.
What is the difference between alias products and duplicate SKUs?
Duplicate SKUs create separate inventory records for what is physically the same product. When one sells, the other's stock does not update. Inventory fragments across records. At scale, the relationships between duplicate SKUs exist only in someone's memory, turning into specialist knowledge and SKU-number hacks. Alias products maintain a single inventory record (the parent) while allowing independent listings. The inventory problem does not exist; the relationship is system-visible, not person-dependent.