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?”
| What it counts | For each closed CRITICAL/HIGH NR incident in the window, computes drop_pp = baseline_conversion_rate - actual_conversion_rate_during_incident in absolute percentage points. The chart shows one bar per incident, sorted by recency, with the drop_pp as bar height. |
| NerdGraph endpoint | NR side: actor.account.aiIssues.issues(filter: {states: [CLOSED]}) { issues { issueId, priority, createdAt, closedAt } } for incident windows. Commerce side: order-and-session events from the connected commerce sibling for conversion-rate evaluation; or GA4 conversion events. |
| Metric basis | Per-incident actual-vs-baseline comparison. actual_conversion_rate_during_incident = orders / sessions over the incident window; baseline_conversion_rate = rolling 28-day same-day-of-week, same-time-of-day average covering the same minute span. |
| Aggregation window | One bar per incident, computed at incident close. The 90-day window is the chart range; individual incident windows vary from 5 minutes to several hours. |
| Browser vs APM scope | NR side: incident state across all NR product lines (APM, Browser, Infrastructure, Synthetic, Logs). Conversion-rate side: full-funnel (sessions to orders) measured customer-side via GA4 or commerce platform analytics. |
| Severity threshold | CRITICAL and HIGH only. P3/MEDIUM excluded because they typically don’t produce measurable conversion impact, and including them would make the chart noisy. |
| Filtered hosts / services | NR scope: all entities by default; can be narrowed to revenue-critical services. Commerce scope: full-funnel events for the merchant’s primary store. |
| Sample basis | NR incident state is unsampled. Conversion data sample basis depends on source: GA4 is sampled on free-tier accounts (typically 100% on paid); commerce-platform events are unsampled. |
| Time zone | UTC for incident windows; merchant local timezone for “same time-of-day” baseline alignment. Baseline is a 28-day window. |
| Time window | 90D (rolling 90-day chart) |
| Alert trigger | >10% drop (any single incident with >10 percentage-point conversion drop). Calibrated to flag incidents whose customer impact justifies a post-incident review. |
| Roles | owner, marketing |
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:| Incident ID | Severity | Date | Duration | Baseline conv | Actual conv | Drop (pp) |
|---|---|---|---|---|---|---|
| iss-7a01ab | CRITICAL | 14 Mar 26 | 22 min | 3.2% | 1.1% | 2.1pp (-66%) |
| iss-7a04c2 | HIGH | 18 Mar 26 | 8 min | 3.4% | 3.1% | 0.3pp (-9%) |
| iss-7a08e5 | CRITICAL | 22 Mar 26 | 47 min | 3.1% | 0.8% | 2.3pp (-74%) |
| iss-7a0c11 | HIGH | 02 Apr 26 | 12 min | 3.5% | 3.4% | 0.1pp (-3%) |
| iss-7a1234 | CRITICAL | 08 Apr 26 | 31 min | 3.3% | 2.4% | 0.9pp (-27%) |
| iss-7a1789 | HIGH | 15 Apr 26 | 18 min | 3.2% | 3.0% | 0.2pp (-6%) |
| iss-7a1a55 | CRITICAL | 21 Apr 26 | 9 min | 3.3% | 2.9% | 0.4pp (-12%) |
| iss-7a1c88 | HIGH | 26 Apr 26 | 14 min | 3.4% | 3.3% | 0.1pp (-3%) |
| … | … | … | … | … | … | … |
- 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
| Card | Why pair it with Conversion Drop During Incidents |
|---|---|
| Active Incidents | The live counterpart. While that card answers “is something broken now?”, this card answers “did past incidents matter?” |
| Mean Time To Resolve | Pair to see whether faster MTTR correlates with smaller conversion drops. |
| Revenue Lost / Min | Dollar-impact view of the same per-incident relationship. |
| Cart Abandonment During 5xx Spikes | Funnel-step view rather than full-funnel. Same direction; finer detail. |
| Operational Health Score | Composite parent. Big-drop incidents typically saw the score drop below 60; small-drop incidents kept it above 75. |
| Datadog Conversion Drop During Incidents | Cross-connector peer. |
| GA4 Conversion Rate | The conversion-rate input source. Open for raw rate series. |
| Shopify Sales / Min | Volume-weighted view of the same impact. |
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).
| Reason | Direction of divergence |
|---|---|
| Account timezone vs UTC. Incident windows are UTC; conversion baseline uses merchant local timezone for “same time-of-day”. For incidents that span timezone boundaries (e.g., a US-East incident that runs across midnight UTC) the baseline alignment can produce 0.1, 0.3pp drift. | Either direction at boundaries |
| NRQL retention windows. 90-day window uses NR’s incident-history store (separate from raw event retention). Incident metadata is retained 13 months; the conversion-rate inputs may be on rolled aggregates past day 8 on standard plans, producing slightly coarser per-incident attribution. | Drift on older incidents <0.5pp |
| Incident grouping evolution. Applied Intelligence may regroup incidents post-hoc as more correlation evidence arrives; the chart uses the final grouping at incident close. Re-grouping rare. | None typically |
| Conversion source choice. GA4 vs Shopify-native conversion can disagree by 5, 10% on absolute rate (different session definitions). The drop-pp metric is robust because both sides use the same source for actual and baseline. | None for drop-pp |
| Baseline window staleness. 28-day baseline. If the merchant ran an unusually low-traffic campaign during the baseline period, baseline reads low and the incident drop reads low. | Drop understated |
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.