Usage events

Revenue tells you who pays. Usage events tell you who's getting value, which is the thing that predicts who keeps paying. When your app reports its meaningful moments (a first sync completed, a report exported, an onboarding step finished), each one lands here within seconds, attached to the shop that did it.

That stream is the foundation of the whole Behavior section: it powers web analytics, funnels, and usage metrics, and any event can trigger a flow, so "email merchants two days after their first sync" becomes a thing you can actually build.

Reading the feed

The Usage events page is the live feed. Filter pills across the top show every event your apps have sent with volumes, so one glance tells you what's being tracked and how much. Click a pill to filter, search by shop to follow one merchant's trail, and open any row to see the properties the event carried.

It's the quickest way to answer "did shop X actually use the feature?" without opening a database console.

Sending events well

The zero-code path is the PartnerConsole Pixel: one script tag and page views, sessions, and custom events flow on their own. For everything else, your app reports events through one HTTP call. Two habits make the data far more useful later:

• Name events after actions, and keep names stable. report_exported will still make sense in a year; ReportPage_Export_v2 won't.
• Put variability in properties. One order_synced event with a value property beats a dozen name variants, and numeric properties unlock sum and average calculations in usage metrics.

Start with the two or three moments that define activation for your product. You can always add more, and even a small set turns your funnels and flows from guesses into measurements.