> ## 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. # Store profile A store profile is everything Meridian knows about one shop, on one screen: what it pays, how long it's been around, who to talk to, and what it did. ## The header The store's name, whether it's **active**, **on trial**, **frozen** or **churned**, and its plan with its price. The line under the name gives the store's domain and the date it joined. A store on trial also shows its trial end date in the shop details card. Next to the status, the plan pill shows the store's plan with its billed price and how often it bills: **Pro · $49.95/mo**, or **Pro Annual · $499.00/yr** for a yearly plan. It is the plan's price, not what the store brought in this month: usage and one-time charges are not part of it (the store's MRR, which does include recent usage, is on the [Stores list](/dashboard)). A store with no running paid subscription shows the plan name alone. An installed store reads **Free** after a known cancellation of its last subscription. Frozen and uninstalled stores keep the name of the last plan they paid for. The plan price, the five numbers below, the revenue chart and the last charge are all in the store's own billing currency, with no conversion. ## The five numbers | Stat | Window | | - | - | | **Total revenue** | All time | | **Monthly revenue** | Current month | | **Average monthly revenue** | Across the months it's been active | | **Active days** | Since first install | | **App events** | Charges recorded for it | **Total revenue** is the store's [LTV](/dashboard): what it has been billed over its lifetime, renewals included and refunds deducted. **Monthly revenue** is the same figure for the current calendar month so far, and the revenue trend below draws it month by month, so the chart adds up to the total. Two things can make a paying store read \*\*$0** for the month. Shopify bills a plan every 30 days rather than once per calendar month, so a store billed on January 31 renews on March 2 and February shows nothing, while a store billed on January 1 renews on January 31 and January shows two cycles. And billing transactions reach Meridian once a day, so a charge billed today shows tomorrow: early on the 1st, every store reads $0. ## The charts * **Revenue trend**: monthly revenue over 6 months, 12 months, or all time: since the store first installed, or since its first charge when its billing history goes back further than the install Meridian has on record. * **App events**: monthly event count, split into charges and installs, so a spike in revenue can be traced to what caused it. ## Usage What this store has metered **in its current billing period**, against what its plan allows: the per-store mirror of what your own app reads through [`getUsage()`](/events). The **App events** chart above shows volume over months; this card shows where the store stands right now. The card header states the period it covers: the store's own 30-day subscription cycle, or the calendar month when it has no subscription (usage is still metered either way; the store just has no plan terms to be measured against). | Row | What it shows | | - | - | | **Event** | What the store used this period. When its plan meters that event, a bar of used against included, the amount it's over by, and the overage units already billed this period | | **View** | The [view's](/usage-views) value for this store over the view's own window, with that window's dates underneath | Every key links through to its event's page under **Usage**. A view has no page of its own, so it links to the event it interprets. Two things the card can say instead of figures. If your app hasn't declared any [usage events](/events) yet, it points you at **Usage** to define some. If it has, and neither its figures nor its last 30 days show anything, it says exactly that rather than showing a list of zeros. These are billing-period figures, so they reset at each cycle boundary and match what the merchant's app sees. They are the same numbers Meridian bills overage against, not a separate report computed for the dashboard. ### The trend beside each row Every row carries this store's **last 30 days** to the right of its figure, events and views alike, under a single **Trend: last 30 days** label. It is a fixed span rather than each row's own window, and deliberately so: an event is measured over the billing period and a view over whatever window it defines, so those windows differ in length from row to row. Only a shared axis lets a column of trends be read as a stack. Otherwise two neighbouring lines of the same width would cover different amounts of time. The series is a calendar, not a list of active days: a day the store reported nothing is a zero, not a gap. That is what makes a flat line at zero meaningful: it says this store is not using that metric, which is usually the reason you opened the page. Nothing is drawn below two points. ## Recent usage events Under the Usage card, the last events this store reported, **exactly as your app sent them**, with no totals in between. Where the Usage card answers "where does this store stand against its plan", this one answers "what did its app actually send", which is the question a figure that looks wrong raises next. Each row carries the timestamp, the event key, the quantity, and a preview of the properties your app attached. Click the preview to open the whole object, the same panel the [Activity feed](/usage-activity) uses. A key that isn't in your [event catalog](/events) shows in the warning tone here just as it does there, so an integration typo is visible on the store that is sending it. **All N →** opens the Activity feed already filtered to this store. The filter arrives through the URL (`?shop=…`), so it survives a refresh, and the field stays free text from then on, ready to be widened or cleared. ## Shop details One card in the right rail holds the store facts the header leaves out. The header already gives the store's domain, status, plan with its price, and the date it joined, so none of those repeat here. | Row | When it shows | | - | - | | **Mode** | Always: **Live** or **Test store**. Development stores are left out of counts across the product, so this is how you know which kind you're looking at | | **Shopify domain** | Only when the store has a custom domain. The header shows the custom one, and this row keeps the `.myshopify.com` address that support and the Shopify API use | | **Country** | Only once the store has identified (see below) | | **Trial ends** | Only while the store is on trial | | **Last charge** | Always: the amount and date of the store's most recent non-test charge (subscription, usage or one-time), for example **\$12.40 · 10/06/2026**. Test charges are excluded. **Transactions and billing** lists each recent charge with its own amount. A store with no non-test charge shows a dash | The country is the one on the merchant's Shopify shop address, and it reaches Meridian only through the SDK [identify](/sdk-identify) handshake. A store that has never identified has none, so the row is absent rather than blank. ## Transactions and billing A preview of the store's recent [transactions](/introduction-12), with a link through to its full **billing history**: past invoices with their amounts and whether each is paid, pending or overdue, and the total due. ## Contacts The named people at this store, and the shop inbox as a fallback. See [Contacts](/store-contacts): this is where an [automation](/send-email) addressed to "store contacts" gets its recipients. ## Custom fields Your own attributes on this store, editable in place. **Emptying a field removes its value**. A blank text value is never stored, so "unset" and "empty string" don't drift apart. Define the fields first in [Custom fields](/custom-fields). ## App Store review If your app's [listing is linked](/app-store-listing), the review this store left on it appears here, with a link to the listing. The match is **indicative, not certain**: it's based on the reviewer's store name and how long they used the app, because App Store reviews carry no store identifier. Meridian says so on the card rather than presenting a guess as a fact. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.