Revenue at Risk (active incidents), Google Analytics 4

Metrics type: Cross-Platform Metrics • Category: Analytics

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:

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.
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).
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.
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).
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	When an incident spans GA4’s measurement layer (purchase tag failing), Property Health goes red simultaneously. The two cards corroborate.
GA4 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	The leading indicator: CR collapse during an incident is what’s driving the revenue loss.
GA4 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	Live purchase event rate. During an incident, this rate drops below baseline; the difference is what feeds this card’s calculation.
Datadog Open Incidents	The incident source. This card takes Datadog’s incident state and translates it to revenue.
New Relic Alerts	Same: alternative incident source.
Shopify / BC / Adobe 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`	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`	Same shape.	Same.
`adobe_commerce.total_revenue`	Same shape.	Same.
`stripe.stripe_total_revenue`	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`	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`	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 or book a demo to see this metric running on your own data.

Get Started

The AI OS

Revenue at Risk (active incidents), Google Analytics 4

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre

​At a glance

​Calculation

​Worked example

​Sibling cards merchants should reference together

​Reconciling against the vendor’s own dashboard

​Known limitations / merchant FAQs

​Tracked live in Vortex IQ Nerve Centre

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre