Analytics

Customer activity & engagement

Metric definitions & data sources
Cycle start & day of cycle
A "cycle" begins when a catalog month's first row is imported (min(catalog.created_at) for the current catalog_month) and runs until the next month's catalog is first imported. Day 1 = the import day; "Day N" in the page subtitle counts elapsed local days since then. Weekly reloads of the same month (new shipment invoices, corrected catalog rows) don't move day 1 — only a new catalog_month does. Source: catalog.created_at.
Customer Engagement Score
One number, 0–100, blending four components: customer retention (40%), habit score (25%), visits per week (20%) and actions per visit (15%). Retention and habit are already percentages; visits/week is normalized as min(visits ÷ 3, 1)×100 (3+ visits a week = full marks) and actions/visit as min(actions ÷ 3, 1)×100 (3+ distinct core actions per visit = full marks). The delta compares this cycle's blend to the same point in the prior cycle, on the same basis — reads "—" if the prior-cycle baseline isn't available. Source: usage_events, derived client-side.
Customer Retention
Of customers active in the prior cycle (from that cycle's start up to this cycle's start), the % with any activity so far this cycle — "Did last cycle's customers come back this cycle." The delta's baseline cohort is approximated one cycle further back (prevPrevStart* = prior cycle start minus the prior cycle's own length, since the real month-before-prior catalog rows are typically purged by then) and is phase-capped to the same number of elapsed days as the current cycle. Reads "—" when that approximation falls outside the 90-day usage_events window. Source: usage_events.
Habit Score
Of customers active in the last 30 days, the % who were also active in the last 7 days (WAU ÷ MAU) — how many monthly customers keep a weekly habit. The delta re-anchors both windows at the same day-of-cycle point in the prior cycle, instead of a fixed "30-60 days ago" window. Source: usage_events.
Visits per Week & Actions per Visit
A visit (session) is a burst of one customer's events with no gap > 30 minutes. Visits/week = sessions ÷ active customers ÷ weeks, over the days elapsed so far this cycle. Actions/visit = average distinct core actions (browse, reserve/cancel, my-list, subscriptions, arrivals) per session. The delta compares the same number of elapsed days in the prior cycle. Source: usage_events, session-clustered client-side.
New Customers
Non-admin, non-paper user_profiles created since this cycle began. The delta compares the same number of elapsed days in the prior cycle. Profiles are never purged, so both sides are exact — unlike the usage_events-based metrics above, this one isn't bounded by the 90-day window. Source: user_profiles.created_at.
This Cycle vs Last (overlay chart)
Distinct active customers per day of cycle, current cycle overlaid on the prior cycle at the same day offset. The prior line stops at that cycle's own length — a longer current cycle simply has no prior line past that point. The dashed marker plots the order deadline's day-of-cycle offset when it falls within the chart's range. Bursts (e.g. from a notify-customers email) don't necessarily land at the same day offset every cycle — that email can be suppressed on a given import, so the chart's job is a stable anchor, not a guaranteed aligned spike. Source: usage_events (day-of-cycle bucketed) + catalog.created_at (cycle anchors).
Reserved value
Gross value of reserve actions logged for a catalog month (price × reserves), non-admin. The month-over-month delta compares the current catalog month to the previous one on the same basis — unlike the other Executive metrics above, this one stays anchored to the calendar catalog month rather than the cycle, since it's already scoped to catalog_month. Per-customer averages in Subscription Opportunity come from live preorders for the current catalog month instead. Source: usage_events (price_usd on reserve events) + preorders × catalog.price_usd.
Publisher Demand
Share of reserve events by publisher over the last 90 days. The trend note compares each publisher's share in the most recent 45 days to the prior 45 days (a full 90-day-vs-prior-90 comparison isn't possible — usage_events are purged after 90 days). Source: usage_events (publisher on reserve events).
Cancel timing
For each cancel, the time since that customer's most recent prior reserve of the same title. Cancels within 24 hours read as second thoughts rather than lost sales. Source: usage_events (reserve → cancel deltas).
Customer Segments
Customers bucketed by visits/week: Power user 5+/wk, Regulars 2–4/wk, Occasional under 2/wk. The upgrade value compares average reserved value between the Regular and Occasional tiers. Source: usage_events + reserve-event value.
Weekly Cohorts
For each of the last four weeks, the % of that week's active customers with any activity in the following 30 days. Bar green deepens with the rate; * marks cohorts whose 30-day window is still open. Source: usage_events.
Win-back List & priorities
Active, non-admin accounts whose newest event is 30+ days old (or absent within the 90-day retention). Priority: High value = prior reserved value above the customer median; Paper = never logged in (invite-to-app candidates, not lapses); Medium = the rest. Source: user_profiles + usage_events.
Admin filter
Excludes events whose user belongs to an is_admin profile. Client-side set-filter, default ON. Admin self-actions ARE logged (only impersonated sessions are skipped). Note: toggling includes/excludes admin users; the amber banner warns when included.
Retention window
usage_events are purged after 90 days by the monthly import. There is no "all time" view — every metric here is bounded by that window, including cycle-anchored ones (a delta reads "—" once its baseline window falls outside the 90 days). The Executive and Operations tiles above compare equal-length cycle windows; the panels below (funnel, title bars, publisher demand, activity table, segments, cohorts, win-back) use fixed 30-day/90-day trailing windows instead.