Shopify App Events now put an app's own activity inside Shopify Analytics, next to sales and sessions, instead of in a separate dashboard the merchant has to remember to open. Shipped on October 28, 2026, the feature lets an app declare events, send them through the App Events API, and have merchants query them with ShopifyQL. For anyone building or commissioning a Shopify app, the real question is whether this replaces the analytics screen you were going to build, or just sits beside it.
What Shopify shipped on October 28
Apps can now declare events in an analytics_app_events extension, and every declared event they send becomes queryable by the merchant under FROM app_events. The changelog entry describes two kinds. Standard events come from a Shopify registry, so an email app and an SMS app reporting the same thing share one metric name. Custom events carry your app's handle as a prefix and your own attributes and metrics.
The registry is broader than the announcement suggests. The App Events in Analytics guide and its registry list 104 standard events across 18 categories, from checkout offers and loyalty points to return inspections, fraud decisions and restock alerts. A second release the same day lets Checkout and Customer Account UI extensions on API version 2027-01 send events directly with shopify.appEvents.emit(), with no backend and no network access.
App Events vs a custom dashboard: the trade
App Events win on placement and lose on depth. A merchant who already lives in Shopify Analytics sees your numbers without a login, an iframe or a CSV export, and can group a standard metric by app_name to compare you against a competitor in the same category. That comparison cuts both ways, and app teams should expect it.
The limits decide the rest. Each request carries one event, with no batching, and at most 15 attributes. String values cap at 128 characters. You can slice by attribute for only 30 days. After that, count and sum metrics survive as hourly summaries for up to 365 days, with no attribute breakdowns. And app_events cannot be joined with another dataset in the same query, so a merchant cannot divide your upsell revenue by their own order count inside one ShopifyQL statement.
A custom dashboard keeps everything those limits cut: long retention per dimension, joins with order data, per-customer views where the merchant has a lawful basis for them. App Events forbid personal data in attributes outright. Our read is simple. App Events become the summary layer every merchant sees. Your own screen stays the drill-down layer power users pay for.
The checkout extension detail that will bite
Events emitted from checkout only leave the page once the buyer allows analytics processing, and the extension cannot tell when they never do. The checkout extension reference spells it out. Before consent, events are held on the page, and the oldest are dropped if too many pile up. If the buyer declines or leaves, nothing is sent. Each extension also gets a burst of 20 events, then 2 per second.
The sharpest edge is the Shop app. Checkouts there never send extension events, yet emit() still reports success. So a returned {success: true} means the event was accepted locally, not delivered. Any conversion rate you compute from emitted impressions will skew toward buyers who accepted analytics cookies, and in consent-heavy markets like the EU a large share of buyers decline. Treat extension events as a directional signal and keep revenue-grade numbers on the server, where order webhooks are not gated by browser consent.
What we would actually change this quarter
Map your app onto the registry before you design a single custom event. If your app shows post-purchase offers, issues loyalty rewards or sends restock emails, a standard event already exists, and declaring it gets you into every merchant comparison for free. Custom events are capped at 15 per app, so spend them on what is genuinely yours.
Design the schema as if it were permanent, because it nearly is. Released declarations must stay compatible: event names, attribute types, metric aggregations and declared currencies cannot change, and an incompatible schema needs a new event name. That is a database migration discipline applied to analytics, and it rewards a short design review before the first shopify app deploy.
Send money as integers in minor units with a declared currency, set a stable idempotency_key per real-world action (the API dedupes for 24 hours), and remember the 500 requests per second ceiling per app before you replay a backfill. On the merchant side, ask every installed app whether it reports into Analytics yet. An app that does is easier to audit at renewal time.
For merchants on Shopify Plus, this also changes how we scope custom app work on our e-commerce engagements: a reporting screen we would have quoted as a feature becomes a few declarations plus a server emitter. The automation side follows the same logic. Flows we build under automation can now leave a queryable trail in the admin instead of a log nobody opens. If you are already working inside checkout extensions, our note on the 64 KB bundle budget covers the other constraint you will hit alongside emit().