Analytics

Insights → Analytics computes revenue, orders, average order value and conversion from your own order and cart tables.

There is no external analytics account in the read path. The numbers on the page are your rows, counted. That is deliberate: a figure you can trace back to an order is a figure you can defend, and it does not stop being available when a tracking script is blocked or an account lapses.

The same admin also carries a store-wide activity log, and events can be forwarded to PostHog, GA4 and Meta in parallel with your database — which stays the source of truth.

The page lives at:

Insights → Analytics
/admin/analytics

It requires the analytics:view permission.

Where the numbers come from

Revenue and order counts are queried from the orders that fulfilled.

That is the whole read path. No pixel, no sampled session data, no third-party dashboard that has to agree with your database before you can trust it.

The practical consequence is that a number you dispute can be chased down to the rows behind it, which is what the activity log and the per-card detail pages are for.

Two clocks on the revenue trend

The revenue trend card plots two series, and they are not on the same clock.

• Revenue is plotted on the cash ledger — when the money moved
• Orders are plotted on the placement date — when the customer bought

Both are labelled on the card rather than being averaged into one line.

This matters because the two answer different questions. An order placed on the last day of a month whose payment settles on the first of the next belongs to different periods depending on which question you are asking, and a single blended series would quietly pick one for you.

Books Health

The Books Health card compares the revenue projection against the Stripe payment ledger, all-time.

For each row it shows either a pass, or the exact difference in cents.

Does what the store thinks it earned match what the payment processor recorded?

A discrepancy is reported as a signed difference and never corrected for you. The card is a reconciliation, not a repair — the point of the number is that you go and find out why it is there.

Read this card before you read anything else on the page. Every other figure sits on top of the same revenue projection.

How the page is organised

The dashboard leads with sections grouped by the question they answer, rather than by which table the data came from.

The order is:

1. Growth
2. Revenue drivers
3. Loyalty
4. "Which campaigns made money?"
5. "Is inventory a problem?"
6. "Where do customers drop off?"
7. The card grid

The card grid

The cards available are:

• Top sellers
• Abandoned carts
• Cart recovery
• Cohort retention and LTV
• Link attribution
• Feed performance
• The collab cards

Each one renders a chart plus a "View all" link to its own detail page for the full rows:

/admin/analytics/[table]

Two controls shape the grid. The picker decides which cards appear at all; the period selector decides the window they cover.

The activity log

Create, update, delete and duplicate on the store's records each write one Activity row, recording the admin who did it and the record it touched.

You can filter that log by:

• Module
• Activity type
• Date range
• The specific customer, product, order or collab involved

This is how you get from a figure to a cause. A revenue number that moved unexpectedly is a change somebody made, and the log names both the change and the person.

Forwarding events elsewhere

Your database is the source of truth. Forwarding is additive — it sends a copy of an event to the marketing and product-analytics tools you already use.

Three providers receive events from the server, through a single forwarder (forwardServerEvent, if a developer needs to find it):

• PostHog, through its capture endpoint
• GA4, through the Measurement Protocol
• Meta, through the Conversions API

Each one is only contacted when its keys are set, all three are called in parallel, and a failing provider never throws. An outage at an analytics vendor cannot take down the request that triggered the event.

Four trackers load in the browser, behind two separate consent gates:

• Plausible and GA4 load on analytics consent
• The Meta and TikTok pixels load on marketing consent

Nothing loads before consent is read.

Getting data out

Two routes, depending on how far you want to go.

The activity log and the admin tables export to CSV.

Beyond that, you can run plain SQL against your own database. This is possible precisely because the read path holds no external analytics account — the numbers are in tables you own, not in a vendor's dashboard.

Working the page

Start with Books Health. If revenue and the payment ledger disagree, every downstream figure inherits the disagreement.

Then pick a period and the cards you want, and follow a card's "View all" link when the chart raises a question the summary cannot answer.

When a figure looks wrong rather than merely surprising, open Insights → Activity and trace it back to the change and the person behind it.

Set only the provider keys you actually use. Unset providers are skipped, not failed.

The habit worth keeping is this one:

A number here is a claim about rows you own — so when it surprises you, go and read the rows rather than reaching for a second dashboard to confirm it.

Related