A product catalog is more than a list of SKU, title, and price. Once products have different attributes, variants, locales, suppliers, or sales channels, the catalog needs a data model that captures those differences properly.
That's exactly what a PIM does: it separates product structure from output channels and creates a single, consistent data source. PIMSuite builds that on flexible attributes, product families, variants, relationships, and validation.
What actually belongs in a product catalog?
A complete product catalog typically includes:
- SKU / item number
- name / title
- brand
- description
- technical characteristics
- dimensions and units
- colors / sizes
- variants
- prices
- media
- documents
- categories
- product relationships
- supplier information
- translations
- status
- channel-specific content
Those fields roughly fall into four groups: master data (identifiers, brand, dimensions), marketing data (titles, descriptions, benefit copy), technical data (voltage, material, dimensions), and relationships (variants, accessories, replacement parts, bundles).
Why spreadsheets stop working for complex catalogs
The problem isn't that spreadsheets are bad - it's that their data model (one row, fixed columns) doesn't scale with a growing catalog.
Different products need different fields. A t-shirt needs size, material, care instructions. A cordless drill needs voltage, power, torque. In a flat spreadsheet, that turns into hundreds of columns, most of them empty and irrelevant for any given product.
Variants duplicate data. Ten colors times five sizes quickly becomes 50 rows repeating the same description and brand data - every change has to be applied 50 times.
Multilingual data multiplies columns. title_de, title_en, title_fr - for every translatable field individually.
Multiple channels need different structures. A marketplace, a shop, a print catalog, and a B2B feed each want different fields in different shapes.
Validation becomes fragile. Missing units, inconsistent spellings, swapped values only surface in a spreadsheet once an export has already failed.
Product families
A product family defines which attributes apply to a type of product:
Family: T-Shirt
- Material
- Fit
- Gender
- Care instructions
- Color
- Size
Family: Cordless Drill
- Voltage
- Torque
- Battery capacity
- Chuck size
- Weight
PIMSuite groups attributes into families so different product categories get exactly the right fields. Editors only see relevant fields, validation can differ by family, and exports become more predictable because each family has a fixed schema. Attributes are ordered and grouped within each family - the edit form always shows exactly what's needed.
Attributes: choosing the right data type
Attribute modeling is more than "add a field." A common mistake is free text where a controlled field belongs:
Bad: material = "Steel", "stainless steel", "SS", "rostfrei" - four spellings for the same value.
Better: a select field with a fixed value material = stainless_steel, plus localized labels (EN: "Stainless steel", DE: "Edelstahl"). Filtering, reporting, and channel exports only work reliably when the same value is always written the same way.
The same applies to number vs. text: 12.5 as a number with a separate unit is a different thing from the string "12.5kg". Only the structured number can be sorted, filtered, converted, and validated - the string can't.
PIMSuite supports 12 attribute types for this: Text, Textarea, Rich Text, Number, Boolean, Date, DateTime, Select, Multiselect, Image, File, and Price. Every attribute is individually configured - mark it localizable, required, filterable, unique, AI-completable, or bulk-editable. The system adapts to your schema, not the other way around.
Taxonomy is not the same as product family
This mix-up is common, and the distinction matters:
Product family determines what fields a product has.
Category/taxonomy determines where a product belongs.
A drill belongs to the family "Power Tool" but can sit in the taxonomy under "Tools → Drills → Cordless Drills." Family membership says nothing about navigation structure - and the same category can contain products from several different families.
Variants: when should you use them?
The most practically important modeling question: when is something a variant, and when should it be a separate product?
In favor of a variant: same core product, shared description, difference limited to size/color or similar axes, shared merchandising identity.
In favor of a separate product: materially different specs, different function, different regulatory data, a distinct product identity.
PIMSuite treats variants as a first-class data structure: define axis combinations (size × color), designate a main variant, and shared attributes stay synchronized across the whole group - change the description once, and it propagates to every variant automatically. Import-time variant grouping rules let you automatically cluster incoming supplier SKUs into the right variant groups by pattern, instead of matching them up by hand.
Bundles and kits
A bundle is a commercial grouping of independently sellable products - a camera, a lens, and a bag offered together, for example. A kit is more of a set, where the components together define the offer.
Both raise the same practical questions: how does a stock change in one component affect the bundle? Is the price fixed or calculated from component prices? What happens when a component changes?
PIMSuite supports bundles and kits with per-item quantities; bundle pricing can be fixed or calculated from component prices.
Product relationships are not the same as categories
Real catalogs often need relationships beyond variants and bundles - accessories, replacement parts, cross-sells, successor or predecessor products. These aren't variants: they don't share attributes or a merchandising identity, they reference each other. PIMSuite's data model includes product relationships as their own concept, separate from variant grouping and categorization.
Shared data and inheritance
A large catalog quickly gets expensive to maintain if every field has to be set individually on every product. The classic PIM concept for this is inheritance across multiple levels - brand, family, parent product, variant - where a value set at a higher level automatically applies to everything below it unless deliberately overridden.
PIMSuite already covers part of this structurally: the family schema determines which fields apply, and shared attributes stay synchronized automatically within a variant group. A full inheritance chain across arbitrary levels - brand → family → parent product → variant, with a targeted override at any level - isn't a standalone, configurable feature today; for catalogs that need that systematically, it's a natural extension to build.
Completeness is not the same as data quality
Every product in PIMSuite gets a completeness score, calculated per locale. You always know what's missing before you publish, and you can filter the entire catalog by completeness range to close gaps systematically.
One distinction is worth keeping in mind: 100% completeness doesn't automatically mean good data. A product with the title "Product 123" and the description "Good product" is technically complete - every required field is filled - but commercially useless. Four levels are worth separating:
- Completeness - are the required fields present?
- Validity - are the values structurally correct (right type, right format)?
- Quality - is the content actually useful and accurate?
- Channel readiness - does the record satisfy the destination's requirements?
PIMSuite's completeness score covers the first level. For deeper content-quality checks, see data quality.
Supplier catalogs and normalization
Your internal, canonical catalog isn't the same thing as your suppliers' catalogs. Supplier A might call a field Item No: 00124, Supplier B SKU: X992, while internally you have your own product ID. Mapping incoming supplier fields onto your own attribute schema is what PIMSuite's supplier import automation handles, including the variant grouping rules described above for patterns in supplier SKUs.
One product, multiple channels
Canonical product record
↓
Shop
Marketplace
B2B portal
Print catalog
Marketplace feed
Each channel can require a different title length, a different category taxonomy, different required attributes, different media, or a different language. That's exactly what a PIM exists to avoid: maintaining five disconnected copies of the same product. PIMSuite's multi-channel publishing maps that canonical record onto each channel's own fields.
Version history and audit log
The real question a version history needs to answer is rarely abstract: who changed the voltage from 18V to 20V? When? Was it a manual edit or an import? What was the previous value?
PIMSuite records every change to every product with the user, timestamp, and field-level old and new values. Nothing is ever permanently lost - unless you explicitly decide it should be.
Bulk operations
Bulk editing only becomes genuinely useful once there's a real case behind it: renaming a brand across 8,000 SKUs, moving a category, standardizing "Made in PRC" to a consistent country-of-origin value, archiving discontinued products, populating a new field for an entire family.
PIMSuite updates status, brand, country of origin, taxonomy, or any custom attribute across thousands of products in a single operation. Bulk text find-and-replace with regex support handles catalog-wide renames without individual edits.
Draft / Active / Archived
Products move through three statuses: Draft for work in progress, Active for live products, Archived for discontinued ones. Archived products can be restored; soft-deleted products stay recoverable until explicitly force-deleted.
How a good product catalog should be structured
A few principles that hold regardless of which system you use:
- Start with products, not channels. Don't just copy your shop platform's schema into your data model.
- Normalize repeated values. Brands, materials, and categories belong in controlled fields, not free text.
- Prefer structured values.
weight = 12.5with a separate unitkginstead of the string"12.5kg". - Separate product and variant data. Don't duplicate shared attributes across every variant.
- Model relationships explicitly. An accessory isn't a variant.
- Keep provenance traceable. Know which supplier source a value came from.
- Validate before export. The channel shouldn't be your only quality check.
How PIMSuite implements a product catalog
PIMSuite combines all of the above into a structured catalog that grows with your business: 12 individually configurable attribute types, product families with ordered field groups, first-class variants with automatic attribute synchronization, bundles with fixed or calculated pricing, per-locale completeness scoring, a Draft/Active/Archived workflow with recoverable soft-delete, a complete version history with user and timestamp, and bulk operations across thousands of products in a single pass.