Ship analytics in your Shopify app without building a data stack

There is a stage every successful Shopify app reaches where merchants start asking what it did for them. The feature works; now prove it. And the honest answer for most teams is that proving it costs more than the feature did. You end up running an event pipeline, a warehouse or at least a time-series table, a rollup job, a charting library, number and currency formatting for every locale a merchant might use, and a dashboard that never quite matches the numbers in Shopify's own analytics because it is computing them differently.

On July 21, 2026, at DotDev, Shopify shipped full-stack capabilities to power app analytics, which is a plain way of saying: that entire stack is now platform infrastructure. It lands in API version 2026-10. This post walks the four layers and, more usefully, what each one deletes.

Layer 1: get your data into the model

The interesting design choice here is that Shopify did not build a separate place to put app analytics data. It made the places your data already lives queryable.

Analytics-queryable metafields. A metafield can now be marked as analytics-queryable, at which point it becomes a ShopifyQL dimension: something you can group and break down by. If your app writes a supplier or margin_band or size_recommendation metafield onto products, merchants can now slice Shopify's own sales data by it. You wrote the data once, for your feature; the analytics capability comes free.

App Events. Your app emits custom events (an onboarding completed, a sync run, a recommendation accepted) and they become queryable in the same system as orders and sessions. This is the same App Events mechanism that underpins usage-based app pricing, which is a neat piece of platform design: one event stream serves billing and analytics rather than two.

Layer 2: query it with ShopifyQL

ShopifyQL has existed for a while as a query language for commerce data. What changed is status: it is now a first-class part of the platform, with schema-level reference documentation and stable, versioned queries. That is the difference between a feature you experiment with and one you build a product on.

The language reads like SQL that had the confusing parts removed. Three concepts: schemas are the queryable datasets you select with FROM, metrics are measurable values you retrieve with SHOW, and dimensions are the breakdown categories you segment by with GROUP BY.

1FROM sales2  SHOW total_sales3  DURING last_month

Add a time series:

1FROM sales2  SHOW total_sales3  TIMESERIES day4  SINCE -30d UNTIL today

Or a breakdown, which is where your custom dimensions land:

1FROM sales2  SHOW total_sales3  GROUP BY sales_channel4  DURING last_month5  ORDER BY total_sales DESC

From an app, you run these through the GraphQL Admin API and get structured table data back, with parse errors reported separately so you can surface a bad query intelligently instead of failing blank:

1query RunShopifyQL {2  shopifyqlQuery(3    query: "FROM sales SHOW total_sales, orders TIMESERIES month SINCE -12m UNTIL today"4  ) {5    tableData {6      columns { name, dataType, displayName }7      rows8    }9    parseErrors10  }11}

Note displayName coming back with the column metadata. Shopify is handing you the merchant-facing label for each metric, already localised, which is a small thing that saves you maintaining a translation map of every metric name in every language you support.

Layer 3: embed it without a charting library

This is the layer most likely to delete code you have already written. Two web components ship for embedding results directly in your app UI:

• <s-shopifyql-metric-card> renders a query as a metric card with its chart.
• <s-metrics-bar> renders a row of metrics, plus a date picker component for the range control every analytics view needs.

They handle the charting and the locale handling. Concretely, that is a charting dependency you do not add to your bundle, a set of currency and number formatting decisions you do not make, and a visual language that matches the merchant's admin instead of approximating it. It also means your metric card keeps matching Shopify's admin when Shopify redesigns it, which is a maintenance cost people consistently forget to price in.

Layer 4: the enrichment APIs

Two smaller APIs sit on top, and both are about your app participating in the merchant's analytics rather than running a separate universe beside it.

The Annotations API lets your app create annotations on charts through GraphQL, using the read_analytics_annotations and write_analytics_annotations scopes. If your app changed something (a price test started, a sync repaired a catalog, a campaign launched), it can mark that moment on the merchant's chart. The value is causal: a spike with a labelled cause is an insight, and a spike without one is a mystery the merchant will eventually blame on something.

The Metric Targets API exposes targets merchants set on metrics, so your app can reference them programmatically. That means your app can talk in the merchant's own terms ("72% of the way to your Q3 revenue target") rather than asking them to configure a goal a second time inside your settings page.

When this is the wrong choice

A fair post names the limits. Building on this couples your analytics to Shopify's data model, its query language, and its release cadence. That is the right trade for most apps and the wrong one for a few:

• Multi-platform apps. If your product also serves BigCommerce or WooCommerce merchants, you need a unified analytics layer of your own, and a Shopify-specific one becomes a second system rather than a replacement.
• Analytics as the product. If merchants pay you specifically for analysis Shopify does not do, your differentiation lives in modelling and computation that ShopifyQL will not express. Use the embed layer, keep your own model.
• Data that has to leave. Reporting that feeds a merchant's own warehouse, or joins data from systems Shopify has never seen, still needs a pipeline. The embedded components are for surfaces inside the admin.

For the large middle of the ecosystem, though, the app that wants a credible dashboard proving its own value, this is straightforwardly the right call. The dashboard was never the differentiator. It was the tax on having one.

Where to start

1. Read the changelog entry and the ShopifyQL reference. The schema-level docs are the new part and the reason this is buildable.
2. List the metafields your app writes and ask which are dimensions a merchant would want to slice sales by. Those are your analytics-queryable candidates, and marking them is close to free.
3. Write one ShopifyQL query that answers the question your merchants ask most often. If it answers cleanly, most of your dashboard is a query and a component.
4. Before you build any more of an in-house dashboard, price the <s-shopifyql-metric-card> version of it. Bundle size, formatting, and design drift are easy to forget and expensive to keep.
5. Plan for API version 2026-10, and check the DotDev 2026 roundup for the other removals landing in the same version.