Skip to main content
Every metric on the Nerve Centre is computed over a defined time window. The choice of window is not cosmetic. The same Total Revenue figure looks dramatically different over today, the last 7 days, and the last 90 days; the comparison choice (just-the-window, or window-versus-prior) decides whether the merchant sees absolute size or directional change. This page documents the time-window vocabulary, when each window applies, how the “versus previous period” comparison works, and how time-zone settings interact.

​
The vocabulary

The Nerve Centre uses a compact vocabulary for time windows. Every card carries its default in the time_window field; the merchant can change it on the tile.
CodeMeaningTypical use
TToday, calendar-day in the workspace timezone, partial day.Operations cards: today’s order count, today’s spend pace.
24HThe trailing 24 hours, rolling, ends at the current minute.Operations cards that need stability across midnight (latency, error rate).
7DThe trailing 7 calendar days, ends at the start of today.Recency-sensitive marketing and ops metrics.
30DThe trailing 30 calendar days, ends at the start of today.The default look-back for most commerce and marketing metrics.
90DThe trailing 90 calendar days, ends at the start of today.Trend cards, stable baselines, monthly cohort views.
RTReal-time refresh on render. The window is “right now”; the value is recomputed on every page load.Live dashboards, in-flight monitoring, incident response.
vsPSuffix on a window meaning “versus the prior comparable window of the same length”.Directional comparison, change detection.
The vocabulary is intentionally short. Three to five characters per code means the card UI can render the window at small font next to the value without crowding the tile.

​
What each window means precisely

​
T, today

Today is the calendar-day window in the workspace timezone, starting at 00:00 and ending at “now” (the moment the card renders). Today is partial: at 09:00 the window covers nine hours; at 23:59 it covers the full day. Today is the right window for:
  • Operations cards where the merchant wants to see live progress against a daily target (today’s order count vs the trailing 30-day average for the same hour-of-day).
  • Pace-of-day metrics (“we are 14 percent ahead of where we usually are at 10am”).
  • Live spend or delivery monitoring where the action surface is the current day.
Today is the wrong window for:
  • Comparing periods, because the partial day is not comparable to a complete prior day.
  • Stable trend reading, because the value swings as the day progresses.
  • Anything where the merchant might draw conclusions from a quiet morning that is followed by a busy afternoon.

​
24H, last 24 hours rolling

Last 24 hours is the trailing 24-hour window, ending at the current minute. Unlike T, it does not respect the calendar day boundary. At 03:00, the 24H window covers the whole of yesterday afternoon and evening plus three hours of today; at 23:00, it covers most of today plus an hour of yesterday. 24H is the right window for:
  • Latency and error-rate metrics where the merchant needs continuity across midnight.
  • Real-time but smoothed signals (today is too jittery; 7D is too slow).
  • Incident timelines where the boundary of “today” is arbitrary.
The 24H window always has a complete 24 hours of data, so it is comparable apples-to-apples with the prior 24H window (with 24H vsP).

​
7D, last 7 days

7D is the seven calendar days preceding today, ending at the start of today. So at any moment during 12 May 26, the 7D window covers 5 May 26 through 11 May 26 (inclusive). Today is not included. 7D is the right window for:
  • Recency-sensitive marketing metrics (this week’s email performance).
  • Cards that need a complete recent history without today’s partial noise.
  • The denominator for a “this week” question.
7D vsP compares 5 May to 11 May against 28 Apr to 4 May.

​
30D, last 30 days

30D is the most common default in the catalogue. It is the trailing 30 calendar days, ending at the start of today. The 30D window is the merchant’s monthly close approximation; long enough to smooth weekly cycles, short enough to be recent. 30D is the right window for:
  • Most commerce hero cards (Total Revenue, Order Count, AOV, Refund Rate).
  • The denominator on rate metrics where smaller windows would be too noisy.
  • Period-over-period comparison; 30D vsP is the most common default.
30D vsP compares the last 30 days against the 30 days before that. At any moment during 12 May 26, the comparison is 12 Apr to 11 May against 13 Mar to 11 Apr.

​
90D, last 90 days

90D is the trailing 90 calendar days. It is the long-baseline window; long enough to absorb a single anomalous week, short enough to remain commercially relevant. 90D is the right window for:
  • Trend cards (revenue trend, AOV trend, refund rate trend).
  • The baseline against which anomaly detection is tuned (see alert system).
  • Quarterly business review preparation.
  • Cohort analysis with a meaningful sample size.
90D vsP compares the last 90 days against the 90 before that. The compare window length stays at 90, regardless of where the calendar quarter falls.

​
RT, real-time

RT means the card recomputes on every render. There is no fixed look-back; the value is “what is happening right now”. Common RT cards:
  • Live order count over the trailing five or ten minutes.
  • Active checkout sessions on the storefront.
  • Open incidents in Datadog or PagerDuty.
  • Active subscriber count on Klaviyo.
  • Live spend pace on Google Ads.
RT cards are the most expensive to compute (they hit the connector’s API on every render rather than reading from the cached snapshot), so they are reserved for cases where real-time matters. Dashboard rendering throttles RT refreshes to a minimum interval (typically 30 seconds) to protect the connector quota. For the data-freshness vocabulary that interacts with RT see data freshness.

​
vsP, versus previous period

The vsP suffix transforms a single-window value into a directional comparison. The window length is preserved on both sides of the comparison; the prior window ends where the current window begins.
WindowWhat it showsWhat vsP adds
7DThe trailing week’s valuePlus a delta vs the week before
30DThe trailing month’s valuePlus a delta vs the month before
90DThe trailing quarter’s valuePlus a delta vs the prior quarter
The card renders the current value, the prior value, the absolute delta, and the percentage delta. Sentiment colour is decided on the delta; threshold alerts (e.g. drop >15% vsP) fire on the delta. vsP is the comparison default for hero cards because the question “is the metric moving” is more decision-grade than “what is the metric’s current absolute value”.

​
Why some cards have multiple windows

Some cards in the catalogue render with two windows side by side because the question they answer requires both:
  • Total Revenue typically renders 30D vsP as the primary line and a 90D trend mini-chart underneath. The 30D vsP shows direction; the 90D shows absolute size and seasonal context.
  • Conversion Rate often shows 7D vsP for recency and 30D for the smoothed baseline.
  • Refund Rate uses 30D vsP for the alert and 90D for the trend baseline.
The card UI puts the primary window in the headline value and the secondary window in a small chart or annotation below. Both windows refresh on the same cadence; the primary drives sentiment and alerts.

​
Time-zone handling

Windows are anchored to the workspace timezone, set under Settings, Account, Workspace Settings at workspace creation time. The default is UTC; merchants almost always change it to their primary operating timezone (London, New York, Sydney) at first-connector time. Implications:
  • A 30D window for a London-timezone workspace ends at the start of today London time, not start of today UTC. A merchant in London opening the dashboard at 08:00 BST sees a 30D window that ended at 00:00 BST that morning.
  • Vendor APIs that report in their own timezone (Shopify reports in shop timezone, Stripe reports in account timezone, GA4 reports in property timezone) are normalised to workspace timezone at ingest. The reconciliation tables on each card’s documentation page note where vendor-side and Vortex IQ-side timestamps may diverge by a day at the boundary.
  • Multi-property GA4 or Google Ads workspaces (see multi-property and multi-account) inherit the workspace timezone, not the property timezone, for consistent dashboard reading.
A merchant changing the workspace timezone causes all windows to recompute. The recompute happens in the background; cards may briefly show “(recomputing)” until the new boundaries are populated.

​
When the window is configurable per merchant

Card defaults are recipe-driven. Some merchants want to tune them. The customisation surface:
  • Per-card window override. Open the card’s settings menu (top-right of the tile, three dots) and pick a different default window. The override is per-card per-profile.
  • Workspace default windows. Under Dashboard Settings, Defaults, the workspace admin can set the default window for each category (e.g. “all marketing cards default to 7D”, “all commerce cards default to 30D”). The recipe defaults remain available and individual cards can be overridden again.
  • Profile-bound windows. A finance profile can default to 90D for context; a marketing profile can default to 7D for recency. Profile-bound overrides do not interfere with the catalogue defaults, only the rendered windows.
Threshold alerts continue to use the recipe’s default window even when the visual window is overridden, unless the threshold is itself customised under alerts.

​
How time windows surface in the UI

  • Tile header. Top-right corner of each card carries the window code in small font (e.g. 30D vsP).
  • Tile footer. When the window has multiple comparisons, the footer carries “vs prior 30D” with the comparison value.
  • Tile chart. Line and bar chart strokes use the primary window for the data; the secondary window (where present) is a faded line.
  • Briefings. Daily morning briefings open with a 24H view; weekly with 7D vsP; monthly with 30D vsP; quarterly with 90D vsP.
  • Card documentation page. Every card’s docs page (e.g. Shopify Total Revenue) calls out the default window in the At a glance table.

​
How it relates to other modules

  • Vortex Mind uses the card’s window as the default analysis period when a diagnostic is triggered from that card. A 30D vsP alert produces a 30D-vs-prior diagnostic.
  • Ask Viq parses time windows from natural language (“revenue last week” -> 7D, “this quarter” -> 90D from quarter start, “yesterday vs the prior Tuesday” -> custom). Ask Viq always echoes the resolved window so the merchant can verify.
  • Actions carries the alert’s window into the Kanban card metadata. The Action’s “data as of” timestamp uses the window’s end boundary.
  • Vortex Memory uses a fixed daily snapshot for the longitudinal archive. Reading Vortex Memory back through Ask Viq lets the merchant compare arbitrary historical windows even when the live cards are scoped to the recipe defaults.

​
FAQ

What does T mean if I am asking about it at 8am? T at 08:00 covers 00:00 to 08:00 of today. The card renders today’s partial value. It is comparable to “today at 08:00 last week” if you specifically request that comparison; it is not comparable to a full prior day on its own. Is 30D thirty days or one calendar month? Thirty rolling days. A 30D window today (12 May 26) covers 12 Apr to 11 May. It is not the calendar month of April. For a calendar-month view the merchant can pick a custom window. What is the difference between 30D and 30D vsP? 30D shows the trailing 30 days as a single value. 30D vsP shows the trailing 30 days plus the prior 30 days plus the delta. The latter is what the alert thresholds (drop >15% vsP) evaluate against. Why is the alert window sometimes different from the visual window? The card’s threshold and alert logic uses the recipe’s intended window for stability (anomaly detection needs a consistent baseline length). The visual window can be overridden by the merchant for inspection. Decoupling the two prevents threshold drift when a merchant tunes the visual. Why is RT capped at a 30-second refresh? Every RT refresh is a connector API call. Without throttling, a merchant leaving the dashboard open in a tab for an hour would burn vendor quota at the rate of one call per second per RT card. The 30-second floor is configurable under Settings, Data Refresh. Can I add a custom window like 14 days or 60 days? Custom windows are supported through the card’s window picker (open the tile menu, pick “Custom range” and set start and end). Custom windows do not feed alert thresholds; they are inspection-only. How does the window interact with multi-currency cards? Currency is orthogonal to time. A 30D window on a multi-currency Shopify store sums the period’s totalPrice per currency without FX, then renders one row per currency code (or one consolidated FX-translated row, depending on the merchant’s currency display setting). See multi-currency. Why does my Shopify Total Revenue 30D number differ slightly from Shopify Admin’s Last 30 Days? Two reasons: timezone (Shopify reports in shop timezone; Vortex IQ in workspace timezone, which may differ by a few hours) and refund treatment (Shopify Net Sales deducts in-window refunds; Vortex IQ Total Revenue is gross). The card’s documentation page details every reconciliation source.