Executive summary
- What: when a metafield on a product, variant, customer or order points at a metaobject, the fields inside that metaobject can now be used as dimensions and filters in Analytics.
- Why: structured reference data such as a designer, a warranty term or a loyalty tier stops being display-only and becomes something you can group a sales report by.
- Who: merchandising and finance teams who have been exporting to a spreadsheet to answer questions the admin already held the data for.
What changed
Metaobjects have been the right place to model repeated, structured reference data for some time, but until now that data ended where the storefront ended. Reporting treated a metaobject reference as an opaque pointer. Analytics can now follow that pointer and read the fields on the other side, so a report can be grouped by the country on a Designer metaobject rather than by the designer reference itself.
The fields appear in the report picker under Metaobjects, where you select the resource, then the definition, then the field. Filtering to a single value works the same way, and the same fields are available in the query editor for teams that write their own queries. Merchant-owned definitions are enabled by default, and you can turn an individual definition off in Settings under Metafields and metaobjects. Definitions created by an app stay off until you or the app explicitly enable Analytics for them. Nothing about your existing metaobjects or the metafields pointing at them changes, and custom and category metafields remain in their own groups in the picker.
Why it matters
For enterprise catalogues this closes a reporting gap that was usually being patched downstream. The typical workaround was a nightly export into a warehouse, joined against a product attribute table, refreshed on someone else's schedule. That pipeline existed only because the attribute lived in a metaobject rather than a plain field. Where the question is simple, grouping revenue by supplier region or by warranty tier, the warehouse round trip is now unnecessary.
The default-on behaviour for merchant-owned definitions deserves attention. If your team has modelled internal data as metaobjects, cost inputs, supplier notes, negotiated terms, those fields are now selectable by anyone with report access. That is a governance question, not a technical one. Teams running a PIM alongside Shopify should also decide which system is the reporting source of truth before both start answering the same question slightly differently.
Role-specific impact
- Marketers: merchandising questions that previously needed an analyst are now self-serve. Group sales by any structured attribute you already maintain and segment campaigns against the result.
- Developers: no code change is required, but review app-created definitions before enabling Analytics on them. A definition with high cardinality will make reports unwieldy rather than useful.
- Store admins: audit which merchant-owned definitions are exposed and switch off anything holding cost, margin or supplier terms that should not appear in a general report.
Use-case example
Real-world scenario
A multi-brand apparel retailer models each label as a Designer metaobject carrying country, tier and contract start date, referenced from every product. Answering the question of which sourcing regions were driving full-price sell-through meant a monthly export and a manual join, roughly four hours of analyst time per cycle. Grouping a sales report by Designer then Country now answers it in the admin. The team found that one region accounted for 31 percent of revenue but a disproportionate share of markdown, and moved its buy allocation before the next season rather than after it.
Implementation checklist
- List your merchant-owned metaobject definitions and note which are now exposed to Analytics by default.
- Switch off any definition holding cost, margin, supplier terms or other data that should not be broadly readable.
- Confirm which resources carry metafield references to each definition, since only referenced metaobjects surface.
- Rebuild one existing export-based report in Analytics and compare the numbers before retiring the export.
- Decide whether your PIM or Shopify is the reporting source of truth for shared attributes, and write it down.
- Brief the merchandising team on where the fields live in the picker so the capability is actually used.
FAQ
Q: Do we need to restructure our metaobjects for this to work?
A: No. Existing metaobjects and the metafields that reference them are unchanged. Only the reporting layer gained the ability to read through the reference.
Q: Why can we not see fields from a metaobject an app created?
A: App-created definitions stay off until Analytics is turned on for that definition, either by you in Settings or by the app itself.
Resources
Metaobjects in the Shopify Help Center
Need guidance? Talk to Makro.