Product data standardization: required attributes by category

Product data standardization starts with an attribute model per category: for each product type, the company decides which fields are always required, which depend on the category, which apply only to a given channel and which are optional. The category chosen at entry then triggers those fields, and the item does not move forward until it is complete for its destination.

A common scene in a product data team: sales needs a new item set up in a hurry. The analyst fills in the description, tax code, unit and price. Three days later, the online store sends it back because the color is missing. Logistics complains there is no gross weight. The marketplace rejects it because gender and age group are blank.

Nobody got it wrong on purpose. The rule for what is required lived in each team's head, not in the product record.

What is product data standardization, and what is an attribute model by category?

Product data standardization means deciding, before any item is created, how each item must be described: which attributes it has (what makes up the item's technical data sheet), in what format, with which accepted values and who is accountable for each one. The attribute model by category is the core of it. It says a T-shirt has color, size and gender, a juice has net content and a nutrition table, and a screw needs none of those.

Tying attributes to a classification is not something companies made up. GS1, the global standards organization behind barcodes, uses the GPC (Global Product Classification), organized in four levels: segment, family, class and brick. The user manual for the National Product Registry (Cadastro Nacional de Produtos, or CNP), the product database run by GS1 Brasil, defines the brick as a coherent grouping of items that gives visibility and makes that information uniform across users. In the manual's own example, an orange juice sits in Food/Beverage/Tobacco, family Beverages, class Non-alcoholic ready-to-drink beverages, brick Ready-to-drink juice-based beverages (perishable).

One caveat: I am quoting the tool's manual, dated May 12, 2021. The current version of the CNP may have changed screens and fields.

What levels of "required" can an attribute have?

"Required" on its own says little. I split it into four levels, because each one is enforced at a different moment.

1. Always required

Applies to every product in every category. Description, unit of measure, brand, internal category. Without these, the item should not even be created. At GS1 Brasil, for example, the CNP manual lists a set like this for its own registry: to register a GTIN 12 or GTIN 13, it asks for product description, photo or photo URL, brand, language, country of origin, gross weight, unit of measure, net content, NCM and CEST (Brazilian tax classification codes), GPC and destination country.

2. Conditional on category

Only shows up when the product falls into a given classification. The clearest example is in the CNP itself: serving size description, daily reference, nutrition table items (quantity, unit and percent daily value) and allergens only appear if the product is classified in the food and beverage segment. For a hand tool, such as a pair of pliers, those fields do not exist.

3. Required by destination or channel

The attribute is required because the item is going somewhere specific. In Google Merchant Center, Shopping ads and free listings require specific sets of attributes depending on the category: apparel needs gender, age_group and color, and footwear needs the same plus size. Without them, the offer does not show. That is this channel's rule, not a universal one. Each marketplace, EDI partner and customer catalog can have its own.

4. Optional

Helps the product sell or be found, but does not block it. Material, style, occasion. Optional does not mean irrelevant: the CNP manual itself notes that, even though some fields are mandatory, it is important to fill in all of them.

How do you build the requirement table?

Put the four levels in one table per category. It becomes the agreement between teams.

Requirement type	Example	Who defines it	Where it is enforced
Always required	Description, unit of measure, brand, tax classification code	Data governance with tax and product data teams	At item creation, for every category
Conditional on category	Nutrition table and allergens for food and beverages	Category management, supported by quality or regulatory	At creation, as soon as the category is chosen
Required by destination	Gender, age group and color for apparel; the same plus size for footwear, on a shopping ads channel	E-commerce or channel owner, based on the channel's published rules	Before publishing to that channel
Optional	Material, style, search keywords	Sales or marketing	Does not block; counts toward the completeness score

How do you set the value domain and unit for each attribute?

Saying "color is required" and accepting free text gets you halfway. Soon you have "Blue", "BL", "navy blue" and "Navy" for the same thing. Store filters break and reports do not add up.

Closed list for categorical values

Color, gender, age group, packaging type: a list of accepted values, each with a code and a label. If a channel uses a different list, keep a mapping table, not a second product record.

Number with a defined unit for measurements

Gross weight in kilograms, net content in milliliters or grams, dimensions in centimeters. The unit is part of the attribute rule. Without it, the same field receives 500, 0.5 and "500g", and logistics cannot calculate freight or pallet loads.

Free text only where there is no alternative

A long marketing description, for instance. Even then, with a maximum length and a build rule. I covered that in how to write standardized item descriptions.

Who owns each attribute?

An attribute with no owner is an attribute nobody fixes. A split that usually works:

• Sales: selling name, brand, marketing description, appeal attributes (style, occasion).
• Tax: tax classification codes and other tax fields (in Brazil, NCM and CEST). The product data team suggests, tax validates.
• Logistics: gross weight, dimensions, unit of measure, packaging.
• Category management: the item's classification and the attribute model of each category.
• E-commerce and channels: the attributes each destination requires and the mapping to the channel's value lists.

Each team approves what belongs to it. The data analyst should not decide the tax code alone, and the tax team should not pick the product's color.

How do you make the category trigger what is required?

This is the change that most affects day-to-day product data work. The first decision on the form is the category. Once it is chosen, the system shows only the attributes in that model and flags which ones are required. It is the same behavior as the CNP with food: classify it in the food and beverage segment and the nutrition fields appear.

That has two consequences. First, a wrong category triggers the wrong requirements. Google warns about exactly this: if the product category is not provided, it may be assigned automatically and, if it is wrong, the required attributes can change. Second, the category becomes a high-risk field, approved by whoever owns it.

If your data mixes concepts, such as internal-use materials and products for sale, read about the differences between material, product and article first. The attribute model for one does not fit the other.

How do you measure completeness by category and by channel?

A single completeness number for the whole database hides the problem. I measure it two ways:

• By category: of all footwear items, how many have every always-required and conditional attribute filled in? This shows where the model is not being followed.
• By channel: of the items that should be on channel X, how many meet what channel X requires? This shows what is stuck before publishing.

An item can be complete for the ERP and incomplete for the marketplace at the same time. You need both measures. To set up the indicators, the article on measuring master data quality covers the dimensions and how to track them.

How do you change the model without breaking the database?

The model will change. A new channel, a new requirement, a category that needs to be split. The usual mistake is switching on the new requirement for everything on the same day. Result: thousands of existing items become "incomplete" at once and block simple changes, like updating a price.

Version the model

Record what changed, when, who approved it and why. That way you know which version each item was created under.

Treat new and existing items differently

New items follow the new rule from day one. Existing items get a deadline and go into an enrichment queue, prioritized by sales or by the most demanding channel.

Block the channel, not the record

If the new attribute is required by destination, block publishing to that channel, not the whole record. The item keeps running in the ERP while it is being completed.

Hypothetical example: an apparel and food distributor

Hypothetical example, created to illustrate the method. Fictitious company, no real data.

A fictitious distributor, which I will call Distributor A, sells to physical retailers and through its own online store, and has decided to advertise on an online shopping channel. It has two lines: T-shirts and juices.

• Always required for both: description, brand, unit of measure, gross weight, tax classification code, internal category.
• Conditional on the juice category: net content in milliliters, nutrition table, allergens.
• Conditional on the T-shirt category: color (closed list), size (closed list), gender, age group.
• Required by destination: for the ads channel, the T-shirt's color, gender and age group must be mapped to the values that channel accepts.
• Optional: fabric composition, featured flavor, search keywords.

The analyst picks the category first. If it is "juice", the apparel fields never appear. The T-shirt only goes to the ads channel once it passes that channel's rules; in the ERP, it is already active for invoicing.

Where should you start?

1. List the categories that sell the most or get sent back most often by channels.
2. For each one, write down the attributes and classify them as always required, conditional, required by destination or optional.
3. Define the value domain, unit and owner of each attribute.
4. Gather the published rules of the channels you sell on and mark what is a destination requirement.
5. Make category the first decision when creating an item and tie the requirements to it.
6. Measure completeness by category and by channel before and after, and handle legacy items in a queue with deadlines.

If you plan to run this inside a tool, the 4MDG product information management (PIM) page shows how the category model is configured. For complementary routine practices, see also best practices for an efficient product registry.

Frequently asked questions

How many required attributes should each category have?

There is no right number. The rule I use: an attribute is required if, when missing, it prevents you from selling, invoicing, shipping or publishing. Everything else is optional and counts toward completeness. A category with too many required fields pushes analysts to type anything just to get through.

What should you do with existing products that lack a new attribute?

Do not block the whole item. Flag it as pending for the channel that requires the attribute, put it in a prioritized enrichment queue and set a deadline. The item keeps running in the ERP in the meantime.

Is "required in the ERP" the same as "required by the channel"?

No. The ERP requires what it needs to buy, stock and invoice. The channel requires what it needs to display and filter the product. That is why completeness is measured separately for each destination.

Who approves changes to the attribute model?

The category owner proposes, and data governance approves after hearing the affected teams, especially tax and logistics when the attribute is theirs. The change is versioned, with date and reason.

Can GPC be used as the internal category?

It can serve as a reference, and the CNP asks for the 8-digit brick code. But internal categories usually follow the company's own selling and purchasing logic. The most common approach is to keep the internal category and store the GPC brick as an attribute.

What if an attribute is required but nobody knows the value?

Do not make up a value to pass validation. Send the request back to whoever asked for the item, with the reason, or ask the supplier. A generic value such as "not applicable" should only be on the list when it is a genuinely valid answer for that category.

How 4MDG can help

The 4MDG platform delivers PIM functions inside an MDM: a product model by category, with required attributes, value domains and assortment hierarchy, and completeness by channel, where an item is only published when it meets what that channel requires. Configuration is low-code, and ADAM, 4MDG's AI, reads free text and splits the attributes by family. See the details on the PIM and product data page. If you want to know how many SKUs in your database are missing a required attribute today, request the free assessment.

Sources

• GS1 Brasil. Cadastro Nacional de Produtos: Tutorial Completo (National Product Registry user manual, in Portuguese, dated May 12, 2021). Accessed on October 22, 2026.
• Google. Merchant Center Help, How to fix: Missing value: size, color, gender, age group. Accessed on October 22, 2026.
• 4MDG. PIM product information page. Accessed on October 22, 2026.