Skip to main content
Two read-only views over what your app has reported, both under Usage. They exist so metering is something you can inspect, not just something that bills.

​
Activity

Usage → Activity is the raw log: one row per track() call, newest first. Rows are ordered by when the action happened, not when it arrived. An event your app dated (a delayed sync, a replay) appears at its own date, further down the log, rather than at the top. Filter by event key, store domain, and a date range. The event-key box suggests your catalog’s keys but does not restrict you to them, because the keys worth looking for are often the ones that aren’t declared.

​
Keys that aren’t in your catalog

Meridian accepts any event_key. That is deliberate: a metric you haven’t got round to defining, or a typo in a track() call, must never lose billable data. So those rows are recorded, and Activity shows them with an amber key and an Add to catalog button that opens the create form with the key already filled in. This is the fastest way to find an integration mistake. If you expected emails_sent and Activity shows email_sent, the log tells you immediately, instead of the metric quietly reading zero forever.

​
Usage by store

Usage → By store rolls the same data up per shop: total quantity, how many reports it sent, when it was last active, and the breakdown per event key. Most recently active store first. Set a date range to scope every figure on the screen to those days, inclusive, both the totals and the per-key breakdown. Leave it empty for all time. Use it to answer “who is actually using this”, to spot a store that stopped reporting, and to sanity-check a metric against a shop you know.
These figures are totals over the dates you picked, not billing-period figures. A date range is a range; a billing period is per store, so no single column here could mean it. What a merchant owes for usage on a given plan is measured over their current billing period instead, shown by the SDK’s usage readout, by their account page, and, for one store at a time, by the Usage card on that store’s profile. For a windowed reading your app can consume, define a view.

​
The event’s own page

Each event under Usage → Events opens on its lifetime figures: the day it first reported, how many events have arrived since, and how many stores sent them. Quantity appears as a fourth figure when your app reports a quantity other than 1, so it says something the event count does not. Below them, Reported volume charts what the event reported across every store. Pick the period: last 7, 30 or 90 days as one bar per day, last 12 months or all time as one bar per month. The subtitle states the range and the grain that are actually drawn, so a two-year history reads as two dozen monthly bars rather than seven hundred daily ones, and a metric that stopped arriving is visible on the event itself rather than only in the log. Both the figures and the chart are summed from a daily index. If some of your app’s earlier usage has not been indexed yet, the page says so rather than showing a total that is quietly short. The events are still in the log either way. Its views sit below the chart, each with its all-time total and recent trend.

​
Going further

For anything grouped, compared or charted (usage by month, by segment, against churn), use the report builder. Usage is one of its datasets, with event count, total quantity and distinct stores as measures.
Last modified on September 26, 2026