At a glance
Per-incident bar chart showing the conversion-rate drop observed during each NR P1/P2 incident over the rolling 90 days. Each bar is one incident; the height is the percentage-point drop in conversion rate during the incident window vs the baseline for the same time-of-day. Answers “do my incidents actually move customer conversion, or are they internal-only?”
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 store reviewed at 90-day quarter-end on 02 May 26. The chart shows 14 closed P1/P2 incidents over the period:
Pattern reading. Three of fourteen incidents (~21%) drove >2pp drops, the catastrophic ones. Eight of fourteen (~57%) drove <0.5pp drops, statistically barely visible to customers. The remaining three were in the 0.5, 1.5pp band.
Three takeaways for the post-incident review:
- Severity-to-impact mapping is bimodal. CRITICAL incidents on
checkout-api(the three big drops) consistently cost 2pp+ of conversion; CRITICAL incidents on background services (search, recommendations, account management) barely moved conversion. Severity is a coarse signal; which service is broken matters more. - Duration matters but not linearly. The 47-minute checkout incident cost 2.3pp; the 22-minute checkout incident cost 2.1pp. Once a customer hits a broken checkout page they generally walk away within the first 2 minutes, so additional incident duration is mostly affecting new customers arriving rather than further punishing existing ones.
- HIGH incidents on non-checkout services are noise. Of the seven HIGH incidents, six were on infrastructure (memory pressure, log volume, CDN cache hit ratio) and showed <0.3pp impact. The team can deprioritise post-incident reviews on these.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in New Relic: NR doesn’t render this per-incident conversion-impact view natively. The closest equivalent screens for the input signals:- Alerts & AI > Issues & Activity for the historical incident list.
- Dashboards > custom dashboards (if conversion data is piped into NR via Custom Events).
Cross-connector reconciliation:
NR Alerts and Datadog Monitors are independent alerting systems; both track the same conversion-rate input (same commerce sibling or GA4 connector). For incidents that fired on both platforms with peer alerts, the per-incident drop should match exactly. Discrepancies trace to incident-coverage differences: an NR incident with no DD peer is on the NR chart but not the DD chart, and vice versa. The chart count is therefore platform-specific; the drop-pp values per matched incident should agree.
NR APM-detected incidents vs GA4-observed conversion drops: NR catches the cause (server-side error or latency); GA4 measures the effect (customer-side conversion drop). The two views are complementary. When this card shows a 2pp drop attributable to an NR incident but GA4’s overall conversion rate barely moved during that window, traffic-weighting matters: the incident affected a small slice of traffic disproportionately.
Known limitations / merchant FAQs
NR vs Datadog: should the per-incident drop figures match across both platforms? For incidents that fired on both platforms with peer alerts, yes, exactly. The conversion-rate input is the same (same commerce sibling or GA4). Differences trace to incident coverage: an incident only on NR doesn’t appear on DD’s chart and vice versa. The total chart counts will differ; matched-incident drops will not. Apdex math: does a low Apdex during an incident predict the conversion drop? Yes, fairly strongly. In our 90-day data across hundreds of incidents, Apdex < 0.5 sustained for >5 minutes correlates with >1.5pp conversion drop ~80% of the time. Apdex 0.5, 0.7 produces sub-1pp drops typically. Apdex above 0.7 rarely produces measurable drops. The exception: a very brief but very severe incident (say, 60s of total checkout failure) can produce a 2pp drop on the affected window without much Apdex movement because the duration is too short for Apdex’s 5-min rolling window to fully capture. NRQL retention vs incident retention: can I see 12-month incident history? Incidents are first-class entities and retained 13 months by default. The conversion-rate inputs may be on rolled aggregates past day 8 on standard plans (or day 395 on Data Plus), so per-incident attribution gets slightly coarser on older incidents but the chart still works. NR and Datadog disagree on incident count by 4 over 90 days, why? Almost always alert-condition coverage difference. NR may have 4 conditions DD doesn’t, or vice versa. Audit the alert inventory; once aligned, the count converges. The matched-incident drops should be identical regardless. Sampling: does sampling break this card? Incident state is unsampled. Conversion-rate input is unsampled (commerce platform) or sample-corrected (GA4 paid). The drop-pp number is robust. Multi-account: my US and EU stores have different baseline conversion rates, can the chart handle both? Yes. Connect each pair (NR account + commerce sibling) as a separate integration. Each gets its own chart with its own per-incident drops. Combined cross-region analysis is shown side-by-side in the Nerve Centre stack panel. Ingest cost vs visibility: can I sample down without losing this chart? Yes. Conversion-rate is from commerce platform / GA4, not from NR transaction events; NR ingest sampling doesn’t affect this card. Sample down NR transactions freely; this chart remains accurate. Alert tuning: my >10% drop alert fires for tiny incidents, what should I tune? The 10% drop threshold is calibrated for significant incidents; if it fires too often, two options: (a) raise the threshold to 15, 20% if your baseline conversion rate is high enough that 10% is in noise territory; (b) require a minimum incident duration (“alert only if drop >10% AND incident lasted >5 min”) to filter out flutter incidents that briefly spike conversion drop. Option (b) is generally preferred because most short incidents don’t justify a post-incident review anyway. My biggest drop incident shows -1.8pp but the duty engineer remembers it as a “minor” event, why does it look big? Two usual causes: (a) the incident was at peak time when the absolute number of affected sessions is highest, even a brief disruption to checkout costs disproportionate conversion at peak; (b) baseline conversion-rate at that hour was unusually high (a marketing campaign was running), so the relative drop is larger than the engineer’s gut reading. The chart is honest about customer impact; engineer perception is often calibrated to the technical severity of the fix, not the customer cost. Why isn’tdaily impact in the chart instead of per incident?
Per-incident attribution is the actionable view. Daily aggregation would smear individual incidents together and lose the “which incident did the damage” signal that drives post-incident review prioritisation. For daily aggregation, see Revenue Lost / Min summed over the day.