That sounds a bit dry. It isn't, once you think about what most custom apps actually do all day.

What Shopify has changed

Shopify already had something called App Events. It lets an app tell Shopify "this just happened": an onboarding step finished, a text message was sent, a sync failed. Until now those events turned up in the developer's Dev Dashboard logs (kept for 30 days) or fed usage-based billing. Useful for the developer. Invisible to the merchant.

The new bit is that an app can now declare which of its events should appear in Shopify Analytics. Once declared and released, the merchant can query them with ShopifyQL using FROM app_events, or pull them into a report. Shopify's changelog says existing integrations need no changes unless the developer wants their events to show up there.

There are two flavours of event:

  • Standard events, which come from Shopify's own registry and start with shopify. (an email being sent is one example). Shopify supplies the label, the attributes and the metrics.
  • Custom events, which the developer defines, prefixed with the app's handle. These need a label and a category picked from a fixed list of 17, such as Checkout, Marketing or Inventory.

Checkout and Customer Account UI extensions can also send standard events now, from API version 2027-01. Those only go out when the buyer has allowed analytics processing, which is as it should be.

Why this matters if you've got a custom app

Most of the bespoke Shopify work out there isn't glamorous. It's an app that pushes orders to a warehouse, pulls stock levels from an ERP, sends wholesale quotes, or tidies up product data overnight. When it works, nobody notices. When it quietly stops working, you find out from an angry customer or a stock count that doesn't add up.

The usual answer is a developer digging through logs. Now there's another option. If your stock sync reported "items updated" and "sync failed" as events, you could see a chart of both in Shopify Analytics, next to your orders, without ringing anyone.

A few things I'd consider measuring first in a typical custom app:

  • Syncs completed and syncs failed, broken down by which system they talk to.
  • Orders sent to the warehouse or 3PL, so you can compare them against orders taken.
  • Quotes sent or approved, if you've got a wholesale or B2B app.
  • Anything your app charges you for by usage, so you can see the volume yourself.

None of that is clever. It's just turning "I think it's working" into a number you can check.

The small print worth knowing

A handful of details in Shopify's docs will catch people out if they rush it.

You have to declare events up front. They're declared in an analytics_app_events extension and released with shopify app deploy. Events your app already sends for logs or billing don't appear in Analytics automatically. They have to match a released declaration.

Released definitions are hard to change. Once an event is live you need to keep its name, kind, attribute types and metric setup compatible. If you need something incompatible, Shopify's advice is to create a new event name. So it's worth ten minutes of thought before you deploy, rather than after.

There are limits. Up to 15 custom events per app, up to 15 attributes per event, and string values up to 128 characters. Plenty for most apps, but not a dumping ground for everything.

History is shorter than you might expect. Attributes can be used for filtering and grouping for 30 days. Count and sum metrics are kept in hourly summaries for up to 365 days, but without the attribute breakdowns. If you want a year of "failed syncs by supplier", you'll need to keep that yourself.

It's one event per request. In Shopify's words, "Batch requests aren't supported." The API allows 500 requests per second per app, and a 202 response only means Shopify received the event, not that it's queryable yet. Validation happens afterwards, so build in some way of spotting events that are being rejected.

No personal data. At all. Shopify is explicit that event attributes mustn't include anything that could identify a person, including names, email addresses, phone numbers and customer IDs. That's a sensible rule, and an easy one to break by accident if someone just passes the whole order object through. Worth checking in code review.

Authentication is its own thing. The App Events API uses a client ID and secret from the Dev Dashboard to get a bearer token that expires after 60 minutes. Check how an older app will handle that before promising anyone a dashboard.

Should you bother?

If your custom app does one simple job and has never caused you a moment's worry, probably not yet. There's no deadline here and nothing breaks if you ignore it.

If you've got an integration that sits between Shopify and your warehouse, ERP or accounts package, and the main way you find out it's struggling is a phone call, then I think it's well worth a look. It's a fairly small piece of work to add a few well-chosen events, and the payoff is that the people running the shop can see what the app is doing without needing a developer to translate.

Want a hand?

We build and look after custom Shopify apps and integrations, and API work connecting Shopify to ERPs, 3PLs and accounting tools. If you'd like someone to look at your app and suggest which events are worth reporting (and check nothing personal leaks into them), get in touch. And if you'd rather have someone keep an eye on all of this for you, that's what our outsourced tech department is for.

Cheers, Rob