Saved views, saved charts, and exports

A saved view keeps a live dataset query. A saved chart keeps an analytical configuration. A CSV export captures data at a particular generation point. They are separate features with different scope and completeness.

Saved views

Open Saved views → New saved view, name it, choose Customers, Transactions, or Events, and define the supported filters. Reopening the view runs the query against current authorized data, so its rows can change over time.

Edit the name/query when your investigation changes, or delete the saved view when it is no longer useful. Deleting the view does not delete its underlying transactions, customers, or events. Detail drill-down and return navigation retain the originating view/filter context where supported.

Saved views belong to the requesting account within its project access. A link is not an access token or a way to share a private report with an unrelated user.

Saved charts

From Charts, save the current app, metric, range, resolution, comparison, store/environment/product filters, visualization, segmentation, currency, and applicable cohort/window settings. Reopen it to rerun that configuration.

Switching to a different metric must use supported settings for that metric. A retention matrix does not preserve an irrelevant area-chart selection as a hidden extra behavior. A shared chart URL can reproduce configuration for an authorized recipient but does not grant membership.

Aggregate chart CSV

A chart CSV contains the aggregate report already loaded on screen, with its selected scope and range. It is useful for chart analysis and does not contain every contributing customer or raw store payload.

If the requested report failed, its export is unavailable. Do not silently replace an unavailable custom range with full history. To investigate every contributing normalized event/transaction row, use the durable export flow instead.

Email a normalized data export

Open Email a data export from the supported reporting surface. Choose Transaction history or Event history, the selected range or supported full-history option, and the applicable app/store/environment/product filters. Submit Queue export and inspect its status in the dialog.

The job is requester-private. Another project member cannot use your session to list or download your export simply because they share the project. The CSV is generated asynchronously and delivered as a link to your account email, not as an email attachment.

An oversized job fails with a size error rather than silently giving you a truncated complete report. Narrow the time range or filters and try again. A busy account must wait for its active job to finish.

Download and privacy

The gateway stores the report in private object storage and sends a bounded-lifetime link. Its secret token stays in the URL fragment and is submitted via same-origin POST, rather than being placed in request URLs/referrers. Expired links require a new export.

Export fields are normalized reporting data. Raw ledger payloads, API credentials, signing material, and account tokens are not included. Spreadsheet formula prefixes in store-controlled identifiers are neutralized, which can explain an escaped identifier when opening the CSV in a spreadsheet.

Troubleshoot delivery

Check job state, account email verification, the latest email, link expiry, and the self-hosted email/report gateway configuration. A queued job is not proof of a delivered email. For a large history, split it into bounded ranges. An aggregate chart and a transaction export can legitimately differ because they use different metric attribution rules. Metrics · Operations.