Lifetimely: Report prefiltering
Report prefiltering
At a glance
Pre-filters are saved, store-wide exclusion rules that define the orders and customers Lifetimely normally uses in reports. Use them to remove test, unpaid, draft, cancelled, POS, wholesale, or other activity that should not influence sales, profit, cohort, or retention decisions.
Availability and data freshness
Availability: The current Settings > Pre-filters page is available in an authenticated shop context and has no plan or feature-flag gate in the current UI. Its controls use Shopify order statuses, tags, app channels, and source names; a rule has no effect when the selected store's source data does not contain the matching value.
When changes take effect: Saving updates the shop setting immediately, and pre-filters are supplied with later report requests. They apply to qualifying historical orders as well as future orders; they do not delete or alter source records. Reload the report before reconciling it after a settings change.
On this page
- Open and save pre-filters
- Choose exclusions
- Understand how reports apply them
- Understand customer and cost consequences
- Compare pre-filters with report filters
- Reconcile an unexpected result
Open and save pre-filters
- Open Settings.
- Select Pre-filters (
/settings_v2/prefilters). - Select every status or value that Lifetimely should exclude.
- Select Save. Discard restores the last loaded values.
The page loads the current shop's saved settings. Boolean controls are shown as unchecked when the API does not return a saved value. New shop-setting records initialize Cancelled Orders as excluded, but existing shops can have a different saved value; use the checkbox state shown for the selected shop as the source of truth.
Caution: Every selected option is an exclusion. In the report request contract,
truemeans “exclude matching orders”;falseor an omitted value adds no exclusion. Selected values in the tag and channel fields are also excluded.
Choose exclusions
The current page groups controls under Payment status, Orders, Sales channels, and Customers.
| Current control | What the shared report pipeline excludes |
|---|---|
| Pending | Orders whose financial status is pending. |
| Authorized | Orders whose financial status is authorized. |
| Zero Value Orders | Orders whose total price is zero or less. This can remove free or sample orders from order and customer metrics. |
| Draft Orders | Orders whose source name is shopify_draft_order. |
| Cancelled Orders | Orders with a cancellation timestamp. |
| Order tags to exclude | Orders having any selected tag. Matching trims whitespace around each source tag and otherwise uses an exact match. |
| Exclude all order tags where name contains | Orders having any tag that contains any entered term. Enter comma-separated terms; whitespace is trimmed, blank terms are removed, and the page accepts at most 50 terms. Matching is case-sensitive in the current ClickHouse query. |
| POS | Orders whose source name is pos. |
| Sales channels to exclude | Orders whose app ID resolves to any selected app-channel title. The selector searches the channel titles available in report data. |
| Sales Channel IDs | Orders whose source_name equals any selected value returned by the sales-channel search. Despite the current helper text saying “Only these channels will be included,” the active report query excludes them. Treat this as an exclusion control; the UI wording and “IDs” label require owner correction. |
| Customer tags to exclude | Orders belonging to a customer having any selected customer tag. Matching trims whitespace around each source tag and otherwise uses an exact match. |
All enabled rules are cumulative. For example, selecting POS and Cancelled Orders keeps only orders that are neither POS nor cancelled. Entering several tags excludes an order or customer when any configured tag matches.
The API also supports raw app-channel IDs, but the current page does not expose that field. This is not an additional customer-facing control.
Data contract: how reports apply pre-filters
Reports that use the shared Merchant Insights order-filtering pipeline receive the current shop's saved pre-filters with the report request. The pipeline:
- selects orders for the requested shop and applicable date scope;
- applies all enabled status, value, channel, and order-tag rules, removing an order when any exclusion matches;
- removes customers matching configured customer tags when resolving eligible customer records;
- builds the qualifying order and customer population;
- applies any report-level complex filters used for that analysis; and
- aggregates the remaining orders, customers, line items, refunds, and associated costs.
Pre-filtering therefore changes more than the rows visible in a table. It can change sales and profit, order and customer counts, a customer's first qualifying order, new-versus-repeat classification, acquisition cohort membership, repurchase rate, and LTV.
Implementation scope: This contract applies to reports built on the shared
PrefiltersandPrefilterQueryBuilderpath, including core Profit & Loss, LTV, and Customer Behavior calculations that send these settings. Integration-only values, such as ad spend, are governed by their integration and account settings unless a report explicitly joins them to the qualifying order population. A report that uses another calculation path must document its own population rules.
Source fields used for matching
| Exclusion type | Imported field used |
|---|---|
| Payment status | Order financial_status |
| Zero value | Order total_price |
| POS, draft, and Sales Channel IDs | Order source_name |
| Cancelled | Order cancelled_at |
| Sales channels to exclude | Order app_id, resolved through Shopify app metadata title |
| Order tags | Imported order tag array |
| Customer tags | Imported customer tag array |
A pre-filter uses the imported value available to Lifetimely. If Shopify changes a status, cancellation, tag, or channel and that update is imported, later calculations can change for historical periods.
Customer, first-order, refund, and cost consequences
First qualifying order
First-order calculations use the order population after order pre-filters. If a customer's actual earliest order is excluded, their next qualifying order can become their first order for reporting. This can move the acquisition date and change:
- new and repeat customer counts;
- cohort membership and cohort LTV;
- first-order product, channel, UTM, tag, and geography breakdowns;
- repurchase calculations; and
- complex filters that distinguish first-order from any-order behavior.
Example: A customer places a $0 sample order in January and a $60 paid order in February. With Zero Value Orders selected, January's order is removed and February can become that customer's first qualifying order. The customer moves into the February acquisition cohort, and the $60 order is treated as new-customer activity rather than a repeat order in reports using this pipeline.
Missing customer identity
Shopify orders with missing customer data can have a null customer ID. Amazon orders with missing customer data can use a generated ID ending in @unknown-customer. The shared query retains these orders where its customer lookup permits, but an order without usable identity cannot always contribute to customer-based metrics. New-customer plus repeat-customer counts can therefore be lower than total order count.
Refunds and costs
Where a report scopes refunds and order costs through the qualifying order population, excluding an order also removes its revenue, refunds, product costs, shipping costs, handling costs, and transaction fees. The shop's refund-date and refunded-product-cost rules still determine when and how a qualifying order's refund is counted; see the refund profile.
Ad spend, operating expenses, accounting entries, and other values not attached to an order are not automatically removed merely because an order is excluded. For example, excluding test orders can lower sales without lowering ad spend for the same period.
Pre-filters compared with complex filters
| Pre-filters | Complex filters |
|---|---|
| Saved under Settings > Pre-filters for the current shop. | Selected on a report or stored with a saved analysis/cohort. |
| Exclude statuses, zero-value, POS, draft, cancelled, channel, order-tag, and customer-tag matches. | Include or exclude products, SKUs, vendors, geography, discount codes, attribution fields, Klaviyo membership, and other supported dimensions. |
| Establish the shop's normal reporting population. | Answer a narrower question within that population. |
| Can redefine the first qualifying order before cohort and retention calculations. | First-order or any-order behavior depends on the chosen complex-filter rule. |
An “unfiltered” report can still have pre-filters because these settings are applied automatically and are not displayed as report-level filter chips. To compare two Lifetimely reports, confirm that both calculations use the shared pre-filter path before expecting them to match.
Consolidated and multi-store reports
A consolidated Income Statement applies each shop's own pre-filters before combining results. It does not take one shop's exclusions and apply them globally after aggregation. Two shops in the same consolidated view can therefore use different qualifying populations.
Reconcile an unexpected result
When Lifetimely is lower than Shopify or another report:
- Confirm the selected shop, report dates, timezone, and currency.
- Open Settings > Pre-filters and record every checked option and selected tag or channel. Do not rely on the absence of report-level filter chips.
- Find a missing order in Shopify and compare its financial status, total price, cancellation state, source/channel, order tags, and customer tags with the saved exclusions.
- If the order was the customer's earliest order, check whether the next retained order became the first qualifying order; compare cohort and new-versus-repeat results accordingly.
- Align any complex filters on the report. Removing a complex filter does not disable the store's pre-filters.
- Reload the report after saving changes.
- For profit differences, also verify the shop calculation profile. For report-specific population or formula differences, follow that report's reconciliation guidance.