Which Product Facts Belong at Model, Variant and SKU Level?

Learn which product facts should live at model, variant, SKU, batch or item level, how inheritance works and how to avoid duplicated or wrongly scoped data.

LinkedIn X Email

Navigate this page

Direct answer
Why product facts need a scope
The levels in practical business language
Fact scope matters more than labels
Inheritance
Overrides
Practical product fact matrix
Identifiers and levels
Scope and source are separate questions
Common modelling mistakes
How to decide where a new fact belongs
Worked example: one shirt style
Direct questions
Next question
Sources and evidence basis

Direct answer

Put a product fact at the highest level at which it remains true for everything underneath it.

If every sellable version of a product shares the same brand, care instruction or core specification, that fact can often sit at a model or style level and be inherited. If one colour, size, pack configuration, production run or individual item can legitimately differ, the fact needs a lower scope.

The difficult part is that model, variant and SKU are not universal semantic levels. Ecommerce platforms, ERP systems, PIMs and manufacturers use the words differently. A SKU is usually an internal commercial or inventory identifier, not a universal definition of product granularity.

The reliable question is therefore not:

Which database table should this field live in?

It is:

At what scope is this fact actually true?

That is the basis for inheritance, overrides, identifiers and change control.

Why product facts need a scope

A product business can hold hundreds of facts about what it sells:

brand
model or style name
material composition
size
colour
weight
barcode
country of manufacture
supplier
packaging
price
certification
environmental figures
care information.

Those facts are not all true at the same level.

A style name may describe an entire range of sellable configurations. A colour is normally specific to one branch of that range. A barcode may identify a particular trade item. A factory may apply to one production run. A serial number may belong to one physical unit.

If these levels are ignored, two common failures appear.

Duplication: the same shared fact is copied into every SKU and then drifts.

False inheritance: a higher-level value is assumed to apply to every child even when one child is different.

A useful product model therefore needs a scope for each important fact.

The levels in practical business language

These labels are useful, but they are not a global taxonomy.

Product family or range

A broad commercial grouping.

A range may collect related products under one proposition, collection or family name. It can be useful for merchandising and navigation but may be too broad to own detailed technical facts.

Model or style

A model or style usually represents the core product design or specification that several sellable configurations share.

For an apparel example, one shirt style might share:

style name
core design
general care method
base construction.

Whether composition also belongs here depends on whether every variant genuinely shares it.

Variant

A variant is a meaningful configuration of a product.

Common variation dimensions include:

size
colour
material
finish
pack size
market configuration.

Shopify, for example, treats combinations of option values such as size and colour as variants. That is documented Shopify system behaviour, not a universal industry law.

SKU

A stock keeping unit is normally an internal code used to identify and manage stock or a sellable configuration.

An SKU often maps one-to-one to a variant, but it does not have to define a separate semantic layer in the product model.

Shopify explicitly distinguishes SKUs from barcodes and describes SKUs as internal inventory codes. Its documentation recommends unique SKUs for product variants. Other businesses may use a different commercial convention.

So:

Variant describes a configuration. SKU usually identifies a commercial or inventory record for a configuration.

They may align. They are not synonyms.

Batch or lot

A batch or lot groups physical production output for traceability.

It can carry facts such as:

production date
manufacturing plant
raw-material lot
supplier lot
inspection result
temporary process condition.

GS1 defines its batch/lot identifier as information a manufacturer considers relevant for traceability and explicitly notes that batch/lot is not part of the unique identification of the trade item itself.

Individual item

An item-level record belongs to one physical unit.

Typical examples include:

serial number
item-specific repair history
item condition
warranty event
individual lifecycle state.

Not every product category needs item-level data.

Fact scope matters more than labels

Two businesses can describe the same physical reality with different software language.

Business A may have:

style -> colour/size variant -> SKU

Business B may have:

model -> SKU

Business C may have:

product family -> model -> option combination -> material code -> warehouse SKU

The names differ. The core governance test does not:

What is the smallest group of products for which this value remains true without exception?

That is the fact's truth scope.

Inheritance

Inheritance lets a lower-level record use a fact maintained at a higher level.

Suppose every version of a shirt shares:

brand = North Harbour
care = machine wash 30°C
core fabric = 100% cotton.

Instead of repeating those values across 24 size/colour SKUs, the model can own them and the variants can inherit them.

That reduces maintenance and drift.

But inheritance is only safe when the fact is truly shared.

Inherit because the fact is common, not because copying it is convenient.

If one variant is different, the model needs either a lower-level value or a controlled override.

Overrides

An override is a lower-level value that intentionally replaces an inherited higher-level value.

Example:

Model composition: 100% cotton

Stretch variant composition: 98% cotton / 2% elastane

The stretch variant should not silently inherit the model's composition.

Another example:

Model manufacturing country: Portugal

Batch 2026-09-A: Turkey

If the manufacturing location genuinely changed only for that run, the lower truth scope is the batch.

An override needs governance. At minimum, a business should know:

which higher-level value is being overridden
the lower scope
why the exception exists
evidence supporting it
when it became effective.

Practical product fact matrix

This is an example framework, not a mandatory placement standard.

Product fact	Often model/style?	Often variant?	Often SKU?	Batch/item relevance	What determines scope	Common mistake
Brand	Yes	Sometimes	Rarely	Rare	Whether brand differs between sellable configurations	Repeating it in every SKU with no control
Model/style name	Yes	Sometimes	Sometimes	Rare	Commercial naming structure	Treating SKU code as model identity
Colour	Rare	Yes	Often represented on SKU	Rare	Whether colour defines a sellable configuration	Storing colour only in free-text title
Size	Rare	Yes	Often represented on SKU	Rare	Whether size creates a separate sellable configuration	Confusing size with the SKU identifier itself
Composition	Yes if genuinely shared	Often	Sometimes	Sometimes	Whether materials differ by colour, size, market or run	Assuming one style composition applies to all children
Weight	Sometimes	Often	Often	Sometimes	Whether configuration, packaging or production variation changes weight	Keeping one model weight when variants materially differ
GTIN/barcode number	No universal rule	Common for trade-item variant	Common mapping	Different identifier at batch/item if needed	Identifier standard and trade-item definition	Equating GTIN with SKU
Internal SKU	Not usually	Often maps to variant	Yes by definition in many systems	No	Inventory/commercial convention	Treating SKU as a universal semantic level
Country of manufacture	Sometimes	Sometimes	Sometimes	Often	Where the actual unit or run was made	Setting one country at model level because it is the usual factory
Supplier	Sometimes	Sometimes	Sometimes	Often	Whether sourcing differs by configuration or run	Treating supplier as part of product identity when it is only provenance
Price	Sometimes	Often	Often	Rare	Channel, market, customer and sellable configuration	Treating a channel price as timeless product truth
Packaging	Sometimes	Often	Often	Sometimes	Pack count, material, market and logistics configuration	Mixing product and packaging identity
Certification status	Sometimes	Sometimes	Sometimes	Sometimes	Scope of certificate and applicable product configuration	Applying a certificate to products outside its scope
Care information	Often	Sometimes	Sometimes	Rare	Whether material/construction changes care requirement	Repeating care copy instead of controlling the rule
Carbon figure	Sometimes	Often	Sometimes	Sometimes	Calculation boundary, product configuration and period	Publishing one number without scope or method
Serial/item state	No	No	No	Item	Individual physical object	Storing lifecycle state on the model

Identifiers and levels

Identifiers tell you what record or object you are referring to. They do not remove the need to understand fact scope.

Internal model ID

An internal identifier for the model or style record.

SKU

An internal commercial or stock identifier. A SKU is not automatically a GTIN, UPI or regulatory identifier.

GTIN

A GS1 Global Trade Item Number identifies a trade item in the GS1 system.

A GTIN can map to a sellable product configuration, but GTIN assignment follows GS1 trade-item rules, not an organisation's arbitrary data hierarchy.

Batch or lot identifier

A traceability identifier for a production grouping. GS1 explicitly distinguishes this from the unique identity of the trade item.

Serial or item identifier

An identifier that distinguishes an individual physical unit where item-level identification is required or useful.

Regulatory identifier

A law or regulatory system may require its own identifier or may allow an existing recognised identifier. That question must be checked against the specific regime.

For Digital Product Passports, use the separate Digital Product Passport Identifiers resource for the regulatory identifier question. Do not infer that a commercial SKU is automatically a DPP unique product identifier.

Scope and source are separate questions

Knowing where a fact is true does not tell you where it came from.

A composition fact may be variant-level but supported by:

supplier declaration
approved technical specification
laboratory test.

A weight may be SKU-level but maintained in:

ERP
PIM
product development system
controlled measurement process.

This is why product-data architecture needs two separate controls:

fact scope
fact authority and evidence

The next question is therefore: Which System Should Own Each Product Fact?

Common modelling mistakes

Putting everything at SKU level

This avoids inheritance decisions but creates duplication, maintenance cost and drift.

Putting everything at model level

This is tidy until one colour, size, supplier or production run differs.

Treating variants as universally defined

A variant is a useful concept, but ecommerce, ERP and manufacturing systems do not all implement it in the same way.

Treating the SKU as the product

An SKU is usually a business identifier. It does not by itself tell you whether the underlying truth is model, variant, batch or item-level.

Copying inherited values instead of inheriting them

Copied values look correct on day one and become inconsistent later.

Allowing overrides with no evidence

An override should represent a real lower-level exception, not an unexplained manual edit.

Mixing identity and traceability

A supplier lot, production batch and serial number answer different questions from a model ID or GTIN.

How to decide where a new fact belongs

Use this sequence.

1. Define the fact precisely

Do not start with a vague label such as "weight".

Ask:

net product weight?
packaged shipping weight?
measured item weight?
declared regulatory weight?

Different facts can have different scopes.

2. Find the first level at which exceptions appear

If all variants share the value, model-level may work.

If one variant differs, move the fact down to variant scope.

If variation only appears by production run, batch may be the right scope.

If every physical unit can differ, item-level may be needed.

3. Check whether the lower level is commercially distinct

If the change creates a different sellable configuration, the business may need a separate variant or SKU.

That is a commercial decision and may also interact with identifier standards.

4. Check evidence scope

The source document must support the same scope as the fact.

A certificate covering one factory and one model should not be used as evidence for every product in a range.

5. Define inheritance and override rules

State which lower records inherit, when they may override and what evidence an override needs.

Worked example: one shirt style

Consider the Harbour Oxford Shirt.

Model/style

Shared across the range:

model name: Harbour Oxford Shirt
brand: North Harbour
base construction: long-sleeve Oxford shirt
standard care instruction: machine wash 30°C.

Variants

The style is sold in:

navy
white
green

and sizes:

The business treats every colour/size combination as a sellable variant.

SKUs

Each sellable combination has an internal SKU, for example:

HOS-NVY-M

The SKU identifies the stock record. It does not make every fact SKU-level.

Composition exception

Navy and white are:

100% cotton

Green is:

98% cotton / 2% elastane

Composition cannot safely remain as one universal model-level fact unless the green variant has an explicit override.

Manufacturing batch

Most production is made in Portugal.

A specific replenishment run is produced in Turkey.

If that change applies only to the run rather than all future green shirts, the manufacturing-country fact belongs to that batch or another lower production scope.

Item state

One returned navy medium shirt is repaired and resold.

Its repair history belongs to that physical item, not to every navy medium shirt.

The model has not changed. The item's lifecycle state has.

Direct questions

What is the difference between model, variant and SKU?

A model or style usually describes a shared core product. A variant is a meaningful configuration of that product. An SKU is usually an internal commercial or inventory identifier for a sellable configuration. The exact terminology varies by organisation and system.

Is colour a variant?

Often, yes, when colour creates a meaningful sellable configuration. It is not a universal rule. The useful question is whether colour changes the product configuration your systems and customers need to distinguish.

Is size a variant or SKU?

Size is an attribute. A size value can help define a variant. The sellable size configuration may then have an SKU.

Should composition live at SKU level?

Only if that is the right truth scope. If every SKU under a style shares the composition, maintaining it once at model level may be better. If one variant differs, use lower-level ownership or an override.

Can one fact apply to every variant?

Yes. That is exactly when inheritance is useful.

Is GTIN the same as SKU?

No. A SKU is typically an internal stock code. A GTIN is a GS1 trade-item identifier governed by GS1 rules.

What happens when one variant differs from the model?

The lower-level record should carry a controlled override or its own value. Do not let the model value silently overwrite a genuine exception.

Should batch information live in the PIM?

That depends on the architecture and use case. Batch information needs a governed home and traceable relationship to the product, but it does not universally have to be mastered in the PIM.

Next question

Once the fact scope is right, the next decision is:

Which System Should Own Each Product Fact?

Keep exploring

The questions this page usually raises next.

Also worth reading

CompareSmall businessHow to Organise Product Data Without a PIM: A Small-Business Operating ModelIf your catalogue is managed with lightweight systems, see the small-business operating model.

Does this reach your products?

Give ActivateDigital one product and it works out which obligations apply from the product's own character, and says which it cannot decide.

Check a product How a value is decided

Help someone else make sense of product passports.

LinkedIn X Email

Sources and evidence basis

Industry standards / conventions

GS1 GTIN Management Standard, Release 1.1, September 2023
GS1 General Specifications, current repository version 26.0.0
Schema.org ProductGroup, which represents a group of products varying by defined properties and allows shared properties to sit on the group

Documented system behaviour

Shopify Help Centre, Variants
Shopify Help Centre, Using SKUs to manage your inventory

Existing ActivateDigital canonical context

Digital Product Passport Granularity: Model, Batch or Item?
Digital Product Passport Identifiers
Is Your Product Data Ready for a DPP?
Passport Evidence: How We Know, and What a Blank Means

The placement rules in this article are ActivateDigital governance recommendations and synthesis, not a universal product-data standard.