New Relic state x commerce-sibling baseline = $/hour at risk while the incident is open. The single most-valuable card in this manifest.
At a glance
The single dollar number that translates technical incident state into a number the COO can read. Multiplies the merchant’s current hourly revenue baseline (from connected commerce sibling, Shopify / BigCommerce / Adobe) by an impact factor derived from live New Relic operational state (Apdex degradation, error rate, active P1s).
Calculation
Calculated automatically from your New Relic 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 Shopify Plus merchant with NR APM on the storefront. Baseline revenue at this hour-of-day is £18,400/hour (averaged over the last 28 days, same Tuesday 11:00, 12:00 hour). Live state at 11:14 on 02 May 26:
Impact factor calculation:
apdex_drop = 0.91 - 0.72 = 0.19. Multiplier:0.5 x 0.19 = 0.095(Apdex contribution).error_rate_excess = 4.6% - 1.0% = 3.6%(clamped to a 0, 1 normalised scale: 3.6/10 = 0.36). Multiplier:0.3 x 0.36 = 0.108(error-rate contribution).p1_count_factor = 1 / 5 = 0.2. Multiplier:0.2 x 0.2 = 0.04(P1 contribution).impact_factor = 0.095 + 0.108 + 0.04 = 0.243, ~24% of revenue at risk.
current_apdex >= baseline_apdex - 0.05 AND current_error_rate < 1.0% AND active_P1_count = 0.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in New Relic: New Relic does not surface a revenue-at-risk number, this is a Vortex IQ composite that joins NR operational state with commerce-sibling baseline. The closest equivalent screens for the operational-state inputs:- APM > Service > Summary for Apdex and error rate.
- Alerts & AI > Issues & Activity for P1 count.
- Dashboards > “Service overview” pre-built.
Cross-connector reconciliation:
The same composite shape is implemented on Datadog (
dd_revenue_at_risk) using DD’s APM, Monitors, and Synthetics inputs. With both connectors wired, the two risk numbers should agree within ~10% (the gap reflects probe-coverage differences and slightly different impact-factor weights). A 25%+ persistent gap indicates one platform is missing service coverage; audit which services each is instrumenting.
The card is reconciled forward (against actual revenue loss) every 30 minutes after an incident closes: Vortex IQ Mind pulls the actual sales/min trace during the incident window and compares it to the baseline-projected revenue. If the actual loss tracks within 25% of the predicted loss, the model is calibrated; if it drifts persistently, the impact-factor weights are tuned. This back-test runs continuously.
Known limitations / merchant FAQs
NR vs Datadog: should the two revenue-at-risk numbers match? Within ~10%, yes. Both use the same baseline revenue source (the commerce sibling) and the same composite shape, but feed slightly different operational-state inputs (NR APM vs DD APM probes). A 10, 25% gap during an incident is normal and reflects each platform’s coverage. A 25%+ persistent gap means one platform is missing instrumentation on a service that’s contributing to the impact factor. Apdex math: how does Apdex translate to revenue? The card usesapdex_drop = baseline_apdex - current_apdex as a 0, 1 multiplier with 50% weight in the impact factor. So a 0.20 Apdex drop (e.g., 0.91 to 0.71) contributes 0.5 x 0.20 = 0.10 to the impact factor, or 10% of baseline revenue at risk. The 50% weight reflects that Apdex is the strongest single predictor of conversion drop; SOASTA / Akamai 2017 data shows roughly 7% conversion-rate drop per 100ms of additional p95 latency, and Apdex is a satisfaction-weighted view of latency.
NRQL retention: is this card affected by retention?
The live card reads 5-minute windows, well inside any retention window. The 28-day baseline is computed from rolled hourly aggregates and is not affected by raw-event retention. So the card works on standard NR plans (8-day raw retention) as well as on Data Plus (13-month).
NR and Datadog disagree by 30%, who’s right?
Probably both, on different scopes. The two most common causes: (a) coverage difference, NR has the checkout service instrumented, DD has only the storefront, so NR sees more of the incident; (b) sampling difference, one platform’s high-cardinality sampling is dropping events the other keeps. Audit instrumentation parity if a single-number reading across both matters.
Sampling: does sampling break the calculation?
No. Apdex and error-rate inputs are sample-corrected on high-cardinality accounts. P1 count is unsampled. Baseline revenue is unsampled (commerce platform Order data, not event-stream data). The whole composite stays accurate even on heavily-sampled NR accounts.
Multi-account: my US and EU revenue baselines are different, can the card handle both?
Yes. Connect each commerce sibling separately and pair each with the corresponding NR account integration. The Nerve Centre stack panel renders one risk number per regional pair. Combining into a single global number is also supported (sum of regional risk numbers), but most CFOs prefer the regional split for incident triage.
Ingest cost vs visibility tradeoff: can I reduce NR ingest without breaking this card?
Yes. Drop sample rate on non-checkout transactions to 25%, keep checkout at 100%, keep all error events at 100%. The Apdex / error-rate inputs stay sample-corrected, the P1 count is unsampled, baseline revenue is unaffected. The card stays accurate and ingest cost typically drops 40, 60%.
**Alert tuning: my 100/hour” if you want to ignore residual customer-experience drag; (b) add a duration clause (“must be above 0 risk for 5 minutes then back to $50/hour” is rarely worth a notification.
The number jumps to £20k/hour for 30 seconds then back to £0, was that real?
Almost certainly an Applied Intelligence grouping artifact: when an issue family briefly contains 5+ incidents (before AI groups them into one) the P1 count factor can spike. AI typically resolves the grouping within 60, 90s and the number normalises. If the spike persists past 2 minutes it’s a real escalation worth reading. Tune by adding a “must stay above £X for Y minutes” clause to the alert.