Product Attribute Standards for Fashion PLM That Work Across Markets

When a sales report shows “Navy”, “navy”, “Dark blue” and “Marine” as four separate colours, the problem did not start in the report. It started in the product data, when four people typed a colour into a free-text field. Most of the reporting clean-up I have done in fashion traces back to product attributes that were never standardised. This article covers which attributes a fashion brand needs, how to structure the dictionary behind them and the rules that keep colour, season and composition consistent across markets.

Which Product Attributes a Fashion Brand Needs in PLM

Product attributes are the characteristics that describe a product and let people and systems tell products apart. Some are tangible, such as fabric or length; some are intangible, such as price tier or lifecycle status. In a PLM they are stored as structured fields with allowed values. I find it most useful to split them into four types, because each type has a different owner and must be complete at a different moment:

• Technical attributes: materials, weight, measurements, construction details. Owned by product development; needed before the sample is approved.
• Descriptive attributes: colour family and colour name, fit, length, neckline, sleeve type, pattern. Owned by design and buying; needed before the range is fixed.
• Commercial attributes: department, category, subcategory, season and drop, price tier, core or fashion status, channel, launch date. Owned by buying and merchandising; needed before the buy.
• Legal attributes: fibre composition, care instructions, country of origin, sustainability claims. Owned by quality or compliance; needed before labels are printed.

Commercial attributes are the ones most often forgotten in PLM projects, because PLM is seen as a design tool. Yet they are exactly what planners and analysts filter on. If price tier or core status lives only in a buyer’s spreadsheet, every report has to rebuild it by hand.

Product Attribute Dictionary Structure

The attribute dictionary is the single list of every attribute and every value it may take. Product attribute management is mostly the work of keeping this list correct. For each attribute, the dictionary should record:

• A code and a name, plus a one-sentence definition that answers “what counts as this?”.
• The data type: value from a list, number with a unit, date or yes/no. Free text only for real descriptions, never for anything people filter on.
• The allowed values, each with its own code, translations per language and an active or retired status.
• Whether one or several values are allowed, and at which stage gate the attribute becomes mandatory.
• The owner who approves new values, and the mapping to each channel, such as the online shop or a marketplace.

Codes, not names, go into the systems. Names can then be corrected or translated without breaking any report, because the history is stored against the code.

Colour Attribute Rules in a PLM Dictionary

Colour is the attribute that breaks first, because everyone has an opinion about it. I separate it into three fields with different jobs:

• Colour family: a short, stable list, around fifteen values such as black, white, blue, green or red. This is what customers filter on and what reports group by.
• Colour name: the commercial name the customer sees, such as “ink blue” or “sage”, chosen from a controlled list that the owner extends on request.
• Colour code: the precise shade reference agreed with suppliers, used by product development and quality.

Every colour name belongs to exactly one family, so a new commercial name never creates a new filter value. Multicolour and print need their own rule, for example the family of the dominant colour plus a pattern attribute. And the colour never goes into the style description as well, because then two fields disagree sooner or later.

Season Code Rules Across Markets

A season code looks simple until the same product sells at different times in different markets. My rule is to keep one global season code, the season the product was designed and bought for, in a fixed format such as SS27 or AW27. Everything else is a separate attribute:

• Drop or delivery window within the season, as its own list.
• Launch date per market, because one market may start selling weeks after another.
• Carry-over: the first season stays unchanged, and the seasons in which the style is active are stored as a list, rather than creating a new code each time.

If markets overwrite the season code to match their own calendar, the same style appears as new in one report and as carry-over in another, and sell-through by season stops being comparable.

Composition Fields Without Free Text

Composition is a legal attribute, so errors are costly. In the EU, fibre names on labels must follow the textile labelling regulation, and each language has its own wording. Free text such as “95% cotton 5% elastane” cannot be translated or checked reliably. I store composition as rows instead: component, fibre from the dictionary and a percentage.

Style     Component  Fibre      %
S27-1042  Shell      Cotton     95
S27-1042  Shell      Elastane    5
S27-1042  Lining     Polyester 100

' Check in Excel: each component must add up to 100
=SUMIFS(Comp[Percent], Comp[Style], A2, Comp[Component], B2) = 100

The label text in every language is then generated from these rows. The same data feeds the online product page, sustainability reporting and any analysis of fibre mix, without anyone retyping it.

How to Agree Product Attribute Standards with Markets

The technical part is the easy half. The harder half is getting markets and departments to stop creating their own values. The approach that has worked best for me:

• Start with evidence: pull every distinct value of an attribute from all systems and count how many products use each. A list of 60 colour spellings convinces people faster than a presentation.
• Propose target values and a mapping from every old value to a new one, then review it with each market in a short workshop.
• Name one owner for the dictionary, usually product data or product operations, with a simple request process and a promised response time.
• Make attributes mandatory at stage gates in PLM, so incomplete products cannot move to the next step.
• Publish a data quality report: completeness per attribute, season and market. What is measured every week gets fixed.

For the report, I use a simple completeness measure in Power BI and show it as a matrix of attributes against seasons.

Attribute Completeness % :=
DIVIDE (
    CALCULATE ( COUNTROWS ( ProductAttributes ), NOT ISBLANK ( ProductAttributes[ValueCode] ) ),
    COUNTROWS ( ProductAttributes )
)

An attribute standard is never finished; new categories and channels will keep asking for values. But once the dictionary has an owner and the gates are in place, the clean-up stops being a project and becomes a routine. The difference between PLM and PIM, and where each attribute should live, is the subject of a separate article on this blog.