Sales Dashboard

What "Net Sales" means here: order subtotal after discounts and refunds, excluding VAT/sales tax and shipping (i.e., the revenue the business recognises, not what the customer paid). This matches Shopify's "Net sales" report metric. Shopify's "Total sales" (the bigger headline figure in Admin) is typically ~20 % higher for UK/EU because it includes VAT and shipping.

How "Reorder by" is computed: velocity = trailing-28-day units sold per day (replacements included since they consume stock). Days of cover = on hand ÷ velocity. Reorder by = today + (days_of_cover − lead_time − safety_buffer). Lead times default to 90 days; override per-SKU in lead_times.yaml. Discontinued SKUs (zero on-hand AND zero sales in the trailing 12 months) are filtered out automatically, so this list stays focused on commercially active products.

Blended ROAS = Shopify net sales ÷ Meta spend (per region). Higher than Meta Ads Manager's reported ROAS — they use Meta's own attribution; we use 100 % of Shopify revenue, which conflates organic / direct / email with paid. CFO-friendly headline; not a strict measure of paid efficiency. MER at the group level uses only regions that have ad spend (UK + EU); US revenue is excluded from the denominator since it has no Meta spend, otherwise it would inflate the ratio artificially.

Revenue split by GA4 default channel grouping. Answers "if I turned off ads tomorrow, what would I keep?" — the Direct + Organic Search bands roughly approximate that floor. Channel revenue is what GA4 sees (its tag must fire), so the per-month total typically lags Shopify net sales by 5–10 % — close-enough for mix-share signal.

Branded = queries containing "omura", "flowerstick", "x1e", or similar product/brand patterns. Non-branded = everything else — captures pure SEO acquisition for category terms. Branded trend is the long-term brand-awareness signal; sustained drops ≥30 % MoM are flagged in the pulse banner. Subdomain scoping is applied via a page-filter regex per region (the shared sc-domain:omura.com property covers all subdomains so each region's data only includes its own subdomain's pages).

A customer is classified as new on their first order seen in our data window; every subsequent order counts as returning. Customers whose actual first order pre-dates our 12-month cache will appear "new" on their first visible order — error skews higher at the start of the window and decays as history accumulates.

How to read this: median LTV is the typical customer's lifetime spend (mean is dragged by whales). LTV:CAC ratio ≥ 3:1 is the canonical healthy-DTC threshold; lower means each acquired customer barely covers their acquisition cost. Payback period is median months across the last 6 cohorts until cumulative cohort revenue ≥ CAC; under 12 months is healthy. The Subscription split (US / Recharge) flags any customer whose history contains at least one subscription-tagged order; their full lifetime spend then counts toward subscriber LTV — Recharge / Shopify use the same propagation rule. Tags / sourceName accrue going forward from 2026-03-11, so customers whose only subscription orders pre-date that window will under-classify as one-time. The lift multiplier is suppressed while the subscriber base is still young (median tenure 0d < 90d threshold) — comparing brand-new subscribers' lifetime spend against a 2-year-old one-time customer base would left-censor. The lift unlocks automatically once subscribers cross the threshold. Caveats: LTV uses Shopify net sales (gross proxy — contribution-margin LTV filed as omura-ksv once Shopify product cost is wired); cohorts whose true first order pre-dates our cache window will under-attribute (visible-first bias decays as history accrues past 12 months).

Each row is an acquisition cohort; each cell shows the average per-customer cumulative revenue at that lifetime-month. Reading top-to-bottom: are recent cohorts retaining as well as older ones? Reading left-to-right within a row: how fast does revenue accrue past the first order? Cells past today are blank — the cohort hasn't lived that long yet. Same caveats as the Unit Economics card above.

How priorities work: P2 is the next batch in the build queue. P3 is committed but lower-urgency. v1.2 items are deliberate deferrals — the design considered them and chose the simpler v1 alternative; revisit once enough history has accrued or once the simpler view surfaces a question that only the deferred view can answer.