As a catalog grows, the same item may appear as a standalone product in an online store, as a variant on a marketplace, and as an inventory item in an internal system. The result is often duplicated information, relationships that are difficult to maintain, and errors when identifying what is being sold. The solution starts before connecting channels: define what each entity represents and which data belongs to it.
A useful model separates the identity of a product and its variants from the commercial terms applied in each channel. This makes it possible to maintain a shared source of information without requiring every system to present the catalog in the same way. The key decision is not how many records to create, but which differences actually change what the customer is buying.
Distinguish products, variants, and offers
The product represents a shared family or commercial concept: it brings together items with a common identity, general description, and core attributes. For example, a backpack in a particular model may be the product, while its color or capacity combinations are variants.
The variant is a purchasable unit distinguished by a defined combination of attributes, such as size and color. It must be identifiable without ambiguity and, where relevant, linked to inventory, a barcode, and a selection on the product page. If two units are not interchangeable when making a purchase or preparing an order, they are probably not the same variant.
The offer describes how a variant is sold in a specific commercial context: channel, seller, price, availability, or delivery terms. An offer should not automatically become another product. The same variant can have different offers in different channels without changing its identity.
This separation helps answer different questions: what the item is, which exact option is being purchased, and under what terms it is offered. If a system does not have an entity called “offer,” the model can be represented another way, but it is useful to preserve this conceptual distinction.
Decide whether a difference deserves a variant
A difference deserves a variant when customers choose between options of the same item and the organization can describe them using consistent attributes. Size, color, capacity, or finish often fit, provided they preserve the product’s purpose, identity, and main description. The selection should lead to a specific item that can be purchased and managed.
Create a separate product when the commercial identity changes substantially. This may happen if the difference changes the main use, compatibility, composition, package contents, or the way the item is presented. A separate product may also be necessary if each version needs a description, classification, or relationship to other products that cannot be expressed as an option within the same product.
To resolve borderline cases, ask these questions:
- Does the customer expect to choose between options on one page, or to compare different items?
- Are the attributes consistent? If the difference needs its own narrative rather than a selectable option, it may be another product.
- Can each option be purchased and prepared separately? If so, each sellable combination needs its own variant identity, even when grouped under one product.
- Does the relationship make sense in every channel? If a channel does not support variants, each one can be presented separately there while the relationship is retained in the master catalog.
Do not decide solely on the basis of the structure a platform allows. A channel may impose presentation limits, but it should not dictate the catalog’s internal identity by itself.
Assign stable, unambiguous identifiers
Define one identifier for the product and another for each variant. The first groups items; the second identifies the purchasable combination. A variant should not use its display name, position in a list, or a value that may change, such as its price or promotional title, as its identifier.
The internal identifier must be unique, persistent, and never reused. If a variant is discontinued, retain its historical reference rather than assigning it to another item. Reusing codes can mix orders, inventory, or historical records with a different unit. If commercial or barcode identifiers exist, store them as identifiers with their own meaning and rules; do not assume that they replace the internal key.
Channel identifiers may also be needed to link records. Treat them as external references, not as the master identity: an item may receive a different identifier on each platform. The relationship between the internal variant key and external references should be explicit, verifiable, and maintained by the system responsible for the catalog.
Separate shared attributes from variant-specific attributes
Data that describes the entire family belongs to the product: model name, general description, brand if applicable, category, and shared features. Attributes that determine the specific option belong to the variant: size, color, capacity, or format when those differences define distinct purchasable units.
Establish a clear inheritance rule. A variant can display the product description and add its own values, but a critical field should not have two conflicting values at both levels. If each variant has a different composition, for example, that information cannot be treated as shared data without an explicit exception.
Use controlled vocabularies for shared attributes: the same size should not be recorded using incompatible labels, and color names should not depend on free text without a good reason. Also define which fields are required, which may be empty, and which combinations are valid. This makes it easier to compare, validate, and transform data without confusing real differences with spelling variations.
Model availability and commercial data separately
Availability and price can change without the item itself changing. They should therefore be associated with the offer or relevant context, not used to create a new variant. A variant may be out of stock in one channel and available in another; that difference is commercial or operational, not a new product identity.
Also separate the relevant dimensions: the variant identifies what the unit is; the offer indicates where and under what terms it is available; and stock may depend on a location or inventory system. Not every business needs a separate entity for each dimension, but each must know where every data point resides and which source is authoritative. Avoid copying prices and availability into descriptions or attributes that are interpreted as permanent.
Adapt the catalog to channels without duplicating the source
Channels can support different structures. One may group variants under a single listing, while another may require separate records. Handle this difference through a channel-specific representation or transformation, while preserving the product-to-variant relationship in the master catalog. Separating how an item is published from what the item is reduces the risk of creating duplicate products just to meet a particular presentation requirement.
Before integrating, document master fields, external references, grouping rules, and channel-specific exceptions. Assign an owner to each data point: if two systems can modify the same field without a defined priority, discrepancies are predictable. When a channel cannot express a feature, decide whether to omit it, transform it, or require a review; do not silently reinterpret it as another entity.
Common errors and checks before integration
Orphaned variants without a parent product make presentation and analysis more difficult. Inconsistent attributes prevent equivalent options from being recognized. Reused references can link historical data to the wrong item. It is also common to duplicate a product because a channel uses a different structure, or to turn an offer with a different price into a new variant.
Before connecting systems, review a representative sample of the catalog and check that:
- Each product groups items that share an understandable identity.
- Each variant corresponds to a purchasable unit and has its own stable, unique identifier.
- Attributes that distinguish variants have defined values and valid combinations.
- Inherited data does not contradict variant-specific values.
- Prices, availability, and commercial terms are distinguished from the item’s identity.
- Channel references point to the correct variant and do not replace the internal key.
- Presentation exceptions are documented without changing the master model.
A consistent catalog does not require every channel to display items in the same way. It requires the business to recognize the same product and variant across all its systems, and to separate that identity from the specific way they are sold. When these rules are clear before integration, later adaptations are easier to control and there are fewer duplicates to correct.