Skip to main content
The Report Builder is for the questions the fixed Analytics screens don’t answer. Pick a visualization, choose a dataset, group and measure it, filter and date-range it, then save. Custom reports are a plan feature; without it, the builder explains that rather than hiding.

Saved reports

The list carries each report’s name, dataset, visualization, when it was updated and who created it, and the list is searchable, filterable by dataset, and favouritable so the ones you actually use stay at the top. From a report you can save as new, duplicate, export CSV, or delete it.

Building one

A report definition is:
  • a visualization,
  • a dataset: what you’re reporting over,
  • dimensions to group by (up to 4), with a grain for date dimensions: daily, weekly or monthly,
  • metrics to measure (up to 10),
  • filters (up to 20), combined with And or Or,
  • a date range: today, yesterday, last 7 / 30 / 90 days, last 12 months, month to date, year to date, all time, or a custom range (UTC day boundaries),
  • an optional comparison against the previous period or previous year,
  • and sort and a row limit.
Funnel and retention cohort add their own fields (steps, entity, entry and activity dates) in the config rail after the dataset, once you pick that visualization. Changing the dataset keeps the visualization you picked when the new dataset can show it. A funnel needs something to count and fields to set step conditions on, and a cohort needs a date to bucket by. If the new dataset cannot show it, or it is still the current dataset’s default, the report takes the new dataset’s default. Either way, the dimensions, metrics, filters, funnel steps and cohort fields start over, because they name the old dataset’s fields. The result pane updates as you configure, and tells you what it did: the date range, the row count, and how long the query took. If the row limit truncates the result it says so, rather than quietly showing a prefix.

Filter operators

is · is not · contains · does not contain · is one of · is none of · is set · is not set · is greater than · is at least · is less than · is at most List operators take comma-separated values, and boolean fields read as Yes/No.

Visualizations

Table, line, bar, stacked bar, donut, single value, plus two that compute their own columns: Funnel: between 2 and 8 ordered steps, each with a condition, showing how many entities reach each step and where they drop. Retention cohort: pick what to count, the field entities enter on, and the field they stay active on, over up to 24 periods. Unlike the built-in cohort screen, you choose the entity and the fields. Both need their own configuration before they can run, and the builder says which piece is missing instead of returning an empty chart. Charting a report also needs a dimension and a metric, otherwise it tells you to add one or switch to a table.

Datasets

Each report reads one dataset: a curated, reportable view of your data. Datasets span CRM (stores, trials, subscriptions, lifecycle events, transactions, segments), Emails, Automations, Affiliates, Plan Builder (discounts, redemptions, subscriptions, usage events), and hosting (deployments, webhooks, security scans, activity). Custom fields are attributes of a store, not a separate dataset. On Stores (and every other store-grained dataset) you can filter on any non-json custom field, group by select / boolean / date fields, and measure number fields as sum or avg. The same fields need the custom fields permission; without it they do not appear on the stores catalog. Usage on Stores. With Plan Builder access, the Stores dataset also offers each catalogued usage event as count and quantity measures over the report’s date range, plus each ready usage view as its current windowed reading (the same figure getUsage() returns). Event measures follow the date range you pick; view measures follow the view’s own window. When a report uses any of those usage fields (as a metric, a filter or a funnel step condition), the date range applies to the usage aggregates rather than filtering stores by install date. That way you can report usage across every store, and a funnel of stores that synced an order in the last 30 days also counts stores installed long before. All time then starts at the earliest usage row rather than the earliest install. The separate Usage events dataset remains available for funnel and cohort reports that need one row per event. Transactions on Stores. With the transactions permission, Stores also offers date-ranged rollups from the billing ledger: gross, net and transaction count over the report’s date range, plus the same three figures split by type (subscription, usage, one-time, adjustment, credit). Those fields sit next to plan and lifecycle so you can ask “revenue last quarter by plan” without leaving Stores. The Total revenue measure is the store’s all-time LTV: it reads the same ledger, all time and whatever the date range, and falls back to Partner charge events for an app whose ledger has not synced yet. Total charges stays a count of Partner charge events. When a report uses any of the ledger fields (as a metric, a filter or a funnel step condition), the date range applies to the transaction aggregates rather than filtering stores by install date, and All time starts at the earliest ledger row rather than the earliest install. The separate Transactions dataset remains available when you need one row per money movement. Finding a field. The group by, metrics and filter pickers are searchable and grouped by where each field comes from: the dataset’s own fields first, then Custom fields, Usage events, Usage views and Transactions. Once an app has a few dozen custom fields and usage events, type to filter instead of scrolling the whole list. You only see the datasets your plan and permissions allow. A dataset your plan excludes is locked with an upgrade prompt rather than disappearing, and each dataset requires its own CRM or hosting permission on top of the report permissions that gate saved reports. A saved report reading a dataset you can’t access says so instead of running. The billing datasets (Subscription items, One-time grants and Billing subscriptions) also follow your role’s apps: a role limited to some apps sees only those apps’ billing lines, without the organization-wide ones, and no billing subscriptions, since a subscription covers every app. If a field a report uses is deleted, it’s marked as a deleted field rather than silently dropped.
There’s no free-form SQL. Every field, filter and grain comes from the dataset’s declared catalog and every value is bound. A report can only ask for data you’re allowed to see.
Last modified on October 8, 2026