Analytics definitions

This page is the contract that decides whether a number is right. It answers, for every reported metric: what it counts, whether it includes tax, which currency it is in, which clock owns its day boundary, and what happens to it after a refund.

Read it before reconciling two numbers. For the underlying money and ledger lifecycles, read Financial semantics.

How to read a metric definition

Every money metric on this page is defined by the same seven fields. When a definition below omits a field, the default in this table applies.

Field	What it tells you	Default
What it answers	the business question, in one sentence	—
Formula	the aggregate over named stored columns, not prose arithmetic	—
Tax treatment	net of all tax, contains tax, is tax, or not money	merchandise money is net of all tax
Currency	reports are always in the store’s one configured currency	store reporting currency
Clock	which timestamp decides the day the value lands on	store-local reporting date
Restatement	order-dated immutable, event-dated signed, or snapshot	see Restatement
Freshness	worker cadence and worst-case lag	see Per-source freshness

Two rules follow from the template and are worth stating on their own:

• Rates are ratios of aggregate flows, never averages of daily percentages. A selected range sums its numerator and its denominator and then divides once. A rate is undefined — not zero — when its denominator is zero.
• Point-in-time metrics are not summed across days. Outstanding balances, inventory levels, RFM, and lifetime value read the last (or first) snapshot in the range. Adding their daily rows counts the same balance repeatedly.

Money and tax

Every store carries an order-level snapshot of whether prices were entered with tax included. One store can hold both regimes, so nothing may be summed across them without normalising first. Sellerlane normalises when the fact is written, not when the report is read.

Every merchandise figure is net of all tax, in both tax regimes. Gross sales, Discounts, Net sales, AOV, COGS-based gross profit and Shipping are reported after the tax embedded in a tax-inclusive price has been carved back out.

Tax is reported once, by the tax metrics. Taxes is the sum of every tax line on the order — the tax embedded in tax-inclusive prices and additive tax. It is the only place tax appears.

Therefore Net sales + Taxes is not double counting. It is the buyer-facing subtotal, and adding shipping, tips, additional fees and adjustments to it gives Total sales — the amount the buyer actually paid.

The same order in two regimes

Note

These two orders have the same merchandise value and the same effective tax rate recorded two different ways. They produce the same ladder shape, which is the whole point of normalising at write time.

Ladder term	India, GST-inclusive ₹11,800 order	United States, $10,000 + $2,000 tax
Gross sales	10,000	10,000
Discounts	0	0
Net sales	10,000	10,000
Taxes	1,800	2,000
Total sales	11,800	12,000

On the inclusive order the buyer-facing line money is 11,800; the 1,800 of embedded tax is subtracted from the line before gross_sales_cents and net_sales_cents are written. On the exclusive order the line money is already 10,000 and nothing is subtracted. Both then add the full tax back once, in Taxes, to reach what the buyer paid.

Before this normalisation the same metric names meant tax-inclusive money on one store and tax-exclusive money on another. If you are comparing a report against a figure captured earlier, that is the difference you are looking at.

Gross sales and Discounts on a tax-inclusive store

Tax is levied on the discounted base, so there is no per-line tax on the pre-discount total to subtract. Gross sales is derived by applying the line’s own realised net-to-gross ratio:

• net = discounted line money − embedded tax
• gross = round(pre-discount line money × net ÷ discounted line money)
• discount = gross − net

Discounts is defined as the difference, which is why gross − discounts = net closes exactly at every grain despite the rounding. Rounding is exact decimal, half away from zero.

One deliberate edge case: a line discounted to zero carries no tax line at all, so no ratio exists and the pre-discount total is used unchanged. On a tax-inclusive store that overstates Gross sales and Discounts by the same amount on that line. Net sales, Total sales, COGS, gross profit and AOV are unaffected because both terms move together.

Shipping and shipping tax

Shipping is reported net of shipping tax on exactly the same basis as merchandise. shipping_tax_cents is a breakout of the tax total, never an addend to Total sales — adding it to Shipping would count that tax twice.

Tax-inclusive price adjustment (formerly “Adjustments”)

The line labelled Tax-inclusive price adjustment is the out-of-zone tax adjustment: the cross-zone re-gross delta that arises only under inclusive pricing. It is honestly zero on a tax-exclusive store, because no such delta exists there.

It is measured, not derived. It carries no cash-rounding component: that column is dead in the platform (checkout assigns a literal zero), so including it would have been a permanent zero masquerading as a figure.

If Total sales does not equal the sum of its rungs, the difference lands in unattributed_total_sales_cents under its own name, and a database CHECK constraint rejects the row rather than letting the ladder close on a wrong split.

Note

Until recently this line was labelled simply “Adjustments” and was a residual — computed as Total sales minus every other rung, so the ladder closed by construction and any upstream error reappeared here wearing this label. On a tax-inclusive store with cash on delivery, what a seller actually saw was the tax on their COD convenience fee, presented as an adjustment they never made.

The sales ladder

Orders counts non-test, non-deleted orders with at least one reportable line item. Gift-card-only orders are excluded from core sales reporting: issuing a gift card creates a liability, not merchandise revenue. Gift-card and store-credit redemption are tenders, not discounts.

Term	Formula	Tax	Clock	Restatement
Gross sales	line money before discounts, less allocated embedded tax	net of all tax	order day	order-dated, immutable
Discounts	gross − net at line grain; presented negative	net of all tax	order day	order-dated, immutable
Returns	merchandise reversed by a refund linked to a return	net of all tax	refund-processed day	event-dated, signed
Non-return refunds	merchandise reversed by a refund with no linked return — goodwill and price-adjustment refunds	net of all tax	refund-processed day	event-dated, signed
Refunds	the full refund amount, tax and shipping included; positive	contains tax	refund-processed day	event-dated
Sales reversals	merchandise cancelled, edited or charged back away — the merchandise leg only; refunds are Returns and Non-return refunds	net of all tax	processed day	event-dated, signed
Total sales reversals	the same reversals expressed gross of tax — a disclosure figure, never subtracted a second time	contains tax	processed day	event-dated, signed
Net sales	gross − discounts − all refunded merchandise − merchandise cancelled, charged back or edited away	net of all tax	mixed	composite
Shipping	shipping charged net of shipping tax, less shipping reversals	net of all tax	order day / reversal day	signed net
Taxes	every tax line — embedded and additive — less tax reversed	is tax	order day / reversal day	signed net
Duties	not supported. The platform does not support duties: no order source persists an amount, the fact and rollup columns have been removed, and no family exposes a metric	—	—	—
Tips	tips captured, less tip reversals	not taxed	order day / reversal day	signed net
Additional fees	the COD fee, the one persisted customer-facing fee, less fee reversals	net of tax	order day / reversal day	signed net
Tax-inclusive price adjustment	the out-of-zone tax re-gross delta, less adjustment reversals. Zero on a tax-exclusive store. No cash-rounding component — that column is dead	not tax-basis dependent	order day / reversal day	signed net
Total sales	Net sales + Shipping + Taxes + Tips + Additional fees ± Tax-inclusive price adjustment + Unattributed	contains tax	mixed	composite
Average order value	(Gross sales − Discounts) ÷ Orders	net of all tax	order day	order-dated

The Total sales line is an identity, not a description: every component column above it is already the signed net of its own reversals, and the order fact’s total is built from exactly those addends. It holds in both tax regimes, and a fully cancelled tax-inclusive order returns Taxes and Total sales to exactly zero.

Average order value is not Net sales ÷ Orders. Its numerator is the order-dated merchandise after discounts — Gross sales − Discounts — with no reversal term at all, so a refund never moves a past day’s AOV. Its denominator and numerator therefore share one clock, which Net sales ÷ Orders would not.

Caution

Net sales is not Gross − Discounts − Returns. Returns, Non-return refunds, Refunds and Sales reversals are disclosure components at four different grains — return-linked merchandise, refunded merchandise with no linked return, whole refund money, and the merchandise cancelled or edited away. Subtracting the wrong one, or subtracting two that overlap, does not give Net sales.

The ladder itself does close on the stored columns, in both tax regimes:

net_sales = gross_sales − discounts − returns − non-return refunds − sales reversals

where those four deductions are disjoint by construction. The trap is not that the identity is unavailable — it is that Gross − Discounts − Returns omits two of the four legs, and must never be presented as if it were Net sales.

Terms that look alike

Term	Where	What it actually means
Returns	Sales, Orders, Finance	merchandise on refunds linked to a return, net of tax
Refunds	Sales, Orders, Finance	the whole refund amount paid back, tax and shipping included, positive
Refunds	Payments	successful refund transactions, a payment flow, not a sales reversal
Sales reversals	Sales, Orders, Finance, Total sales by location	the merchandise-only reversal (net_sales_reversal_cents) — the leg that reduces Net sales. All four commerce families bind the same column
Returns	Returns by product, Returns by reason	a count of returned units, not money. The same word heads a negative-money column in the families above
Total sales reversals	Profit	the total-sales reversal at product grain, plus an order-grain residual row
Taxes	Sales, Orders, Finance	all tax charged, signed by later reversals, every order
Tax collected	Taxes family	all tax on orders whose payment landed, order-dated, refunds netted separately
Orders	everywhere except Taxes	non-test, non-deleted, at least one reportable line item
Orders	Taxes family	the same, restricted to paid / partially-refunded / refunded orders
Revenue	Products, Collections, Vendors, Recommendations	product-attributed net merchandise sales
Revenue	Traffic, Marketing, Search, session-location families	attributed total sales — a whole-order figure credited to a session or touchpoint
Net sales	Products, Collections, Vendors	product-attributed net merchandise; no shipping, tax, tips or fees

Reversal metrics are presented as negative signed contributions so displayed components add up to the displayed total. Never negate or subtract a signed reduction a second time.

Restatement: what changes after you looked

This is the section merchants need most. A report is not a photograph — parts of it move, and the rules for which parts are strict.

Positive bookings are order-dated and immutable. Gross sales, Discounts, Orders, ordered quantity, COGS, and the original shipping, tax, tip, fee and adjustment amounts are booked once on the order’s store-local day and are never reduced afterwards. Gross sales for 1 March is the same number in April as it was on 2 March.

Every reversal is event-dated and signed. A reversal lands as a negative row on its own processed day. It is never back-dated into the order day.

The two rules combine differently for different metrics. Gross sales, Discounts, Orders, ordered quantity and COGS carry no reversal, so they never move. The component metrics — Shipping, Taxes, Tips, Additional fees, Adjustments — are reported as the order-day booking net of reversals that landed on later days, which is why a single day’s Taxes can be negative when a large refund was processed and no tax was charged.

Event	Lands on
Refund, including return-linked	the refund’s processed date
Cancellation, full or partial	the adjustment’s processed date
Order edit	the adjustment’s processed date
Lost chargeback	the dispute’s resolved date
Return receipt (units)	the per-receiving date

A lost chargeback reverses revenue, not just payment state. Voiding the order alone would leave Sales, Finance and Profit carrying the full order value forever after the provider clawed the money back. The reversal is the order’s still-unreversed value, written in the same shape a full cancellation uses, so the existing machinery caps chargeback-after-refund and refund-after-chargeback without double reversal. A replayed webhook finds nothing left to reverse.

What this means when you read a report

• A single day shows that day’s placed orders at full value, plus reversals processed that day for orders placed at any earlier time. A quiet day with a large refund can be negative. That is correct.
• A range nets the two only when both the order and its reversal fall inside it. A range containing more reversals than it contains matching orders reads low, and Reversed quantity rate can legitimately exceed 100%. It is not clamped into a more comfortable but false range.
• Reconciling two ranges means aligning the event clock, not just the calendar. Original sales use order creation; refunds use refund processing; cancellations and edits use adjustment processing; chargebacks use dispute resolution.

Snapshot families are recomputed forward, never back-dated

RFM, lifetime value, product ABC, inventory day snapshots, month-end inventory and outstanding liabilities are point-in-time snapshots. A snapshot’s history is only as good as the day it was computed on. Selecting a date returns the state at that snapshot; adding snapshot rows across days counts the same balance many times.

The specific things that can change a number you already saw

• The rolling daily rebuild re-rolls the last 3 days on every 15-minute tick.
• Anything older is restated through the dirty-day queue when a late refund, identity link or attribution correction touches it.
• Snapshot families recompute forward only.
• Predicted lifetime value activates only after more than 100 eligible store orders, so it appears where there was previously nothing.
• A session that converts is retroactively marked not bounced, which lowers a past day’s bounce count.

Identity: session, visitor, and customer

These are three different units and only one of them is summable.

Unit	Definition	Summable across days?
Session (visit)	one retained visit row; opens on first qualifying activity, closes after 30 minutes idle or at UTC midnight	Yes
Visitor	a distinct first-party browser identity within the queried range	No
Customer	a resolved durable customer identity; a session may have none	n/a

Caution

Visitors is not summable. It is a range-distinct count. Adding daily visitor counts counts a visitor active on three days three times. For ranges up to 365 days the overview counts distinct identities over the whole range; beyond that it falls back to a summed daily approximation and says so in a report warning.

Staff, preview, test and bot traffic each carry their own traffic class, and the merchant rollups select human only — so those four populations are excluded by construction rather than by a filter someone could forget. Reports that deliberately include bots expose Human or bot session as a dimension.

A new visitor is not a new customer, and a returning customer can arrive from a browser that looks new. Customer status comes from order history; visitor status comes from the browser identity consent permits Sellerlane to retain. Declining analytics tracking means no visit is persisted at all.

Session authority and boundary

The durable Valkey session state — not the browser’s visit cookie and not a database lookup — is the session authority. State is isolated by a SHA-256 key over store, browser identity and traffic class; the raw browser identity is not present in the key. A request reuses the current visit only when all of these hold:

• the traffic class is unchanged;
• the activity is on the same UTC calendar day; and
• elapsed inactivity is strictly less than 30 minutes.

At exactly 30 minutes, and at 00:00:00Z, the next accepted activity receives a new visit token. The visit cookie’s lifetime is the shorter of 30 minutes and the remaining time to UTC midnight; it reflects the authoritative decision and is never an independent fallback resolver.

Document requests and validated browser collect events are activity. A context-token refresh is a heartbeat and does not extend the session. Token selection and the seller resolve intent commit in one Lua transaction, so concurrent tabs observe one new token and a retried create intent cannot increment the session count twice. If the result is uncertain the buyer retries once with identical task, intent and candidate token; if neither attempt is observable the request continues with no analytics context.

These rules move session counts, conversion denominators, bounce, landing pages and attribution. They never create, remove or change an order, payment, refund, tax or sales amount.

Engagement and bounce

• Page views count successfully recorded page-view events.
• Session duration is the observed span from first activity to last activity. The 30-minute timeout is not added as engagement time.
• A closed session bounces only when exactly one page view was recorded. A retained zero-pageview session is not a bounce, and neither is two or more.
• A session that produced an eligible order is never a bounce, whatever its page-view count — the conversion overrides the flag.
• Bounce rate is bounced sessions ÷ all sessions in scope. Sessions still open when the rollup ran sit in the denominator with bounced = false, so the current day reads low until those sessions close.

The two funnels

There are two funnels. They have different units and must never be read as one chain.

The session funnel is genuinely session-distinct and monotonic. Each stage counts sessions carrying a per-visit flag, and every rate divides by the same denominator, total sessions:

sessions → product view → add to cart → checkout started → purchase

• add-to-cart rate = sessions with add-to-cart ÷ sessions
• checkout-start rate = sessions with checkout start ÷ sessions
• conversion rate = converted sessions ÷ sessions

Checkout completion rate is deliberately different: converted sessions ÷ checkout-started sessions. A session that places two orders is one converted session but contributes two eligible orders to an order report.

The checkout step funnel is a count of raw checkout events:

contact submitted → address submitted → shipping submitted → payment info submitted

Caution

These four are event counts, not session counts. One shopper who edits an address three times contributes three address events. They can therefore exceed the session counts around them and they are not monotonic — a later stage can be larger than an earlier one. Do not compute a stage-to-stage rate across the two funnels; the units do not match.

Checkouts started and Checkouts completed in the Checkout family are also raw event counts, and Checkouts abandoned there is started − completed within the same day, floored at zero. A checkout that starts before midnight and completes after it is counted as abandoned.

The Overview’s checkout card is where the two bases sit side by side: its Checkout started, Checkout completed and Checkout abandoned figures are session counts, while its four middle steps are the event counts above. Read the card as two blocks, not one descending chain. The Overview’s conversion card, by contrast, is session-based throughout.

Time and currency

The reporting day is store-local

Date presets, daily buckets, comparison ranges and scheduled deliveries all resolve in the store’s configured reporting timezone. Reporting dates are stored columns stamped once from the event’s own timestamp in that zone, never recomputed at read time. Range starts are inclusive and ends are exclusive internally, so combining adjacent periods cannot double-count midnight.

Order, refund, adjustment, event and page-view reporting dates read the store’s timezone from the store record at write time. The one exception is a visit’s start date, which is stamped from the reporting timezone the storefront server sends on visit resolve; that server sends the store’s own timezone, and falls back to UTC if the store record carries none. A visit’s start date is therefore store-local in practice, but by a slightly different route than every other stamped date.

Comparisons resolve calendar periods in the same zone. “Previous period” is the immediately preceding equal-length calendar window; “previous year” maps to the corresponding prior-year calendar dates.

Hourly buckets are store-local wall clock. Under daylight saving the fall-back hour merges two real hours and the spring-forward hour is empty.

The deliberate UTC boundaries

Session close is UTC, on purpose, permanently. A session closes after 30 minutes idle or at UTC midnight, for session-count parity with Shopify. The consequence is real and is not hidden: on an Asia/Kolkata store the boundary falls at 05:30 local, so a visitor browsing at 05:25 and again at 05:35 is two sessions inside one store-local reporting day. Only the session’s close is UTC — its reporting day is still store-local, so daily session totals still bucket correctly.

Web vitals is the one family whose reporting dates are UTC. Its samples are bucketed by UTC date and both primary and comparison ranges must fall inside the latest 90 UTC calendar days. The server normalises the range to UTC even when a shared report form supplied the store timezone, and the resolved response reports UTC. This is fixed report semantics, not a selectable dimension.

Everything else — including the product-recommendation session funnel — buckets on the store-local stamped reporting date.

Currency

• One configured currency per store, and it is immutable. Every money figure in analytics is in that currency. There is no FX and no historical rate table; a report never converts.
• An order’s currency is frozen at order time and equals the store currency by construction.
• Money is integer minor units. Minor-unit digits are per currency: 0 for JPY, KRW and VND, 3 for KWD, BHD, OMR and TND, 2 for most others. The backend emits an amount plus its currency; the frontend does all formatting.
• Unlike currencies are never summed and relabelled. If a range somehow contains a transaction in another currency, or one whose order-time currency is unknown, the monetary report fails closed with an explicit error rather than producing a false total.
• Traffic counts are currency-independent and are stored once per day, on the store-currency row. Readers aggregate traffic across currency rows; a currency-scoped read of a traffic metric must not drop whole days.

Freshness and reconciliation

Per-source freshness

“A few minutes” is not a useful answer. These are the actual cadences.

Source	Cadence	Worst-case lag
Order, line, finance and fulfillment-timing facts	5 min	~10 min
Attribution	5 min	~10 min
Visit sweep (session close)	5 min	~10 min
Daily store rollup (3-day rolling window)	15 min	~30 min
Hourly store rollup (6-hour window)	10 min	~20 min
Abandoned-checkout stamping	10 min	~20 min
Cart abandonment and recovery	30 min	~1 h
Inventory and inventory movements	1 h	~2 h
Lifetime value, store credit, month-end inventory, product ABC	6 h	~12 h
Attribution reconciliation	12 h	~24 h
RFM, customer cohorts, cart retention	24 h	~48 h

Caution

The Data health surface does not cover everything. Its rollup thresholds — delayed after 2 hours, stale after 24 — apply to the daily rollup and the hourly correction scan only. Append-only fact sources are judged on a far looser scale (delayed after 7 days, stale after 30) because an idle store has no meaningful cadence. No snapshot family is covered at all, so a 20-hour-old RFM snapshot is normal and is never reported as delayed. Judge those families by the cadence table above, not by the health badge.

Freshness and durable ingestion

Storefront events enter a durable, idempotent outbox before background delivery. Every event has a stable identity, retrying delivery is expected, and consumers must produce one business effect. Visit resolution uses the same acceptance boundary: session-state mutation and resolve-intent append are atomic, and the storefront does not wait for the seller network call. During a Valkey outage no visit cookie or context is exposed rather than claiming tracking is available.

“Accepted” means the event intent is durably stored. It does not mean the event already appears in a report. Events for one browser/store identity are a strict FIFO: only that partition’s head is eligible for delivery, a retry keeps the same head, and acknowledgement promotes exactly one successor. Different identity partitions remain independently claimable, so one delayed visitor cannot hide or reorder another’s due events.

Every claimed payload is structurally validated before delivery. An invalid envelope is a poison record, not a business event: the same atomic claim copies its bytes, identity, partition, reason and quarantine time to durable quarantine, removes only that record, installs an idempotency tombstone, and promotes the next record in that FIFO. A lost response can cause a retried claim but cannot restore, duplicate or discard anything.

Quarantine records have no automatic expiry or retry. /health reports analyticsDispatch.quarantineDepth and oldestQuarantinedAgeMs, and any non-zero depth degrades analytics health until an operator preserves and investigates the evidence. A quarantined intent is absent from every report until it is corrected and replayed as a separately auditable event; quarantine itself never counts as a sale, session, conversion or adjustment.

Production uses either managed synchronous multi-AZ durability or a dedicated self-managed Redis with TLS, noeviction, AOF enabled and appendfsync always. appendfsync everysec is deliberately rejected: it can acknowledge a short write window before disk persistence and therefore does not satisfy the acceptance contract.

Late-arriving events mark their actual reporting day dirty, so an old refund or identity link is rebuilt even when it falls outside the rolling refresh window. A freshness state describes data delay; it never changes a metric definition.

Not supported, and why

Stating this here is better than letting a merchant discover an empty report. Each entry names the missing primitive.

Not reported	Why
Subscriptions	requires subscription contracts, recurring-order lineage, interval and activation/cancellation snapshots. Ordinary repeat orders are not subscriptions.
Order risk scoring	requires an order-risk provider with a levelled per-order assessment and a fraud-attributed cancellation decision. Neither is persisted, so every field would be a permanent zero. Chargebacks are a different primitive and are reported, from provider payment disputes.
Duties	the platform does not support duties. No order source persists an amount, the fact and rollup columns have been dropped, and no report family exposes a duties metric.
Sales by discount code	combined discounts retain only a combined reversal amount, not an immutable allocation back to each discount application. Proportional allocation would fabricate financial results.
Restocking / return fees	orders persist no restocking fee. The fact column, the rollup column and the metric were all removed rather than shipped as a permanent zero.
Shipping-discount split on the sales ladder	orders persist no merchandise/shipping discount split. Real shipping discounts are reported at their own grain by Shipping by order.
Shop channel, Shop Pay, Managed Markets, Markets, Autopilot, agentic commerce	each requires a Shopify-owned identity or classification. Sellerlane does not relabel online-store traffic, gateway names, shipping country or transaction currency as any of them.

Metric reference by family

Sales and orders

Source: the daily commerce rollup, at (store, day, channel, currency).

Metric	Formula	Tax	Clock
Gross sales	SUM(gross_sales_cents)	net of all tax	order day
Discounts	SUM(discount_cents), shown negative	net of all tax	order day
Returns	return-linked refund merchandise	net of all tax	refund-processed day
Refunds	refund amount paid back, positive	contains tax	refund-processed day
Sales reversals	total-sales reversal, shown negative	contains tax	processed day
Net sales	see the ladder	net of all tax	mixed
Shipping, Taxes, Tips, Additional fees, Adjustments	signed component nets	see the ladder	mixed
Total sales	the ladder identity	contains tax	mixed
Orders	orders with a reportable line item, non-test, non-deleted	not money	order day
Average order value	(Gross sales − Discounts) ÷ Orders	net of all tax	order day

On Sales, hourly granularity is available for gross sales, discounts, returns, refunds, net sales, total sales, orders and AOV only. The hourly rollup carries no shipping or tax columns.

Orders reads the same daily rollup as Sales — the same columns computed by the same writer, not a second opinion. It exposes a narrower money set (orders, AOV, refunds, returns and sales reversals) and adds sessions, converted sessions and conversion rate. Its hourly set is orders, AOV, refunds, returns and sessions; converted sessions and conversion rate have no hourly column.

Total sales by billing location groups the order’s own address. Billing and shipping are separate order-address dimensions and never session IP geography. Its Sales reversals is the merchandise reversal, unlike the Sales family’s. It also carries Average order quantity (ordered quantity ÷ orders, original demand only, never reduced by later reversals) and Reversed quantity rate (reversed ÷ ordered), which can exceed 100% when a range contains reversals for older orders.

Sales by company reads the order fact directly for B2B orders only. Its money is order-dated gross and is not reduced by later refunds; its returns and refunds columns are order-lifetime reference amounts. Use Finance or Returns & refunds for the refund-dated split. Company and location names are order-time snapshots.

Cancellations is dated by the day the order was cancelled, while Orders placed is dated by the order day, so Cancellation rate holds over any range. Canceled orders and Partially cancelled orders are disjoint: an order whose line cancellations belong to a same-day whole-order cancellation is counted once by the former, and the latter counts only orders touched by a cancellation that is not part of one. Cancellation rate stays the whole-order rate.

Tips counts tipped orders only. The rollup selects rows with a tip, so it cannot count untipped orders and has no denominator of its own.

Point of sale shares every financial formula, refund timing and currency rule with online. It differs only in dimensions — selling location, terminal, cashier, sales staff. A POS order never receives a synthetic online session to fill a traffic report, and a gift-card-only POS checkout belongs to gift-card liability reporting, not POS order count, merchandise sales or AOV.

Money and finance

Fees, payouts & reversals (the family labelled “Finance summary” in older copy) carries the same commerce columns as Sales. It is not a second rollup with matching predicates: both families read the same shared commerce table, so the money is identical because it is literally the same stored columns, not because two computations agree. Sales is the authoritative surface for Total sales. The two metrics only Finance has are Payment fees and Payouts; Additional fees and the total-sales reversal are on both families. Finance carries no Orders and no Average order value, and no COGS, gross profit, margin or cost coverage — those are on Profit.

Payments counts successful capture and refund rows on their transaction processed date.

Metric	Meaning
Attempts	payment attempt identities, dated to the attempt’s first qualifying intent/auth/capture event, so a lifecycle crossing midnight does not move or repeat
Transactions	captures + refunds
Gross payments	successful captured money
Refunds	successful refunded money, positive
Net payments	gross payments − refunds; legitimately negative in a quiet period with refunds for older orders

Payment-method and gateway breakdowns use the immutable attributes snapshotted on each transaction. Payments are not sales: authorizations, failures, voids, payouts, provider fees and disputes are separate measures.

Chargebacks & disputes reports live provider payment disputes only. Chargeback rate is disputes opened in the period ÷ successful live gateway captures processed in that period. Disputes are dated by the day the provider opened them, not by the disputed order’s date, so a short period can exceed 100%. Order risk scoring is not reported — see Not supported.

Caution

A chargeback lands on two different days in two different families, on purpose. This family dates a dispute on the day it was opened, because that is when the dispute became a fact you have to work. The sales-ladder reversal for a lost chargeback is dated on the day the dispute was resolved, because that is when the money actually left. A dispute opened on Monday and lost on Friday appears in Chargebacks on Monday and in Sales reversals on Friday. Do not reconcile the two day for day.

Taxes is order-dated and restricted to orders whose payment landed (paid, partially refunded, refunded) — tax charged on a pending order is not tax collected. This restriction is why Taxes on the Sales ladder and Tax collected here can differ on the same day.

Metric	Meaning
Tax collected	every tax line, embedded and additive, on collected orders
Taxable sales	the double-count-safe taxable base: one taxable amount per tax target at its lowest applied priority, not net sales
Refunded tax	item tax + shipping tax on refunds, on the refund’s processed date; the out-of-zone adjustment is deliberately excluded
Net tax	tax collected − refunded tax
Orders	the payment-restricted count, unlike Orders everywhere else

Geography follows the order’s own tax calculation basis: billing-first when tax was driven by the billing address, shipping-first otherwise, and a refund nets the same bucket it was collected in.

Tax by rate is a sibling, not a widening. It is gross-only — tax collected and orders, broken down by tax name and rate (CGST/SGST/IGST, VAT standard and reduced) under the same collected-orders filter, so it adds up to the jurisdiction total. Refunded tax and the taxable base live on Taxes.

Liabilities mixes flows and balances. Gift cards and store credit issued and redeemed are flows and sum across days. Outstanding balances and the loyalty points liability are point-in-time snapshots: the range reads the last day only. Loyalty points outstanding is a point count; its liability is that count valued at the program’s redeem rate.

COD & partial payments is order-cohort dated: cancellation and RTO rates divide within one order cohort, so they will not line up day-for-day with Sales or Cancellations. COD balance outstanding is a cumulative point-in-time balance stamped on every day row and read as last-in-range.

Profit and cost

Source: the daily profit rollup, at product/variant/order grain with POS dimensions.

Metric	Formula	Note
Cost of goods sold	SUM(unit cost snapshot × net sold quantity)	order-dated; the snapshot is immutable, so a later cost change never rewrites history
COGS restored	cost restored by refund and cancellation events	on the event’s processed date
Gross profit	Net sales (net of tax) − COGS	mixed clock
Net sales with cost recorded	net sales on lines carrying a unit-cost snapshot	the gross-margin denominator
Net sales missing cost	net sales on lines with no cost snapshot	—
Gross margin	Gross profit ÷ Net sales with cost recorded	not ÷ Net sales
Cost coverage	costed units ÷ all units, sold and refunded	a unit share. The money share is Net sales with cost recorded ÷ Net sales, and the two need not agree

Caution

Gross margin’s denominator is costed net sales, not net sales. This is subtle and load-bearing. Dividing by total net sales would silently dilute margin by every line that has no cost recorded, so a store that costs half its catalogue would read at roughly half its true margin and the number would drift with catalogue hygiene rather than with pricing. Read Cost coverage alongside Gross margin: the margin describes only the costed share of the business.

Orders on Profit counts distinct orders on sale rows only — a refund event retains its order for the Order dimension but must not create an order on the refund day. Total sales reversals here is the total-sales flavour, including a null-product order-grain row for any full, itemless or custom-refund residual; that residual completes the order total without inventing product-level merchandise, cost or profit.

Sales by vendor and Product ABC analysis read the same cost basis. Product ABC is a snapshot family over a 28-day lookback.

Operational contribution estimate

This figure is computed by the server for the Overview payload but is not rendered on any Analytics screen today, and it is not a report metric — no report, dashboard card or dashboard target can select it. It is documented here because the number exists and is referenced elsewhere. This is the formula the server actually computes:

gross profit + shipping + tips + additional fees + adjustments − outbound shipping cost − payment fees

• Gross profit is event-dated: refunded merchandise and its cost restoration land once on the processed date.
• Shipping, tips, additional fees and adjustments come from the signed finance stream, so their reversals stay on their processed dates.
• Outbound shipping cost is the snapshotted carrier cost on the original order and stays on the order date — returning merchandise does not undo a carrier cost already incurred.
• Return fees are not a term. Orders persist no restocking fee, so the column that once summed them was a literal zero and is gone.

It excludes customer sales tax, duties, overhead, payroll, marketing spend, financing, income taxes, reserves and chargebacks. It is a commerce contribution diagnostic, never accounting net profit.

Products, collections, search, and recommendations

Products, Variants and Collections share one engagement metric set: product or collection views, added to cart, card impressions, card clicks, orders, units sold, and Net sales — which is product-attributed net merchandise only. Shipping, tax, tips, fees and order-level refund residuals cannot be allocated to a product without inventing data, so they are absent by design.

Store search counts searches, result clicks, searches with and without clicks, zero-result searches, click-through rate, average results returned, added to cart, orders, and search-attributed total sales.

Recommendations exposes two distinct populations that must not be mixed:

• Placement diagnostics — impressions, clicks, click-through rate, added to cart, orders, original units ordered, and original-order attributed merchandise sales. These are event counts and order-time money.
• The session funnel — sessions with a recommendation impression; those with a later click; those where the same product is added to cart after the click; those where that product is purchased by an online order linked to the session after the cart event. The invariant is sessions ≥ clicks ≥ add-to-carts ≥ purchases. Sessions are assigned to the store-local day of the first eligible impression. A click after order creation cannot receive purchase credit.

Traffic, marketing, and behaviour

Traffic acquisition is operational acquisition reporting: sessions, visitors, orders and attributed total sales, by referrer source and host and UTM. Marketing attribution is a separate consent-qualified dataset backed by the touchpoint and credit ledgers; it never relabels Traffic rows as campaign attribution.

Visitor behavior carries sessions, visitors, page views, bounced sessions, bounce rate, the session-funnel stages, conversion rate, average session duration and average pages per session.

Location has three meanings

Always pick the location dimension that answers the business question.

Location	Source	Use it for
Session location	trusted edge/IP geolocation captured when the visit begins	approximate audience geography
Customer location	the customer’s most recent non-empty shipping location across their complete eligible order history	customer geography
Sales/POS location	the order’s POS selling location, assigned inventory location, or named fulfillment location	store and inventory performance

Session location never means the shipping address or the fulfilling store. Sales location never means where the shopper’s IP was.

At the edge, Cloudflare country, region, city, timezone, latitude and longitude are accepted only when the request arrived through the configured trusted proxy path; client-supplied copies are not trusted. Coordinates are validated and retained only as an approximate IP point for coarse map placement — their decimal precision is never treated as address accuracy, and named city/region detail, not coordinate precision, determines the reported accuracy label. Cloudflare’s XX and T1 country values become Unknown rather than a fabricated country. Detailed region/city fields are trusted only after the production transform is checked and the runtime trust flag enabled. The connecting IP is used only through keyed identity and rate-limiting hashes; analytics does not persist the raw address. Postal and metro codes, True-Client-IP and JA3/JA4 are not collected merely because they can be. Cloudflare’s visitor timezone never changes the store reporting timezone.

When tracking is allowed but trusted location is unavailable, the visit produces an Unknown geography row. It is never reassigned to the merchant’s own location.

Attribution

The canonical acquisition model is last non-direct click within the configured lookback window — 30 days by default, capped at 365.

• The window ends at order creation, so a delayed COD payment cannot admit a post-purchase visit.
• A visit can match through the order’s visit token, browser identity, signed-in customer, or an audited browser-to-customer identity link.
• Direct traffic receives credit only when there is no eligible non-direct touchpoint in the window.
• Marketing attribution respects marketing-consent eligibility. Operational order reporting does not disappear because marketing consent was not granted.
• Single-touch models allocate 100% once. Multi-touch credit basis points must sum to exactly 10,000 for an order.
• Attributed order counts are order-equivalent credit: whole numbers for single-touch models, fractional inside Linear breakdowns, and intentionally repeated in any-click participation rows.
• Attributed sales use the order’s snapshotted currency and sales basis. Later cancellation, edit, chargeback, refund and restoration events retain the original touchpoint and model allocation and change attributed total sales on the event’s processed date. They never rewrite the order-date value. Sold gift-card face value is excluded.
• Attribution average order value is order-time gross merchandise less discounts ÷ attributed orders. It excludes shipping, tax, tips, fees and later reversals. Attributed total sales per order is a different calculation and is never presented under the AOV name.

First click, last click, linear and any-click are separate lenses, not numbers to add. Marketing defaults to last non-direct click. Selecting the attribution-model dimension compares lenses row by row; cross-model totals, comparisons and time series are suppressed because they would multiply sessions. See Marketing attribution.

Customers

Customer lifecycle counts customers as order-event facts. A cancellation, restoration, return or refund never manufactures a customer on its processed date.

• A new customer is one whose qualifying order is their first eligible non-test order in that store; a returning customer has at least one earlier eligible order.
• Returning customer rate is distinct returning customers ÷ distinct customers who placed an eligible order in the period. A customer who places both a first and a later order in one displayed period appears in both rows, and the denominator still counts them once.
• Guest orders without a stable identity contribute orders and sales but not distinct-customer metrics. Internal POS walk-in holder records are excluded. Gift-card-only orders do not establish customer chronology; a mixed checkout does, using only its reportable non-gift-card merchandise.
• Lifecycle Total sales uses a mixed clock: original total sales on the order date, signed cancellations, restorations, chargebacks and refunds on their processed dates, each retaining the original order’s first-time or returning classification.
• Late identity linking can change classification. The resequencing worker recalculates order index deterministically so only the earliest eligible order remains the first order. Chronology and cohort membership use the store-local placement date; a COD order paid days later does not move cohorts or become the customer’s latest purchase.

In Live View, the visitor new/returning split is browser-based: new means the retained visitor token was first seen on the current store-local day. The customer mix is order-based and requires a customer identity on every classified row, so anonymous guest commerce stays in overall Orders and Total sales but contributes to neither customer bucket. Live windows are adjustable: visitors default to a rolling 5 minutes (adjustable 1–30 minutes) and customer behaviour to 10 minutes (adjustable 1–60).

RFM and actual lifetime value

RFM and lifetime value are point-in-time customer snapshots, not daily totals. Both require a stable customer identity, so a guest order stays in store sales but cannot be assigned to a customer. They differ in population: the lifetime-value snapshot writes a row only for customers who have purchased, while the RFM snapshot writes a row for every customer in the store and puts those with no eligible order in Prospects.

An order is eligible for either snapshot when it is non-test, non-deleted, in the store’s reporting currency, carries at least one reportable line item, and was placed on or before the snapshot date. B2B company orders are excluded from both, so a company buyer scored only through company orders reads as a Prospect.

• Recency is store-local calendar days since the most recent eligible order was placed. Payment, fulfillment, refund and cancellation dates do not move it.
• Frequency is the number of eligible orders placed. A later refund is a financial reversal; it does not pretend the order never happened.
• Monetary value is lifetime event-net total sales through the snapshot, floored at zero per customer. Sold gift-card face value and its refunds are excluded.

R, F and M are store-relative purchaser quintiles from 1 to 5, tie-broken deterministically so reruns are stable. Recency is scored so that the most recent buyers get 5. The combined score is FM = floor((F + M) ÷ 2), and the segment is the first matching rule in this order:

Segment	Rule	What it means
Prospects	no eligible order	a known customer who has never bought; also the fallback bucket
Dormant	R ≤ 2 and FM ≤ 2	bought little, long ago
At risk	R ≤ 2 and FM 3–4	solid history, has gone quiet
Previously loyal	R ≤ 2 and FM = 5	your best buyers, now absent
Almost lost	R = 3 and FM ≤ 2	low value, fading
Needs attention	R = 3 and FM = 3	mid on everything; the nudge segment
Loyal	R 3–4 and FM ≥ 4	frequent and valuable, recently active
Promising	R = 4 and FM = 1	bought recently, has not built history yet
Active	R ≥ 4 and FM 2–3	recent, moderate value
New	R = 5 and FM = 1	just bought for the first time
Champions	R = 5 and FM ≥ 4	most recent, most frequent, highest value

Rules are evaluated top to bottom and the first match wins. The bands overlap on purpose: a customer with R = 2, FM = 2 satisfies both Dormant and At risk, and is Dormant, because Dormant is tested first. Customers with no eligible order are never given a fabricated purchaser score.

Actual lifetime value uses the same signed lifetime total-sales basis and the same zero floor. It is historical customer spend — not contribution margin, not predicted value, not gateway cash, not accounting revenue. Average lifetime value is the sum of actual customer values ÷ distinct customers in the result. The lifetime-value report’s Average order value is a separate order-time merchandise calculation (gross less discounts, weighted by lifetime orders) and therefore does not divide lifetime value by orders or absorb later reversals. Predicted lifetime value and predicted-spend tier are separately labelled Sellerlane estimates that become available only after more than 100 eligible store orders.

Customer cohorts

A customer enters exactly one weekly, monthly or quarterly cohort by the store-local placement date of their first eligible merchandise order.

• Period -1 is the immutable acquisition cell: acquisition-order count and acquisition net merchandise sales, displayed as the 100% retention baseline, with customers returned zero by construction.
• Period 0 holds additional eligible orders in the same acquisition interval plus reversals processed in it. The first order is not counted again as a repeat.
• Later periods hold repeat orders placed in that period plus reversals processed in it.
• Cohort revenue means net merchandise sales: repeat-order sales at placement, line-attributed cancellations, edits and refunds as signed changes on their processed date, restorations positive. It excludes shipping, tax, tips, fees and order-grain refund residuals, so a period can be negative.
• Retention is distinct customers with a repeat order in one cohort-period cell ÷ the immutable size of that exact cohort. A financial reversal changes revenue only; it never counts a customer as returned.

Cohort date and period are required dimensions and one exact interval must be chosen. The server omits totals, comparisons and time series and rejects a result with either cell dimension removed, because cohort size repeats on every period row and one customer may return in several periods — summing those rows could report retention above 100%.

Cart and checkout

Carts counts carts created, cart views, items added and removed, cart updates, active, abandoned, recovered and checked-out carts, plus average cart value (weighted by carts created), abandoned cart value and recovered cart value.

Checkout funnel is described under The two funnels. It has no revenue metric: the column that once existed summed total sales over every order on the day, paid or not, and never joined the checkout cohort — a duplicate of Sales wearing a checkout label. Paid orders is the funnel’s only money-adjacent figure.

Checkout OTP verification counts OTPs sent, verified and skipped, with abandoned derived as sent − verified − skipped floored at zero.

Operations

Fulfillment counts fulfillment orders, fulfillments created, shipped and delivered, items and orders fulfilled, shipped and delivered, and four average duration metrics (order to fulfillment, order to ship, ship to delivery, order to delivery) computed as summed hours ÷ summed samples — never an average of daily averages.

Returns by product dates Units returned by the day the return was received and Units sold by the order day, carrying units sold on the unspecified-reason rows only, so Return rate is correct per product over any range and grouping by reason never fans the denominator — per-reason rate rows read as blank by design. Refunded amount is per-line refund allocations by processed day; order-level-only refunds carry no product attribution and stay on Returns & refunds.

Returns & refunds counts returns, items returned, refunds and refund amount by reason.

Post-purchase requests is sourced from the append-only request timeline; Requests counts distinct requests per group and Estimated refund amount sums each distinct request’s buyer-shown estimate once.

Inventory metrics

Inventory is location- and time-sensitive, and mixes flows with boundary snapshots.

• On hand, available, committed, reserved, incoming, not stocked, damaged, safety stock, quality control, unavailable are point-in-time states read from the last snapshot in the range.
• Starting inventory units is each inventory item/location’s first available snapshot in the period; an item introduced mid-period starts on its introduction day. Ending inventory units is its last.
• Inventory units sold is the gross flow of tracked units ordered. Refunds, cancellations, manual adjustments and transfer receipts do not reduce it. This is different from the sales-report Net quantity, which is ordered quantity less signed processed reversals.
• Percent of inventory sold is gross units sold ÷ starting inventory, undefined when starting inventory is zero. It can exceed 100% or be negative.
• Sell-through rate is gross units sold ÷ (gross units sold + max(ending inventory, 0)), undefined when that denominator is zero. Only the sell-through denominator treats a negative ending balance as zero; raw ending inventory stays negative for policies that permit selling past zero.
• Days of inventory remaining is ending available ÷ average daily gross units sold over the previous 28 days, recomputed from additive components at the requested grain.
• Inventory value and inventory retail value are last-snapshot money.

Ratios are recalculated from aggregate components at the requested grain and are never averages of daily rates. Inventory movement date and sales event date answer different questions: a return receiving can restock on a later date than the refund. Inventory movements, transfers, shipments and month-end inventory are separate families at their own grains.

Platform families

Loyalty program columns are whole loyalty points, not money; Redemption value is the cash value of consumed redemptions. Outstanding points liability lives on the Liabilities family as a snapshot, not here.

Referrals carries shares, visits, unique visits, signups, referral orders, fulfilled and rewarded orders, rewards issued and cancelled, gross and net referral revenue, pending and issued advocate rewards, three funnel rates, and suspicious referrals.

Theme components counts impressions, clicks and click-through rate per surface, component, section and block.

Privacy & ingest health counts analytics-allowed and marketing-allowed visits, consent events, events rejected by consent, browser events received and dropped, and ingest errors.

Web performance

The nine Core Web Vitals presets are three views — over time, by page type and by page path — for each of LCP, INP and CLS, from validated browser Real User Monitoring samples only. Bot, staff, preview, test, server and synthetic events are excluded, as is any sample whose value is not a plain number. This family’s dates are UTC and its range is limited to the latest 90 UTC calendar days; see The deliberate UTC boundaries.

P50, P75 and P95 are calculated from every individual retained experience in the selected range and grouping. Sellerlane does not average daily, device, page-type or page-path percentiles; percentiles are not composable that way.

The Web vital dimension carries five metrics, not three: FCP and TTFB are retained and banded alongside the three the presets chart. These are the bands:

Vital	Good	Needs improvement	Poor
LCP	≤ 2500 ms	> 2500 ms and ≤ 4000 ms	> 4000 ms
INP	≤ 200 ms	> 200 ms and ≤ 500 ms	> 500 ms
CLS	≤ 0.10	> 0.10 and < 0.25	≥ 0.25
FCP	≤ 1800 ms	> 1800 ms and ≤ 3000 ms	> 3000 ms
TTFB	≤ 1800 ms	> 1800 ms and ≤ 3000 ms	> 3000 ms

CLS is deliberately banded with a strict < 0.25 for needs-improvement and ≥ 0.25 for poor, rather than the generic inclusive bucket.

The page-path dimension strips the URL authority, query string and fragment, rejects protocol-relative and control-character values, caps the retained path and groups by hash, so tokens and customer data in URLs cannot enter merchant reports. A sample with no safe path still contributes to the over-time and page-type populations but not to a page-path row.

Exact-grain report sources

Some questions cannot be answered truthfully from a daily aggregate. These families execute against dedicated entity or event sources at their documented grain.

Family	Grain and contract
Visitors right now	a rolling point-in-time count of distinct visitor identities whose latest qualifying online-store visit was active in the window ending now. Multiple active visits for one identity count once.
Net payments by order	one row per successful tender event. Gateway, manual, cash and COD use payment-transaction rows; gift cards and store credit use their non-overlapping bearer-money ledgers. Dated when processed. Test orders and simulated gateway transactions excluded.
Net sales from gift cards	one row per original sold gift-card line. Date and sale ID stay the original sale while later cancellations, edits, restorations and refunds update net items and net sales on that row — so re-running the original period can show a later reversal. Redemption is excluded: it settles a liability.
Shipping by order	shipping money at order/event grain. Original lines keep gross charge and discount; cancellation, edit, restoration and refund amounts stay distinct signed reversals on their processed date. Shipping tax is excluded rather than mixed in.
Items bought together	one complete distinct current-product set per eligible order. A + B + C is not expanded into three pairs and duplicate quantities do not multiply the combination. Labels come from current product records, so deleting a product removes that entity. Because the metric is an order count, it spans every order and does not apply the reporting-currency filter.
Sales by customer name	groups durable customers by identity, so a profile rename does not split history. Current profile supplies the label; immutable order snapshots fill blanks and label guest orders. Original sales at order time, signed reversals at processed time.
Total sales by order	a signed order/reversal ledger. Original sales at order-created time; cancellation, edit, restoration and refund rows at processed time, retaining order identity and currency. Refund-line amounts and the order-level residual are disjoint, so a refund is never deducted twice.
Weekly sales patterns	the same signed events grouped by the event timestamp’s store-local day of week × hour of day. A two-dimensional heatmap, not a daily series renamed.
Offer and component sales	one immutable order-line-component event source behind the bundle and upsell reports. Offer kind splits fixed bundle, bundle rule and upsell rows. Original component merchandise and item tax on the order day; refunds, cancellations, restorations and edits keep the originating offer identity and land signed on their processed day. Order-time offer title, handle, configuration hash, component title, variant and SKU are separate dimensions, so catalogue edits never relabel history.
Post-purchase upsell decisions	eligibility-decision cohort dated. Its reversals are dated to the eligibility-decision day, so it will not line up day-for-day with Sales or Finance.
Customer details, one-time and returning customer lists	classify from complete eligible order history even when the range contains only the first order. Accepted-marketing comes from an immutable snapshot on the most recent eligible order; today’s subscription state is never substituted.

Caution

The marketing-consent snapshot on a customer list is historical reporting evidence, not send-time permission. A campaign must still enforce the contact’s current canonical subscription and suppression state.

For the customer lists, Total amount spent is the sum of each eligible order’s event-net Total sales, floored at zero per order — so it includes tax, discounts, shipping, applicable fees and processed reversals, without letting an excess goodwill refund create negative spend. Average amount spent per order divides that by eligible orders; it is not sales-report AOV.

Attributable offer/component sales on the bundle family is signed component net merchandise plus directly retained item tax. It excludes shipping, shipping tax, tips, order-only fees and residual adjustments because those amounts have no immutable component owner. Net offer component items is signed component quantity and is not presented as whole parent-bundle units when a buyer reverses only part of a bundle.

Online and POS

The channel dimension is part of every sale fact. Online and POS share the financial formulas, refund timing, currency rules, bundle allocation, loyalty and inventory invariants; only their operational dimensions differ. Online reports may use session, landing page, referrer, device and UTM data; POS reports may use selling location, terminal, cashier, sales staff and payment method. An online order fulfilled from a location remains online-channel sales unless the report explicitly groups by fulfillment or inventory location.

Commerce families default to Online + POS when no channel scope is supplied. Traffic, marketing attribution, behaviour, checkout, carts, search, recommendations, device, landing-page, session-location, conversion-location and web-vitals reports are online-store populations. An explicit channel scope always wins; the server never accepts a channel filter and then executes an incompatible hidden default.

Dashboard target semantics

A dashboard target is a persisted threshold over one enabled canonical report metric. It does not copy a card’s displayed text, execute a free-form query or create a second formula. Its current value comes from the same server-owned executor and metric registry as the corresponding report.

Each target snapshots everything needed to keep its meaning stable: report family, metric key, name and value type; threshold direction; typed unit and, for money, one ISO currency; inclusive store-local start and end dates; and the IANA timezone used to resolve them. Calendar presets resolve to their complete period at creation — today, Monday–Sunday week, calendar month, quarter or year — and do not roll forward. Changing the store timezone later does not move an existing target.

Unit	Stored value	Meaning
Money	signed-capable 64-bit column, constrained non-negative	integer minor units in the snapshotted reporting currency
Count	64-bit integer	whole count; never money or points-as-money
Rate	integer basis points	10,000 = 100%; no implicit cap, because some ratios exceed 100%
Number	numeric(30,6)	general non-monetary decimal, no currency

Exactly one typed value may be present. A money target fails closed when its currency differs from the current reporting currency; during hydration a current value in another currency is returned as unavailable with a warning rather than summed or relabelled.

Attainment is current ÷ target × 10,000 basis points, rounded half away from zero, so 10,000 means 100%. It is undefined for a zero target or an unavailable current value and is not capped. Achieved is a separate directional comparison: current ≥ target for at-least targets, current ≤ target for at-most targets — so for an at-most target, lower attainment is better. If the canonical metric is a ratio with a zero denominator, current value, attainment and achieved state all stay unavailable rather than treating the ratio as zero.

Metric identity, unit, currency, direction and resolved period are immutable; only the value in the already-selected typed column can be updated. Create, update and soft-delete events are recorded at the database boundary with actor and before/after snapshots.

Reconciliation status

Sellerlane distinguishes three levels of support:

1. Defined — the report has a documented semantic contract.
2. Executable — the server can run that contract against controlled fixtures and rejects unsupported fields.
3. Captured-reconciled — the same controlled commerce scenario has both a captured Shopify export and a captured production Sellerlane report export, with verified provenance, and passes the comparator within an explicit tolerance or approved expected-difference rule.

“Executable” does not mean “externally reconciled”. Reports that rely on proprietary third-party classifications or unavailable primitives stay clearly unavailable or approximate; they are never marked exact merely because the UI can render a chart. Sellerlane retains its own auditable crawler classification, so bot/human agreement with Shopify is an explicit reconciliation item, not an assumed identity.

Current Shopify report manifest

Advertised

187

Observed

184

Concrete

184

Unresolved

3

Enabled

157

Disabled

27

Captured-reconciled

0

Captured-reconciled reports: none. Controlled internal fixtures count as captured evidence: no.

Support-status counts

Status	Catalog entries
Executable Unreconciled	99
Needs Attribution Reconciliation	15
Partial Sales Components	11
Partial Gateway Scope	7
Requires Subscriptions	5
Needs Funnel Reconciliation	4
Partial Reversal Types	4
Requires Shop Channel	4
Missing Fields Or Preset	3
Unresolved Catalog Entry	3
Needs Close Reconciliation	2
Not Applicable No Label Purchase	2
Not Applicable Shopify Protect	2
Partial Acceptance Denominator	2
Partial Return Components	2
Partial Row Fields	2
Partial Shop Taxonomy	2
Requires Agentic Commerce	2
Requires Risk Provider	2
Requires Shop Pay	2
Not Applicable No Tip Capture	1
Partial Finance Components	1
Partial Low Engagement Threshold	1
Partial Semantics	1
Partial Sku Identity	1
Partial Taxonomy	1
Partial Tracking Presence	1
Proprietary Approximation	1
Requires Autopilot Marketing	1
Requires Historical Fx	1
Requires Managed Markets	1
Requires Markets	1

Disabled-reason counts

Reason	Reports
Requires Subscriptions	5
Requires Shop Channel	4
Missing Fields Or Preset	3
Not Applicable No Label Purchase	2
Not Applicable Shopify Protect	2
Requires Agentic Commerce	2
Requires Risk Provider	2
Requires Shop Pay	2
Not Applicable No Tip Capture	1
Requires Autopilot Marketing	1
Requires Historical Fx	1
Requires Managed Markets	1
Requires Markets	1

Disabled reports (27)

Report	Category	Status	Reason
sessions_by_social_source Sessions by social referrer	Acquisition	Missing Fields Or Preset	Unavailable for strict parity: analytics_visits.referrer_source only distinguishes 'direct' from 'referral', so no social-only population can be selected without fabricating it. All-referrer traffic must not be presented as social traffic.
shop_campaign_roas Shop Campaign ROAS	Behavior	Requires Shop Channel	This report requires Shopify Shop-channel impression, campaign, order, and attribution primitives. Market does not relabel online-store traffic or orders as Shop activity.
managed_markets_taxes Managed Markets taxes	Finances	Requires Managed Markets	This report requires Managed Markets tax, duty, filing, and fee primitives. Market's ordinary tax ledger must not be presented as Shopify Managed Markets activity.
shop_pay_payments Shop Pay payments	Finances	Requires Shop Pay	This report requires Shop Pay's immutable checkout/payment classification. A generic gateway or wallet label is not a defensible Shop Pay substitute.
shop_pay_transactions Shop Pay transactions	Finances	Requires Shop Pay	This report requires Shop Pay's immutable checkout/payment classification. A generic gateway or wallet label is not a defensible Shop Pay substitute.
shop_channel_orders Shop channel orders	Finances	Requires Shop Channel	This report requires Shopify Shop-channel impression, campaign, order, and attribution primitives. Market does not relabel online-store traffic or orders as Shop activity.
shop_payments_by_type Shop payments by type	Finances	Requires Shop Channel	This report requires Shopify Shop-channel impression, campaign, order, and attribution primitives. Market does not relabel online-store traffic or orders as Shop activity.
tips_by_staff_member Tips by staff member	Finances	Not Applicable No Tip Capture	Market has no tip capture path — no POS or checkout surface records a tip — so no tip amount or tipped-staff attribution exists to report.
canceled_due_to_fraud Canceled due to fraud	Fraud	Requires Risk Provider	This report requires an authoritative order-risk provider: a per-order risk assessment with a levelled score, and a fraud-attributed cancellation decision. Market persists neither, so every field would be a permanent zero. Chargebacks are a different primitive and remain available from provider payment disputes.
high_risk_orders_rate High risk orders rate	Fraud	Requires Risk Provider	This report requires an authoritative order-risk provider: a per-order risk assessment with a levelled score, and a fraud-attributed cancellation decision. Market persists neither, so every field would be a permanent zero. Chargebacks are a different primitive and remain available from provider payment disputes.
orders_covered_by_shopify_protect Orders covered by Shopify Protect	Fraud	Not Applicable Shopify Protect	Shopify Protect is a Shopify product primitive and is not represented as a Market metric.
orders_protected_by_shopify_protect Orders protected by Shopify Protect	Fraud	Not Applicable Shopify Protect	Shopify Protect is a Shopify product primitive and is not represented as a Market metric.
performance_by_autopilot_marketing_activities Performance by Autopilot Marketing Activities	Marketing	Requires Autopilot Marketing	This report requires Shopify Autopilot marketing-activity identity and spend/performance facts. Market has no equivalent source and does not infer it from campaigns with similar names.
shop_channel_product_impressions Shop channel product impressions	Marketing	Requires Shop Channel	This report requires Shopify Shop-channel impression, campaign, order, and attribution primitives. Market does not relabel online-store traffic or orders as Shop activity.
shipping_labels Shipping labels by order	Orders	Not Applicable No Label Purchase	Market has no shipping-label purchase flow, so no label cost is recorded anywhere. Carrier and tracking coverage for shipped orders is reported by "Orders with tracking included".
shipping_labels_over_time Shipping labels over time	Orders	Not Applicable No Label Purchase	Market has no shipping-label purchase flow, so no label cost is recorded anywhere. Carrier and tracking coverage for shipped orders is reported by "Orders with tracking included".
active_subscriptions_over_time Active subscriptions over time	Sales	Requires Subscriptions	This report requires a subscription contract, recurring-order lineage, interval, activation, cancellation, and one-time-versus-subscription sale snapshots. Ordinary repeat orders are not subscriptions.
agentic_total_sales_by_channel Agentic total sales by referring channel	Sales	Requires Agentic Commerce	This report requires an authoritative agentic-commerce referring channel and order classification. Market does not guess agentic sales from user agents, referrers, or free-form source labels.
agentic_total_sales_over_time Agentic total sales over time	Sales	Requires Agentic Commerce	This report requires an authoritative agentic-commerce referring channel and order classification. Market does not guess agentic sales from user agents, referrers, or free-form source labels.
average_profit_margin_by_market Average profit margin by market	Sales	Requires Markets	This report requires an immutable sale-time market identity and market-specific pricing/currency semantics. Shipping country or transaction currency is not substituted for a configured Market.
canceled_subscriptions_over_time Canceled subscriptions over time	Sales	Requires Subscriptions	This report requires a subscription contract, recurring-order lineage, interval, activation, cancellation, and one-time-versus-subscription sale snapshots. Ordinary repeat orders are not subscriptions.
new_subscriptions_over_time New subscriptions over time	Sales	Requires Subscriptions	This report requires a subscription contract, recurring-order lineage, interval, activation, cancellation, and one-time-versus-subscription sale snapshots. Ordinary repeat orders are not subscriptions.
sales_by_discount_codes Sales by discount codes	Sales	Missing Fields Or Preset	Unavailable for strict parity: combinable discounts can affect the same line, but current refund and order-adjustment facts retain only a combined discount reversal, not an immutable per-reversal/per-discount-application allocation. Market also lacks a canonical sale-time taxonomy that distinguishes percentage, fixed, free-shipping, buy-X-get-Y, and app discounts. Proportional allocation or taxonomy guessing would fabricate results.
subscription_vs_one_time_sales Subscription vs one-time sales	Sales	Requires Subscriptions	This report requires a subscription contract, recurring-order lineage, interval, activation, cancellation, and one-time-versus-subscription sale snapshots. Ordinary repeat orders are not subscriptions.
subscriptions_sales_over_time Subscriptions sales over time	Sales	Requires Subscriptions	This report requires a subscription contract, recurring-order lineage, interval, activation, cancellation, and one-time-versus-subscription sale snapshots. Ordinary repeat orders are not subscriptions.
total_sales_by_currency Total sales by currency	Sales	Requires Historical Fx	Shopify groups rows by checkout currency but converts Total sales to the store currency. Market can expose native-currency rows, but cannot reproduce Shopify's value without historical order-time FX rates.
sales_by_social_source Total sales by social referrer	Sales	Missing Fields Or Preset	Unavailable for strict parity: analytics_visits.referrer_source only distinguishes 'direct' from 'referral', so no social-only population can be selected without fabricating it. All-referrer traffic must not be presented as social traffic.

Unresolved advertised slots (3)

• #185: Shopify paginator advertised 187 reports, but the signed-in catalog rendered only 184; slug and name intentionally not fabricated.
• #186: Shopify paginator advertised 187 reports, but the signed-in catalog rendered only 184; slug and name intentionally not fabricated.
• #187: Shopify paginator advertised 187 reports, but the signed-in catalog rendered only 184; slug and name intentionally not fabricated.

Catalog captured 2026-07-13T16:45:00+05:30; generated summary schema v2.

The displayed counts are not maintained in this page. The server derives them from the manifest, writes marketing/src/data/shopify-analytics-parity-summary.json, and CI verifies the snapshot byte-for-byte with:

cd backend/seller
go run ./cmd/analytics-parity-summary \
  -check ../../marketing/src/data/shopify-analytics-parity-summary.json

To refresh the snapshot after an intentional manifest change, replace -check with -write. The generated capturedReconciled count includes only passing cases backed by both a captured Shopify output and a captured production Sellerlane output from the same scenario. Controlled Sellerlane fixtures prove internal financial contracts but never increase that count.

Troubleshooting a mismatch

Work down this list. The first five explain most disagreements.

1. Tax basis. Is the figure you are comparing against tax-inclusive? Every merchandise metric here is net of tax in both regimes.
2. Clock. Original sales use order creation; refunds use refund processing; cancellations and edits use adjustment processing; chargebacks use dispute resolution; traffic uses session and event occurrence.
3. Which reversal metric. Returns, Non-return refunds, Refunds and Sales reversals are four different grains — see Terms that look alike.
4. Funnel basis. Session-distinct stage or raw event count? See The two funnels.
5. Freshness. Check the watermark for the specific source, not the global health badge.

Then align: store and channel scope; date range and timezone; currency; test/deleted/bot/staff/preview exclusions; order, payment, fulfillment and refund status; the metric’s denominator; location type; attribution model and lookback window.

Finally, compare fact rows before rollups. A rollup can be rebuilt; an immutable financial or identity fact should be corrected only through its audited source event.

Related guides

Analytics and reports

Use dashboards, reports, cohorts, exports, and Live View in Analytics and reports.

Financial semantics

Read the monetary and ledger contract in Financial semantics.

Marketing attribution

Compare models and campaign credit in Marketing attribution.

Locations and inventory

Configure operational locations in Locations and inventory.