Attributes and data modeling - beyond Shopify mechanics

The Shopify Foundations phase covered where attributes live (metafields, mostly). This lesson is about the harder question: which attributes should exist, what values they're allowed to hold, and who decides. That's data modeling, and it's the difference between a catalog and a pile of products.

Attributes per category, not per store

The first insight: attribute sets belong to categories, not to the whole catalog. Shirts need material, fit, collar type, sleeve length. Shoes need material, heel height, sole type. A single global list produces either bloat (every product showing forty mostly-empty fields) or poverty (only the fields everything shares).

Practical version: for each top-level category in your taxonomy, list the 5–10 attributes a customer would use to choose between two products in it. That's your model. Comparison is the test - if no customer would ever filter or compare on it, it's probably description material, not an attribute.

Closed lists beat free text

For every attribute, decide: free text, or a defined list of allowed values? Default hard toward lists. A material field that only accepts values from your list ("Organic cotton," "Linen," "Wool," …) cannot drift into fourteen spellings. Free text is for genuinely open fields - a styling note, a designer's comment. Everything filterable, feedable, or translatable wants a closed list, because every downstream system depends on values being predictable.

This is also, quietly, your translation strategy: a closed list of 30 material values translates once per market. Free-text materials translate per product, forever.

Required vs. nice-to-have

Mark each attribute required or optional per category. "Required" doesn't mean Shopify blocks saving - it means your workflow treats a product without it as unfinished, and your data audits count it as a gap. Material on a garment: required. Styling note: optional. Without this distinction, completeness can't be measured, and what can't be measured quietly erodes.

Who owns the model

One person or team owns the attribute model - adding fields, extending value lists, retiring unused ones. Not because governance is fun, but because a model everyone can edit becomes a model nobody trusts. Changes go through the owner; the model document stays true; the catalog stays coherent. It's fifteen minutes a month that saves the archaeology project.