Information Models. How to Properly Structure Your Product Data

Why Information Models Matter

A product information model is the architecture that defines what data you collect, how it's organized, and how it interacts. It's not just a list of fields. It's the foundation for everything you do with product data.

Here's the difference:

Without a proper model: Category managers add random fields, marketing structures data their own way, and the integration team struggles because marketplace requirements don't match. Result: chaos, manual data rework, errors on listings.

With a proper model: Data flows in structured, scales easily, syncs automatically with marketplaces, and doesn't require constant rework.

A poorly designed information model costs more than even the best PIM system. Because the system is just a tool — the model is how you think about your products.

What Is an Information Model

An information model is a set of rules and structures that describe what information you store about a product, in what format, and with what constraints.

It consists of four elements:

1. Category hierarchy — how you organize products into a category tree. This isn't just for navigation convenience; it's the foundation for applying different models to different products.

2. Attributes — product properties (size, color, material, weight, wattage). Each attribute has a data type, requirement level, and allowed values.

3. Attribute groups — logical groupings of attributes by purpose. For example, "Basic Information," "Dimensions & Weight," "Media," "Categorization," "SEO." Groups simplify navigation for managers and structure the product card.

4. Dictionaries and vocabularies — predefined value lists for attributes (for example, all possible colors or materials). This ensures data consistency.

Category Hierarchy: How to Build the Right Tree

Categorization is the first thing to define. It determines whether you can apply different rules to different products.

Principle 1: One classification logic

The category tree should be built using one criterion per level, otherwise confusion ensues.

Wrong:

Electronics
├── Home Appliances
├── For Kitchen
├── Under 1000W
└── Black Color

Right:

Electronics
├── Kitchen Appliances
│   ├── Kettles
│   ├── Microwaves
│   └── Blenders
├── Home Care
│   ├── Vacuums
│   └── Steam Mops
└── Climate Control
    ├── Air Conditioners
    └── Heaters

Principle 2: Tree depth

Don't create categories deeper than necessary. 3–4 levels is usually enough. If you're going 7–8 levels deep, there's an error in logic somewhere.

Principle 3: One product — one category

In a PIM system, a product exists as a single instance and belongs to only one category. This isn't a limitation; it's an architectural decision:

• Category defines the data model. If a product is in "Smartphones," smartphone attributes apply. If a product could be in both "Smartphones" and "Gift Ideas," it's unclear which attribute set to apply.
• Changes are made once. Update the description — it updates everywhere. No risk of current pricing in one category and outdated pricing in another.
• No data duplication. One SKU = one record in the system. This is the foundation of Single Source of Truth.

What about website navigation?

On a website or marketplace, a product can appear in multiple sections. In PIM, this is handled through a separate "Categorization" attribute group, where each channel gets its own dictionary with that channel's category tree.

Attribute Group: Categorization

Website Category (dictionary):
- Holiday Gift Guide
- New Arrivals
- Sale
- Best Sellers

Amazon Category (dictionary):
- Electronics > Accessories > Headphones
- Electronics > Accessories > Speakers

Walmart Category (dictionary):
- Electronics > Audio > Headphones & Earbuds

The product still lives in one information model category (e.g., "Electronics > Audio > Headphones") that defines its attributes. Which sections it appears in on the website or marketplace is controlled through these additional dictionaries. A single product can be in "Gift Guide," "New Arrivals," and "Best Sellers" on your website while remaining a single record in PIM.

In practice: GS1 has the GPC (Global Product Classification) standard that recommends this logic. Use it as a starting point, then adapt to your business logic.

Attributes: Types, Requirements, Groups

Attributes are specific product properties. Each attribute has:

Name: A clear designation (e.g., "Case Material," not "CsMat")

Data type:

• Identifier — SKUs, UPCs, any identification numbers with length limits
• Text field — free-form text (descriptions, names) with AI generation capability
• Formatted block (HTML) — detailed descriptions with markup, links, and formatting
• Single-select list — choosing one value from a dictionary (color, brand, country)
• Multi-select list — choosing multiple values from a dictionary (available colors, compatible accessories)
• Number field — prices, ratings, quantities with range and format settings
• Number field with unit — weight, length, volume with unit selection from a dictionary
• Image — product photos with format, size, and quantity controls
• Files — documentation, certificates, manuals (PDF and other formats)
• URL — links to external resources
• Email — contact addresses with format validation
• Phone — numbers with automatic country formatting

Requirement level:

• Required — product cannot be exported to marketplace without this field
• Recommended — should be filled but not critical
• Optional — filled if applicable to the product

Application level:

• Per product (SKU) — unique to a specific product
• Per category — same for all products in a category
• Per brand — characteristics common to all products of a brand

Attribute groups:

Attributes are combined into logical groups to help managers navigate the product card:

Group: Basic Information
- Product Name
- Description
- Brand
- Model

Group: Dimensions & Weight
- Length
- Width
- Height
- Weight

Group: Media
- Photos
- Video Review
- Manual (PDF)

Group: Categorization
- Website Category
- Amazon Category
- Walmart Category

Group: SEO
- Meta Title
- Meta Description
- URL Slug

Example attribute structure for smartphones:

Category: Electronics > Mobile Devices > Smartphones

Required attributes:
- Product Name (text field)
- Description (formatted block)
- Photos (image, minimum 3)
- Brand (list)
- Model (text field)
- Price (number field)
- Stock (number field)

Recommended attributes:
- Operating System (list: iOS, Android)
- Storage Capacity (list: 64GB, 128GB, 256GB)
- Screen Size (number field with unit: inches)
- Battery (number field with unit: mAh)
- Camera (number field: megapixels)
- Color (list)
- Warranty (number field: months)

Optional attributes:
- What's in the Box (text field)
- Video Review (URL)
- Certifications (files)

Dictionaries and Vocabularies: Why They're Critical

A dictionary is a controlled list of values for an attribute. Instead of every manager typing "red," "Red," "crimson," you say: here's the list of colors, pick from it.

Why this matters:

1. Consistency: All data has the same format
2. Analytics: You can accurately count how many red products you have
3. Filters and search: On websites and marketplaces, filters only work with controlled values. If colors are filled via dictionary, shoppers find all red products with one click. If via free text — some products get lost because someone typed "scarlet" or "RED."
4. Integrations: When data syncs with other systems, it's already in the right format

Example color dictionary:

ID: CLR-001 → Red
ID: CLR-002 → Black
ID: CLR-003 → White
ID: CLR-004 → Blue
ID: CLR-005 → Green
ID: CLR-006 → Yellow
ID: CLR-007 → Silver

The product references the ID, not the text. The dictionary itself remains unified and unchanged. But when exporting to different marketplaces, mapping tables are applied at the channel level:

Channel: Amazon US
CLR-001 → Red
CLR-002 → Black
CLR-003 → White

Channel: Amazon DE
CLR-001 → Rot
CLR-002 → Schwarz
CLR-003 → Weiß

Channel: Walmart
CLR-001 → Red
CLR-002 → Black
CLR-003 → White

This separation is important: the dictionary is your internal standard, and channel mapping is adaptation to specific platform requirements. Managers work with values they understand, and the system automatically transforms them to the right format on export.

Where this is especially critical:

• Sizes — apparel, footwear (S, M, L, XL vs. US 4-16 vs. EU 36-52)
• Materials — different product types use different material sets
• Country of origin — ISO codes for customs automation
• Units of measurement — lb, oz, fl oz, in, ft (especially important for logistics and ERP integration)

In practice: ISO 8000 recommends maintaining dictionaries in a separate Master Data Management (MDM) system, from which they're pulled into PIM. This provides one control point for all systems.

Principles for Building an Information Model

When starting from scratch or redesigning an existing model, follow these principles:

1. Start with an audit of the current state

Look at what data you have now. Where is it stored? How is it structured? Which fields are used, which are dead? This gives you understanding of what's actually needed versus legacy from old systems.

2. Define the source of truth for each attribute

Where does the information come from? Prices from SAP, descriptions from marketing, photos from design, specs from the supplier? Each attribute should have an owner and source.

3. Think about marketplaces from the start

Look at Amazon, Walmart, eBay, Shopify requirements. Which fields are required? What formats? Design the model to cover most platform requirements.

4. Plan for scale

If you have 500 products now but plan for 50,000, the model needs to handle that. Don't create special fields for one product; create shared dictionaries.

5. Input validation beats output correction

Set rules directly in the system: which fields are required, what formats are allowed. It's cheaper than cleaning data later.

6. Version your model

When changing structure, don't delete the old one. Create versions: Model v1.0, v1.1, v2.0. This simplifies migration and rollback if something goes wrong.

In Practice: Examples for Different Industries

FMCG (Food & Beverage)

The information model should include:

Required fields:

• Product Name
• Description
• Photos (front of package minimum)
• Ingredients (important for allergens)
• Nutrition Facts (calories, protein, fat, carbs)
• Net Weight/Volume
• Best By Date
• Storage Conditions

Dictionaries:

• Product Type (beverage, snack, dairy, meat, etc.)
• Allergens (gluten, milk, tree nuts, soy, etc.)
• Country of Origin

Electronics (Appliances, Gadgets)

Required fields:

• Model, Manufacturer
• Technical Specs (wattage, voltage, dimensions, weight)
• Warranty
• Photos (multiple angles)
• User Manual (PDF)

Dictionaries:

• Product Type (microwave, refrigerator, coffee maker)
• Color
• Case Material
• Energy Rating (ENERGY STAR certified, etc.)

Apparel & Footwear

Required fields:

• Size
• Material (outer and lining)
• Color
• Photos (front and back minimum)
• Care Instructions
• Fabric Composition (in percentages)

Dictionaries:

• Size Chart (S, M, L, XL vs. US 4-16 vs. EU 36-52)
• Colors (including fashion names: "dusty rose," "charcoal")
• Materials (cotton, polyester, wool, linen, blends)
• Season (Spring-Summer, Fall-Winter, transitional)

Pharmaceuticals & Health Products

Requirements are stricter here due to regulatory constraints.

Required fields:

• Brand Name
• Generic Name
• Dosage Form (tablet, capsule, syrup, ointment)
• Strength
• Package Size
• Manufacturer
• NDC Number
• Expiration Date
• Storage Conditions
• Drug Facts/Package Insert (PDF)
• Rx/OTC status

Dictionaries:

• Drug Classification
• Dosage Forms
• Routes of Administration (oral, topical, injectable)
• Age Restrictions

Important: In pharmaceuticals, data must comply with FDA requirements. An error in dosage or contraindications isn't just bad UX — it's a potential lawsuit.

Localizing the Model for Different Markets and Marketplaces

One information model rarely fits all sales channels. Each marketplace has its own requirements, and the model must account for this.

Different marketplaces — different requirements

Amazon:

• Strict photo format requirements (white background, minimum 1000px)
• Bullet points (5 key benefits)
• Backend keywords (hidden search terms)
• Product variations (color, size) grouped into one listing
• A+ Content for enhanced descriptions

Walmart:

• Shelf description (short search description)
• Key features
• Strict image requirements
• Rich Media content

eBay:

• Item Specifics (attributes depend on category)
• Condition (new, used, refurbished)
• More freedom in descriptions, less structured data

Shopify:

• Metafields for custom attributes
• Product variants (options/variants)
• Collections for grouping

How this is handled in the information model

Approach 1: Base model + extensions

Create a core model with shared attributes, then add marketplace-specific fields for each.