> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Revenue at Risk (active incidents), Google Analytics 4 > Live $/min loss. GA4 traffic + commerce revenue × incident minutes. The number that pages execs. How to read it, why it matters, and how to act on it. **Metrics type:** [Cross-Platform Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Analytics](/nerve-centre/connectors#connectors-by-type) > Live \$/min loss. GA4 traffic + commerce revenue × incident minutes. The number that pages execs. ## At a glance > Live revenue-at-risk in \$/min (or equivalent currency) for any open incident from monitoring connectors (Datadog, New Relic, Sentry, statuspage). Computes: typical-revenue-per-minute-for-this-time-of-week × duration-of-open-incident, displayed as a running counter. **The number that pages execs**, finance and ops want a real currency figure attached to a Sev-1, not "the site is slow". | | | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | For each open incident: `(GA4 30D-rolling revenue-per-minute baseline for the same DOW/hour-of-day) × (minutes since incident opened)`. Sums across all open incidents. The "what would normally be earned in this window" estimate. | | **Sample basis** | The baseline uses GA4 `runReport` for the past 30 days at the dimension `dateHourMinute` to build a 168-bucket (7 days × 24 hours) typical revenue profile, smoothed. The current incident comes from connected monitoring platforms (Datadog incidents API, New Relic alerts API, Sentry issues API, statuspage incidents). | | **Sampling threshold** | None for the GA4 baseline at 30D × hour-of-week. The dimension count is bounded (168 buckets) and never triggers GA4 sampling. | | **Bot traffic filter** | GA4: built-in IAB Tech Lab filter applied. The baseline uses real revenue events, so bot exclusion is automatic. | | **Time zone** | The GA4 property's timezone, NOT UTC. The DOW/hour-of-day baseline is anchored to property zone so an incident at "Tuesday 2pm" uses the right baseline regardless of where the operator is. | | **Currency** | The GA4 property's reporting currency, FX-converted at event time. The card displays in that single currency for consistency. | | **Refunds** | Excluded from the baseline. We use gross GA4 `totalRevenue`. | | **Tracking-gap framing** | The baseline carries the structural GA4 tracking gap (10, 25%). **The displayed revenue-at-risk is therefore conservative**, the true business impact is 10, 25% higher than displayed. We err on the conservative side intentionally; over-stating risk would create alert fatigue. | | **What counts as an incident** | Any open Sev-1, Sev-2, or "page" status incident from connected monitoring platforms. P3/P4 tickets, info-level alerts, and feature-flag rollouts don't count. The card is for fire-alarm events. | | **Time window** | `RT` (real-time, refreshed every 60 seconds during open incidents). | | **Alert trigger** | `>$0 (any open incident)`, the card itself is the alert. Open incidents auto-page the on-call rotation per `sentiment_key: ga_revenue_trend`. | | **Roles** | owner, finance, operations, engineering | ## Calculation Calculated automatically from your Google Analytics 4 data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example A US apparel brand on Shopify, Datadog connected for monitoring. On 28 Apr 26 at 14:18 ET (a Tuesday), a Datadog Sev-1 fires: "Checkout API 5xx error rate >50%". The incident is acknowledged at 14:24 and resolved at 14:53. Property timezone US/Eastern. | Time (ET) | Event | Revenue baseline (this DOW/hour) | Cumulative revenue at risk | | --------- | ------------------------------------ | -------------------------------- | --------------------------------- | | 14:18 | Datadog Sev-1 opens, card lights red | \$87/min (Tuesday 2pm baseline) | \$0 | | 14:24 | On-call acknowledges (no fix yet) | \$87/min | $522 (6 min × $87) | | 14:35 | Engineering deploys hotfix | \$87/min | $1,479 (17 min × $87) | | 14:42 | Checkout API recovers, 5xx rate \<2% | \$87/min | $2,088 (24 min × $87) | | 14:53 | Datadog auto-closes incident | \$87/min | \*\*$3,045 final** (35 min × $87) | Three numbered observations: 1. **The card produces a number execs can act on.** Without it, the morning's incident review reads "Checkout API was failing for 35 minutes". With it: "Checkout API failure cost \~$3,045 of GA4-measured revenue, ~$3,500, \$3,800 of true commerce revenue once the tracking gap is added back." Finance, COO, and the head of engineering all care about that number; "35 minutes of 5xx" is just an engineering brief. 2. **The baseline is DOW/hour-aware.** A Tuesday-2pm incident has a $87/min baseline; the same incident on Sunday-3am would have a baseline of $4/min. The card uses the right reference for "what would normally be happening right now". This makes peak-hour outages look catastrophic (correct), and 3am outages look minor (also correct, you have time to fix without losing significant revenue). 3. **The displayed number is conservative.** The $3,045 is the GA4-measured figure; given the brand's typical 15% tracking gap, the true revenue impact is ~$3,500, \$3,800. We display the GA4-measured number to avoid over-stating risk during incidents (alert fatigue is real); the post-incident report reconciles against Shopify revenue for the canonical loss calculation. 4. **Multiple concurrent incidents stack.** If the checkout outage is happening *while* a separate "Search down" Sev-2 is open, the card sums both: total revenue at risk = sum-of-(duration × baseline-impact-multiplier) per incident. Each incident has a configurable impact multiplier (a checkout outage might be 100% of baseline; a search-down might be 30% because some users find products via category navigation). 5. **What WOULD trip false positives?** Two known false-positive scenarios: (a) a routine deploy that briefly trips a "synthetic check failed" Datadog monitor before stabilising; we filter sub-2-minute incidents to suppress these. (b) a marketing campaign that briefly inflates baseline (Black Friday Tuesday is not the same as a non-BF Tuesday); the engine detects multi-σ baseline outliers and asks for human confirmation rather than auto-closing. **Rule of thumb.** \$0 = green, no open incidents. Any non-zero figure means a real production incident is *currently* eating revenue; this is the highest-priority card on the dashboard at that moment. ## Sibling cards merchants should reference together | Card | Why pair it with Revenue at Risk | | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | [GA4 Property Health](/nerve-centre/kpi-cards/google-analytics/ga4-property-health) | When an incident spans GA4's measurement layer (purchase tag failing), Property Health goes red simultaneously. The two cards corroborate. | | [GA4 Revenue Trend](/nerve-centre/kpi-cards/google-analytics/revenue-trend) | The post-incident reconciliation. After resolution, the Revenue Trend dip should match the Revenue at Risk total (within the tracking gap). | | [GA4 Conversion Rate](/nerve-centre/kpi-cards/google-analytics/ecommerce-conversion-rate) | The leading indicator: CR collapse during an incident is what's driving the revenue loss. | | [GA4 Real-Time Active Users](/nerve-centre/kpi-cards/google-analytics/real-time-active-users) | The canary that pre-warns: if active users drop to 0 (or near-0), the site is fully down; expect this card to spike. | | [GA4 Real-Time Purchases](/nerve-centre/kpi-cards/google-analytics/real-time-purchases) | Live purchase event rate. During an incident, this rate drops below baseline; the difference is what feeds this card's calculation. | | [Datadog Open Incidents](/nerve-centre/datadog/datadog_incidents) | The incident source. This card takes Datadog's incident state and translates it to revenue. | | [New Relic Alerts](/nerve-centre/newrelic/newrelic_alerts) | Same: alternative incident source. | | [Shopify / BC / Adobe Total Revenue](/nerve-centre/kpi-cards/shopify/total-revenue) | The post-incident truth side. Use this for the canonical loss calculation; the GA4 figure is conservative. | ## Reconciling against the vendor's own dashboard **Where to look in GA4 (this card is a Vortex IQ-only metric):** GA4 doesn't have an "incident-aware revenue at risk" view. The closest GA4-native rebuild requires manual triangulation: > **Realtime → Revenue** for live revenue rate during an incident, eyeball-compare to a typical hour. > > **Reports → Engagement → Events → purchase** filtered to the last 1h to estimate the live drop. > > **Realtime → Active users** to confirm traffic is reaching the site (rules out DNS/CDN-level outages). Other GA4 views that *look* relevant but aren't: * **Reports → Acquisition (any view)**: doesn't surface real-time incident state; lagged 24h+. * **Explorations**: can be built to do something similar but require manual setup per incident. * **GA4 alerts (custom)**: the GA4 UI supports threshold alerts on metrics, but they don't compose with monitoring-platform incidents. **Why our number may legitimately differ from a manual reconciliation (rare):** | Reason | Direction of divergence | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | | **Baseline drift**. The 30D baseline doesn't capture seasonal effects perfectly. A peak-season incident may understate revenue at risk; a tail-season incident may overstate. | ±5, 15% on baseline | | **Late-arriving event ingestion**. GA4 has up to 4-hour delay; during the incident window, some baseline events may not have ingested yet. We refresh every 60s but the underlying data is itself slightly stale. | \<2% drift on real-time number | | **Incident-window edge effects**. When an incident opens and closes within seconds (flapping monitor), the card may briefly count a few seconds of risk that wasn't real. The 2-minute minimum filter mitigates this. | Sub-\$10 noise per false-positive | | **DOW/hour baseline cold-start**. Properties under 30 days old don't have a full 168-bucket baseline; we use a flatter aggregate and flag the result as low-confidence. | First 30 days only | **Cross-connector reconciliation, the IMPORTANT one:** This card is fundamentally cross-connector: it joins GA4 baseline + monitoring-platform incident state + commerce-platform truth. Expected relationships: | Card | Relationship | What divergences mean | | -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [`shopify.total_revenue`](/nerve-centre/kpi-cards/shopify/total-revenue) | Post-incident: Shopify's revenue dip in the incident window should be \~10, 25% larger than this card's GA4-measured number (the tracking gap). | If Shopify shows no dip during a card-flagged incident, the incident may have affected only a subset of orders (e.g. checkout was fine for non-3DS payment flows but broken for 3DS); the card's flat baseline can over-state. | | [`bigcommerce.total_revenue`](/nerve-centre/kpi-cards/bigcommerce/total-revenue) | Same shape. | Same. | | [`adobe_commerce.total_revenue`](/nerve-centre/kpi-cards/adobe-commerce/total-revenue) | Same shape. | Same. | | [`stripe.stripe_total_revenue`](/nerve-centre/kpi-cards/stripe/total-charge-volume) | If the incident is payment-side specifically (e.g. Stripe webhook lag), Stripe sees the impact; commerce platform may not until reconciliation. | Use Stripe for payment-incident-specific impact. | | [`datadog.datadog_incidents`](/nerve-centre/datadog/datadog_incidents) | The incident source. Card lights when Datadog has open incidents; goes dark when Datadog closes them. | If card stays lit after Datadog closes, the engine may have stale state, force-refresh. | | [`newrelic.newrelic_alerts`](/nerve-centre/newrelic/newrelic_alerts) | Same: alternative incident source. | Same. | **Use the GA4 figure during the incident; reconcile against commerce-platform revenue post-incident.** During: the GA4 number is the only real-time signal you have. After: the commerce-platform's actual revenue dip is the canonical loss. ## Known limitations / merchant FAQs **The card shows a number but my Datadog dashboard shows everything healthy. What's wrong?** Either (1) the card has stale incident state from before Datadog auto-closed (force-refresh; should clear within 60s), or (2) a different monitoring connector (New Relic, Sentry, statuspage) has an open incident that Datadog isn't aware of. Check the incident-source row in the card's drill-down. The card aggregates across all connected monitoring platforms; closing one source's incident doesn't automatically clear another. **Why is the number lower than my actual revenue loss after the incident?** The card uses the GA4 baseline, which is structurally 10, 25% lower than commerce-platform revenue (the tracking gap). The displayed number is intentionally conservative. After the incident, reconcile the *true* revenue impact against your commerce platform: Shopify Total Revenue dip vs typical = canonical loss. Then update your incident retrospective with the higher number. **The baseline shows $87/min for Tuesday 2pm but our Tuesday 2pm last week was $145/min. Why is the card understating?** The baseline is a 30D average smoothed across all Tuesdays in the window. Last Tuesday could have been a peak day (sale, viral moment, marketing push) that's mathematically averaged with three quieter Tuesdays. The card uses the smoothed median to avoid alert-shock during routine quiet hours. **Configure a custom baseline override** for known peak windows (BFCM, planned campaigns) via the card's settings. **An incident has been open for 2 hours but the card shows \$0. What happened?** Three known cases: (1) the incident's severity is below the card's threshold (P3/P4 don't count), (2) the incident is informational/non-customer-impacting (e.g. internal monitoring on a non-public service), (3) the affected service has zero baseline (e.g. a B2B portal during retail hours). Check the incident's severity classification and impact-multiplier setting. \*\*The card paged me at 3am for an incident that has $4 in revenue at risk. Why?** Because the alert trigger is `>$0\`, ANY open Sev-1/Sev-2 pages, regardless of revenue impact at the moment. We page on incident-existence, not on revenue threshold, the alternative would mean a 3am incident that's only $4/min now becomes a 9am incident that's $400/min by the time anyone notices. **Page now, fix now, even if the revenue number looks small.** **My multi-currency store, what currency does the card display?** The GA4 property's reporting currency. Multi-currency stores see one normalised number (FX-converted at event time during baseline computation). For a more granular view by currency, contact support; we have a multi-currency variant in the roadmap. **Does the card include Sev-3 / P3 incidents?** No. Only Sev-1 and Sev-2 (or "page" status) incidents trigger the calculation. P3/P4 are tracked by Datadog/New Relic for engineering hygiene but don't represent customer-facing revenue impact warranting executive attention. The card is a fire alarm, not an issue tracker. **Can I customise the impact multiplier per service?** Yes. The card settings include per-service impact multipliers: a checkout outage might be 100% of baseline (every order fails), a search-down might be 30% (some users still navigate via category), a CMS-down might be 50% (cached pages still serve). Configure these once; the card uses them for all future incidents on that service. **The card's number keeps changing during an open incident, why isn't it stable?** The number grows linearly: every minute the incident stays open, the card adds another minute × baseline = the running counter. That's the design, the number IS the cumulative loss to date, not the per-minute rate. The per-minute baseline is shown separately in the drill-down. If the card's number ever shrinks, that's a bug; the running counter is monotone-increasing while an incident is open. **Does the card account for delayed-impact orders (customer abandoned during outage but came back later)?** No. The card measures *real-time* lost revenue, not eventual recovery. Many customers who abandon during an outage do return later in the day (5, 30% recovery rate is typical). The card's number is the gross loss; the *net* loss after recovery is smaller. Reconcile against commerce-platform revenue post-incident to estimate the recovery rate, this is captured in the post-incident retrospective view, not in the live card. *** ### Tracked live in Vortex IQ Nerve Centre *Revenue at Risk (active incidents)* is one of hundreds of KPI pulses Vortex IQ tracks across Google Analytics 4 and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.