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 | 87) |
| 14:35 | Engineering deploys hotfix | $87/min | 87) |
| 14:42 | Checkout API recovers, 5xx rate <2% | $87/min | 87) |
| 14:53 | Datadog auto-closes incident | $87/min | **87) |
- 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,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 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,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.
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.
| 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 |
| 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. |