Cleanest canary for checkout regressions, fires before refund-rate or fulfilment cards catch on.
At a glance
A real-time alert that fires when GA4 session-conversion-rate for the trailing hour drops more than 2 standard deviations below the 30-day baseline. The cleanest canary for checkout, payment, or GTM-tag regressions, fires before refund-rate or fulfilment cards catch on. Faster than waiting for revenue cards to trend.
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 beauty brand on BigCommerce, GA4 connected. Property timezone US/Pacific. On 22 Apr 26 at 10:15 PT (a Wednesday), the alert fires.
Three numbered observations:
- The alert fires at -5σ, far above the -2σ threshold. A drop of this magnitude is statistically vanishingly unlikely (a true 5σ event is ~1 in 3.5 million). Either (a) checkout is genuinely broken, (b) payment provider is failing, or (c) GA4’s
purchaseevent has stopped firing. The card doesn’t tell you which; it tells you this is real and to drop everything. - For this brand, the cause was a payment-provider 5xx storm. Stripe was returning 503s on ~50% of charge attempts starting at 10:02 PT. Customers were filling carts, reaching checkout, hitting “Pay”, seeing a generic error, and abandoning. Sessions held steady (10:00, 11:00 traffic was 1,387 vs 1,420 the prior hour, normal); only conversions dropped. This is the classic CR-drop signature: traffic flat, conversions tank. Compare to a traffic-drop alert where sessions also drop.
- Triage workflow when this card fires. Order: (a) test a real checkout from a clean browser, does payment go through? If errors, escalate to engineering with the error message, (b) check Stripe / Shopify Payments / Adyen status pages for known incidents, (c) check GA4 Property Health, if amber, the drop may be measurement-side, (d) check GA4 Real-Time Purchases, is the live
purchaseevent firing at all? Zero = full tag failure; non-zero-but-low = behavioural failure, (e) check the funnel: are users reaching the checkout page? Use GA4 Checkout Completion Rate for funnel-step view. - What WOULD trip false positives? Three known patterns: (a) end-of-sale ramp-down: a 10% sitewide promotion ending at midnight produces a sharp CR drop in the next hour as urgency disappears; we suppress alerts during configured promotion-end windows. (b) traffic source mix shift: a sudden organic-traffic surge dilutes CR (organic converts lower than email/direct); the engine flags channel-mix changes in the alert detail. (c) bot wave: bot sessions in the denominator without conversions in the numerator suppress CR; cross-check bot share.
- The detection lag is 10, 30 minutes. GA4’s session-conversion-rate metric updates with the trailing-hour
runReport, which has 5, 15min event-ingestion lag plus our 0, 15min polling cycle. For sub-5-minute detection of payment failures, use Stripe webhook monitoring or your payment provider’s status page directly. This card catches what those don’t: the aggregate behavioural signal of “customers can’t complete checkout for any reason”.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in GA4: GA4 doesn’t have a 2σ-baseline-aware real-time CR alert. The closest GA4-native rebuild:
Realtime → Conversions for the live conversion rate. Compare against your usual hour-of-day pattern (eyeball check).
Reports → Monetization → Ecommerce purchases → Session conversion rate for the trended view.
Reports → Realtime → Purchase by minute to see if the live purchase event is firing at all.
Other GA4 views that look relevant but aren’t:
- GA4 Custom Insights: GA4’s own anomaly detection. Slower polling (24h+), no hour-of-day baseline, less sensitive than 2σ.
- Reports → Acquisition (any view): 24h+ lag.
- Explorations: can be built but require manual setup; can’t easily re-create the 2σ test.
Cross-connector reconciliation, the IMPORTANT one:
This is a GA4-only alert at the technical level, but it correlates with several truth-side signals:
This card complements monitoring; it doesn’t replace it. A payment-provider 5xx storm will be visible in your monitoring platform’s metrics within seconds. This card detects the customer-side outcome of those errors (and other failures monitoring can’t detect: confusing UX after a deploy, broken JavaScript on a specific browser, regional CDN issues affecting checkout assets).
Known limitations / merchant FAQs
The alert fired but my Stripe / Shopify Payments / Adyen dashboard says everything is healthy. What’s wrong? The CR drop is behavioural, not payment-provider-side. Common causes: (a) a deploy introduced a JavaScript error breaking the checkout button on a specific browser, (b) a third-party app (chat widget, abandonment popup) deployed an update that’s now intercepting clicks on the Pay button, (c) consent-banner change started defaulting to Reject and customers can’t reach the GA4-tracked checkout flow, (d) a CDN caching change is serving a stale version of the checkout JS to some users. Test a real checkout from a clean browser; if it works, the issue is browser/region-specific. The alert fired but my GA4 Property Health is also red. Is the CR drop real? Probably not, it’s a measurement artefact. When Property Health is amber/red AND this alert fires concurrently, the GA4purchase event is failing to fire, making CR look low even though real conversions are happening. Customers ARE buying; GA4 just isn’t seeing the events. The fix is on the GA4 measurement side (GTM container, Key Event configuration), not on the checkout side. Property Health green + this alert = real regression. Property Health red + this alert = measurement issue.
Why 2σ instead of “drop X%”?
A percent-based threshold needs per-property tuning (high-traffic stores have low-noise CR; low-traffic stores have noisy CR; the same 5% drop is significant for one and noise for the other). The 2σ test scales automatically: it asks “is this drop unusual for this property?” and fires when the answer is “yes, very”. No tuning required.
The alert fired, but my Shopify CR is also dropping in the same window. Are both real?
Yes, this is the unambiguous case. When GA4 CR drops AND Shopify CR drops concurrently, you have a real customer-facing checkout regression. Triage immediately: test a checkout, check payment provider, check engineering deploys in the last 4 hours, check consent-banner version history.
My CR dropped from 3% to 2%. Is that 2σ?
Depends on the noise floor. For a high-traffic property where hour-to-hour CR variance is ~0.1%, dropping from 3% to 2% is ~10σ, catastrophic. For a low-traffic property where variance is ~0.5%, dropping from 3% to 2% is ~2σ, just at the alert threshold. The card surfaces the actual z-score in the alert detail; check that to gauge severity.
The alert keeps firing on Friday afternoons. Why?
Friday afternoons have a real seasonal CR pattern, customers browse but defer purchase to weekend. The 30D baseline should learn this, but if your prior 30 days had unusual Fridays (a sale, a viral moment), the baseline σ is inflated and “normal” Fridays look anomalous. The card has a “DOW-aware” mode (configurable); enable it for properties with strong weekday/weekend patterns.
Does this alert fire during a planned promotion?
Yes, unless you configure a promotion window. A sitewide sale typically raises CR (urgency, deal-seeking behaviour); the alert fires for drops, so a promotion-driven CR rise stays green. But the end of a promotion can produce a real drop the alert sees as anomalous; configure end-of-promotion windows to suppress.
My GA4 says CR dropped 3σ but my commerce platform shows orders trending normal. Which is right?
The commerce platform. GA4 is structurally lower than commerce-platform CR (the tracking gap), so when GA4 CR drops, it might be (a) the gap suddenly widened (measurement issue, see Property Health), or (b) a real CR drop. Cross-check both before concluding. Treat the commerce platform as the source of truth; use this card as the early-warning detector.
Why does the alert have a ~2.3% per-hour false-positive rate?
2σ is the calibration choice. We chose it to balance fast detection (low miss rate) against alert fatigue (low false-positive rate). At 2σ on hourly data, ~2% of hours will trip the alert by random chance over 30 days; that’s roughly one false positive per 50 alerts. Tightening to 3σ would reduce false positives to ~0.3% but slow real-detection. We recommend keeping the default; pair with Property Health to disambiguate measurement-vs-behavioural causes.
Can I configure a different baseline window (e.g. 14 days instead of 30)?
Not currently. The 30-day baseline is the engine default; we may add per-property tuning in the future. For very seasonal businesses (florists during Mother’s Day week), the 30D baseline can over-state σ; contact support if the baseline is producing too many false positives during seasonal peaks.