What attribute groups are
An attribute group is a labelled category used to organise attributes within a family. Groups provide structure and readability, especially when a product contains dozens or hundreds of attributes.
Typical examples:
Core Classification
Product Characteristics
Technical Specifications
Ingredients & Nutrition
Packaging Details
Compliance & Certifications
Groups do not affect data logic, inheritance or export rules.
They only influence how the schema is presented to users.
How attribute groups shape the product editing experience
1. Groups define the layout of the product editor
In the product editor, attributes appear grouped under collapsible sections.
This makes it easier to navigate large schemas.
Examples:
Core Classification always appears first, giving users the context they need (Product Type, Brand, Animal Type, etc).
More detailed sections follow, allowing users to focus on specific domains of data.
The clearer the grouping, the easier it is for teams to edit data accurately.
2. Groups create logical mental models for products
Each group represents a domain of product knowledge.
For example:
“Nutritional Info” in Pet Food
“Safety Ratings” in PPE
“Specifications” in Hardware Tools
When groups align with how product teams think, data entry becomes faster and more consistent.
3. Groups improve supplier onboarding
The supplier portal uses the same attribute groups to present required data.
Good grouping:
Reduces confusion
Minimises back-and-forth
Helps suppliers understand which data belongs where
Supports mandatory fields in a context that makes sense
When suppliers see a clear structure, they submit more complete and correct data on the first attempt.
4. Groups help AI agents understand context
While groups do not directly affect extraction logic, they improve:
The interpretability of results
Review workflows
User confidence during approval
For example, if AI places a value under Technical Specifications, reviewers know it reflects a measurement or engineering attribute, not a marketing concept.
Groups make the enrichment process easier to understand and verify.
5. Groups enable cleaner completeness and quality scoring
Completeness scoring is applied across all attributes in a family, but grouping helps teams scan gaps more efficiently.
For example:
“Core Classification” being incomplete signals a top-level issue
“Technical Specs” being incomplete may be acceptable depending on catalogue priorities
“Nutritional Info” missing could be critical for specific categories
Attribute groups therefore help prioritise completion and identify bottlenecks.
6. Groups allow schemas to scale without becoming chaotic
As families evolve and attributes increase, grouping provides structure. Without groups, a schema with 50+ attributes becomes:
Hard to interpret
Time-consuming to review
Easy to mis-enter data
Difficult for suppliers to work with
Groups prevent schema bloat from turning into operational friction.
7. Groups support UI features like collapsing, focusing and quick scanning
Because each group is collapsible:
Users can focus on one part of the schema at a time
Large schemas remain manageable
Reviewers can jump directly to the relevant domain of data
This improves data entry speed and reduces errors.
How attribute groups behave internally
Attribute groups:
Do not affect inheritance
Do not determine which attributes are mandatory
Do not influence select lists or data validation
Do not control visibility (permissions handle that)
Do not affect API or export structure
They are purely organisational and influence user experience, not data logic.
Best practices for defining attribute groups
Use broad, meaningful categories
Group attributes by purpose, not by technical detail.
Keep the number of groups small
3–7 groups per family is ideal.
Avoid over-segmentation
Too many groups create the same confusion as too few.
Use consistent naming patterns across families
Examples:
Core Classification
Characteristics
Specifications
Packaging
Compliance
Place critical attributes in predictable groups
Brand and Product Type should always live in Core Classification, for example.
Mirror how real users think about products
If merchandisers mentally separate “Dimensions” from “Technical Specs”, then create two groups.