E-commerce
March 25, 2026
Standard product sheets are not always enough: materials, compatibility, technical sheets, editorial profiles, reusable content across multiple products. Shopify addresses this need with custom data: metafields to extend existing resources, and metaobjects for reusable standalone structures. This guide condenses official references and team best practices, with only three external sources: the Shopify Help Center overview Custom data, the developer documentation on metafields and data ownership, and the CNIL reminders about legal bases when your fields involve personal data. For the “classic” catalog, keep variants and collections and add a product close at hand.
Summary
Meta fields and metaobjects: official definitions
The page Custom data reminds us that Shopify already covers the fundamental concepts (products, collections, orders) and that custom data is used to extend or create more specific models. The metafields associate a field, standard or custom, with a part of Shopify: product, customer, blog, etc. The metaobjects make it possible to define structures with several fields, then create entries: the official example cites an influencer profile with title, image, and description, displayable in the theme or used in the admin.
On the development side, the documentation About metafields clarifies the mental model: metafields add key-value pairs to existing Shopify resources; for standalone multi-field objects, the recommendation is rather toward the metaobjects, with a dedicated cross-modeling guide. This distinction avoids multiplying flat metafields when an object structure would be cleaner.
Why structure data beyond native fields
Consistency : the same piece of information (e.g. material, standard) reused across dozens of products with the same semantics.
Error reduction : less free-form text scattered throughout the description when the field needs to be filterable or compared.
Interoperability : Shopify-documented standard definitions make the apps and themes ecosystem easier.
Automation : Flow, apps, and integrations can read metafields to trigger business rules.
The goal is not to add fields just to « fill out » the product page : each definition must have a use (storefront, support, logistics, compliance) and a clearly identified business owner.
Metafields: definitions, types, and validation
On shopify.dev, a metafield combines an identifier (namespace and key, for example custom.warranty_info), a value, and a type that defines the semantics (text, number, date, file, reference, etc.). Before writing values, you create a metafield definition: it imposes a schema, enables validation, admin integration, filtering, and performance optimization, according to the same documentation.
Shopify also offers standard definitions for common use cases (ingredients, care instructions, product identifiers): adopting them when possible reduces technical debt and improves compatibility between apps. The French Help illustrates metafields with the example of care instructions on a garment: a typical case of structured content rather than a paragraph lost in the description.
Metafield ownership: merchant, app and special cases
The developer page distinguishes app-owned metafields (reserved namespace, TOML configuration, app-scoped logic) and merchant-owned metafields (non-reserved namespaces like custom, editable by the merchant and apps, suited to shared data). There are also Shopify reserved metadata and app data metafields tied to installation, outside customer product resources: useful for internal settings, but be cautious with secrets (the documentation recommends avoiding storing sensitive credentials there).
For a store without a dev team, most content needs will go through merchant definitions and the editor. For a business app, the app-owned model protects business logic while exposing what needs to be exposed in the admin.
Table: type of need and recommended tool
Need | Approach | Considerations |
|---|---|---|
Simple attribute on a product (warranty, country of origin) | Product metafield with typed definition | Storefront access / Storefront if headless |
Reusable block (e.g. size chart, ingredient sheet) | Metaobject + reference from the product | Avoid duplicating content across 200 SKUs |
Internal data for an app (scoring, preferences) | App-owned metafield or app-data depending on the case | API scopes and admin permissions |
Personal data about the customer | Customer metafield with legal framework | see CNIL section |
Metaobjects: reusable structures and entries
A metaobject defines a type (schema) and entries (instances). Each entry can be referenced from one or more products, collections, or other resources depending on your model. The data modeling guides on shopify.dev describe how to combine metafields and metaobjects to avoid graphs that are impossible to maintain. In e-commerce practice: a metaobject “size chart” with rows for each shoe size, or a metaobject “certification” with logo, text, and link, reused across the relevant product lines.
Shopify admin: Settings, Content, and Team
The Help points to the Content section of the admin to navigate metaobjects and entries, and to settings for meta field definitions. Document internally: who creates a definition, who fills in the values, who validates before publication. A poorly named definition can remain in the catalog for years and complicate migrations.
Plan a lightweight reference list (spreadsheet or Notion) listing namespace, key, type, target resource, customer visibility, and theme dependency. This avoids duplicates custom.matiere and custom.material for the same idea.
Showcase display, theme and API
A metafield doesn't magically appear on the product page: the theme must expose the block via the theme editor (dynamic blocks) or Liquid code, depending on your theme version. Headless teams must expose the fields via the API with the appropriate permissions. The developer documentation emphasizes the access settings for admin, storefront, and customer accounts: a metafield may remain invisible to the Storefront API even though it is accessible in Liquid, depending on the configuration.
Storefront API access and filtering
For storefronts that consume the Storefront API, metafield definitions must provide for read permissions on the storefront side. Definitions also enable filtering capabilities and advanced queries according to the docs: useful for collections filtered by business attribute, without multiplying tags.
Personal data and minimization (CNIL)
As soon as you store information about people (customers, prospects) in metafields or metadata linked to orders, the GDPR applies. The CNIL reminds us that processing must have a legal basis and remain proportionate: do not collect sensitive data in a metafield « notes » without necessity, and restrict access in the admin to the relevant roles. Metafields are not an unlimited storage area: document the purpose and retention periods aligned with your privacy policy.
Examples by sector (without overengineering)
Fashion and textiles
Metaobject for size charts by product line; metafields for composition, care, origin. Avoid duplicating the same chart as a static image on each page if a structure allows an update.
Food
Ingredients, allergens, certifications: prefer standard definitions when they exist for your category to facilitate consistency across channels.
Electronics and parts
Compatibility, manufacturer references, manuals: metafields and sometimes "manual" metaobjects with PDF file and language version.
Additional sections
SEO and useful content
Structured data serves experience and clarity: titles, text, and attributes that are consistent with what you display. Cross-reference with e-commerce SEO and SEO strategy: metafield content must remain useful for the user, not just for search engines.
Category metafields and variant options
Shopify is progressively promoting an approach where product taxonomies and category metafields help align industry-specific attributes (materials, dimensions, compliance). The benefit for you: less inconsistent free text between two product pages in the same family. When variant options (color, size) are connected to category metafield entries, a rename (for example, a shade) can propagate everywhere that entry is reused. This changes the game for large collections: plan label governance and validation before mass renaming.
For variants, the “Variants” Help also reminds us that variant metafields can enrich product pages, with conditional display possibilities depending on the theme. If you combine many variants and rich data, cross-reference with variants and collections to avoid theme- or app-side complexity limits.
Lifecycle: versions, migrations, and cleanup
A metafield project lives over several years. At the start, you quickly create definitions for a launch; as the brand grows, some definitions become orphaned or redundant. Plan an annual review: unused definitions, duplicate keys, overly permissive types (long text where a controlled list would suffice). When changing themes, check that the dynamic connections of the blocks still point to the correct namespaces.
Migrations from older apps or from fields stored elsewhere (ERP, PIM) often go through the API or imports: plan validation batches, samples per category, and an error log. A nighttime migration without a fallback plan is a classic source of product pages that are half-filled the next morning.
Merchants, agencies, and apps: who does what
The merchant must be able to edit visible and business-related content without a ticket for every tweak: hence the value of merchant-owned definitions and clear admin interfaces. The agency or developer configures the definitions, theme blocks, API access, and documents the namespaces. The app developer chooses app-owned metafields for what falls under internal product logic, clearly separating public data and sensitive configuration.
Formalize a minimal interface contract: which fields are required before publishing, which are optional, how teams translate or adapt multilingual content if you use market apps or market-specific fields. Without this clarification, marketing fills in the HTML description while the metafields remain empty and the filters do not work.
Common mistakes
Mistake | Effect | Fix |
|---|---|---|
Definitions without an owner | Chaos and outdated fields | Internal repository and quarterly review |
Duplicating the description in a metafield | Contradictory content | One single source of truth per attribute |
Forgetting Storefront permissions | Empty fields in headless setups | Review definitions and API tests |
Storing sensitive personal data without a framework | Compliance risk | Minimization, roles, anonymization |
Checklist before going live
Before opening a large volume of enriched product pages to the public, run the setup through a short launch review:
Naming: consistent namespaces and keys, without spaces or ambiguity, aligned with internal documentation.
Types: choose the strictest possible type (list, number) rather than free text if you need to filter or compare.
Permissions: check admin, storefront, and customer accounts according to the channels actually used.
Theme: test mobile and desktop, including dynamic blocks and cases where a value is empty.
Apps: validate with critical apps (search, filters, recommendations) to avoid invisible or mis-typed fields.
Personal data: validate with your compliance contact if a field relates to customers or sensitive segments.
Fallback plan: a process for correcting an incorrect definition (export, script, manual fix) without breaking production.
This checklist reduces post-launch “surprises” when marketing starts filling in hundreds of SKUs in parallel. Keep a record of decisions in your project tool: the debt on custom data always costs more in maintenance than in initial design.
Metafields usable by an AI chatbot
When attributes are clean, an assistant can answer “what material?”, “compatible with which model?” without hallucinating from free text. Qstomy integrates with Shopify for e-commerce chatbots, customer support, and recommendations; see e-commerce chatbot and the Shopify integration.
Summary
Metafields extend Shopify resources with typed and validated data; metaobjects model reusable entities. The Custom data documentation sets the framework on the merchant side; the About metafields documentation details ownership, permissions, and API; the CNIL reminds us of lawfulness and minimization when people are involved. Three external sources are enough to frame technical, product, and overall compliance considerations.
FAQ
Metaobject or metafield?
Metafield for an attribute on a resource; metaobject for a small reusable model with several fields and entries.
Should you use standard definitions?
Yes when they match your need: better interoperability and less maintenance.
Are metafields visible without code?
Recent themes often allow adding dynamic blocks; otherwise, Liquid or an app.
CSV import of metafields?
Possible depending on the columns and definitions; respect namespace, key, and types. See Add a product.
Should my app use the app namespace?
For data carried by the app on resources, the app-owned model is appropriate; for merchant editorial data, prefer merchant-owned.
Can customer notes be stored in a metafield?
Yes, technically, but frame it under GDPR: legal basis, access, retention period.
Can Shopify Flow read metafields?
Automation scenarios can rely on metadata depending on the available triggers: test on a development store.
Are metafields useful in B2B?
Yes, to enrich product pages, commercial terms, or internal references, provided they remain consistent with your B2B workflows and the apps involved. Document the fields used by invoicing or price lists.
How do you handle multiple languages?
Depending on your stack, translations can go through international market apps, locale-specific fields, or editorial workflows: the important thing is to avoid duplicating definitions by language without a clear strategy.
Do metafields slow down the store?
Thousands of poorly indexed definitions or heavy storefront queries can affect performance: follow best practices for types, filtering, and API pagination, and measure after large-scale additions.
Can I store API secrets there?
No: developer documentation advises against storing sensitive credentials in public or poorly isolated metafields; use vaults or server-side environment variables instead.
Go further
March 25, 2026
