> ## Documentation Index
> Fetch the complete documentation index at: https://help.the-meridian.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Activity and usage by store

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](/events#dated-events) (a delayed sync, a replay) appears at its own date, further down the log, rather than at the top.

| Column | What it shows |
| - | - |
| **When** | When the action happened |
| **Event** | The key your app reported |
| **Qty** | The quantity on that call |
| **Store** | The shop that reported it |
| **Properties** | The properties you sent, as stored |

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.

<Note>
  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](/events#which-period) instead, shown by the [SDK's usage readout](/events), by their [account page](/account), and, for one store at a time, by the **Usage** card on that [store's profile](/profile-1). For a windowed reading your app can consume, define a [view](/usage-views).
</Note>

## 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](/usage-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](/report-builder). Usage is one of its datasets, with event count, total quantity and distinct stores as measures.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.