Use tags for operational grouping — the things your team sorts by, and the conditions that build automated collections. Use metafields for structured product attributes that customers see, filter by, or that need to exist in more than one language. Use an app only when you need behaviour, not just data.
The most common and most expensive mistake is using tags as a database.
Why the distinction matters more than it looks
Tags are strings attached to a record. That’s the whole model. There’s no type, no schema, no key-value relationship. material-cotton is not a material field containing cotton — it’s a string that a human agreed to format that way, and which nothing enforces.
Metafields are typed and defined. A metafield definition specifies a namespace, a key, and a type. Everything using that definition validates against it.
That difference produces four practical consequences.
Translation. Tags can’t be translated. If your store sells in more than one language, a tag-based filter is a filter that only works in one of them. Metafields can be translated.
Type safety. A metafield defined as a number is a number. You can compare it, sort by it, and render it with confidence. A tag reading weight-2kg is a string you have to parse in Liquid every time.
Filter presentation. Tags used as filters expose every tag on the product, including operational ones you never meant customers to see. A metafield filter shows only the values in that field. If you tag products for internal reasons — supplier, batch, campaign — and also filter by tags, those internal tags become a public browsing interface.
Performance. Parsing structured data out of tag strings in Liquid means string operations inside loops on every render, which is a genuine contributor to server-side render time on large collections.
What tags are genuinely good at
Tags aren’t obsolete. They’re good at exactly the jobs they were designed for:
- Automated collection conditions. Tag a product
sale-ss26and let a smart collection pick it up. - Admin filtering. Finding products quickly in the product list.
- Operational state. Discontinued, needs-photography, supplier-X — anything your team needs and customers don’t.
- Orders and customers. Tags are the segmentation primitive across the admin, not just for products.
The rule of thumb: if the tag exists for your team, it’s a good tag. If it exists to describe the product to a customer, it should probably be a metafield.
Category metafields: check before you build
Since Shopify’s Standard Product Taxonomy, assigning a category to a product generates category metafields automatically — sleeve length for apparel, material for furniture, and so on. The values are consistent by default because they come from a controlled vocabulary rather than whatever someone typed.
Before defining a custom metafield, check whether the category already gives you the attribute. Standard attributes make better filters than custom ones for exactly this reason, and they cost nothing to adopt.
Metaobjects: when the thing is an entity
Metafields describe a product. Metaobjects describe something that exists independently and gets referenced by products.
A colour is the clearest example. If “Forest Green” is a metafield value, it’s a string repeated across forty products, and changing the swatch means editing forty products. If it’s a metaobject with a name, a colour value, and an image, it’s one record that forty products point at.
Use a metaobject when:
- The thing has more than one attribute (a name and a swatch, a name and a description)
- It’s reused across many products
- It might need its own page — a designer, a material, a size guide, a care instruction set
For filter swatches specifically, the metaobject route is what enables visual filters. The metaobject definition needs a colour or image field, a product or variant metafield references it, and both need storefront access enabled. Variant metafields let the swatch link through to the matching variant; product metafields don’t.
When you actually need an app
An app is the right answer when the requirement is behaviour rather than storage:
- Logic that runs at checkout — discounts, shipping rules, payment gating. That’s Shopify Functions, distributed as apps.
- Search and filtering beyond Shopify’s native limits
- Subscriptions, loyalty, reviews — systems with their own data model and lifecycle
- Integrations with an ERP, PIM, or fulfilment provider
An app is the wrong answer when you’re paying a monthly fee to store structured data that metafields would hold for free. A surprising number of installed apps are doing exactly that, usually because they were installed before metafields could do the job.
The decision, condensed
| You need to | Use |
|---|---|
| Group products for an automated collection | Tags |
| Let your team find things in the admin | Tags |
| Store a typed attribute customers will see | Metafield |
| Store an attribute customers will filter by | Metafield |
| Support more than one language | Metafield |
| Store something with multiple fields, reused across products | Metaobject |
| Show a visual swatch in filters | Metaobject + metafield reference |
| Run logic at checkout | App (Function) |
| Exceed native filtering limits | App |
The migration nobody wants to do
Most stores over a few years old have product data encoded in tags that should be metafields. The cost of leaving it there compounds: every new locale, every new filter, and every theme change has to work around it.
The migration itself is mechanical — read the tags, write the metafields, update the theme, remove the tags. The expensive part is the audit that tells you which tags mean what, because that knowledge usually isn’t written down anywhere. Do the audit first, and do it while whoever created the tags still works there.