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.
| What it counts | (GA4 sessionConversionRate in trailing 1h) − (median CR for same hour-of-day across prior 30 days) divided by the rolling-30D standard deviation of that hour’s CR. Fires when the result is more negative than -2.0. |
| Sample basis | Sessions with conversions. Pass-through carries the structural GA4 tracking gap (the numerator is GA4-purchased sessions; denominator is all GA4 sessions). The 2σ statistical test makes the alert robust to baseline-level differences between properties. |
| Sampling threshold | None for the 1h × hour-of-day dimension. The query is metric-only with hour-of-day as a low-cardinality dimension; never sampled. |
| Bot traffic filter | GA4’s built-in IAB Tech Lab bot filter applied. Bot sessions don’t fire purchase events, so a bot wave usually suppresses CR (bot sessions in the denominator without conversions in the numerator) and can produce a false-positive alert; the engine cross-checks bot-share before paging. |
| Time zone | The GA4 property’s timezone, NOT UTC. The hour-of-day baseline uses property zone. |
| Currency | Not applicable, CR is a unitless ratio. |
| Refunds | Not applicable to the alert; CR is computed before any refund-related logic. |
| Tracking-gap framing | A CR drop that’s measurement-side (GTM tag broken, consent banner change) shows the same way as a behavioural CR drop (checkout broken, payment provider failing). The alert can’t tell the difference; pair with GA4 Property Health to disambiguate. Property Health amber/red + this alert = measurement issue; Property Health green + this alert = real conversion regression. |
| Why 2σ and not absolute %? | A 2σ test scales to each property’s noise floor. A high-traffic store has a low-noise CR (small σ); even a 5% drop is significant. A low-traffic store has noisy CR (large σ); 5% drops are normal. 2σ catches both without per-property tuning. |
| Time window | RT (real-time, refreshed every 15 minutes; trailing 1h is the alert window). |
| Alert trigger | session-CR drop >2σ vs 30D baseline, sentiment_key ga_conversion_rate. The 2σ threshold corresponds to a ~2.3% false-positive rate per hour, balanced against fast detection. |
| Roles | owner, marketing |
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.| Hour (PT) | Sessions | Purchases | CR | 30D baseline (same hour) | σ (30D) | z-score | Status |
|---|---|---|---|---|---|---|---|
| 09:00, 10:00 | 1,420 | 38 | 2.68% | 2.61% | 0.18 | +0.39 | Normal |
| 10:00, 11:00 | 1,387 | 22 | 1.59% | 2.66% | 0.21 | −5.10 | Alert: CR drop 5σ below baseline |
| 11:00, 12:00 | 1,401 | 19 | 1.36% | 2.71% | 0.20 | −6.75 | Alert continues |
| 12:00, 13:00 | 1,392 | 20 | 1.44% | 2.78% | 0.22 | −6.10 | Alert continues |
- 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
| Card | Why pair it with Conversion-Rate Drop Alert |
|---|---|
| GA4 Conversion Rate | The metric this alert is built on. Use to see CR over a wider window. |
| GA4 Real-Time Purchases | The 30-min companion. Zero purchases = full tag failure or full checkout failure; non-zero-but-low = behavioural failure. |
| GA4 Checkout Completion Rate | The funnel-step view. Healthy add-to-cart + healthy begin-checkout + dropped purchase = the failure is at the final payment step. |
| GA4 Add-to-Cart Rate | The earlier funnel step. If add-to-cart also dropped, the regression is upstream of checkout (PDP / category / search). |
| GA4 Property Health | The disambiguator. If Property Health is amber/red AND this alert fires, the CR drop is measurement-side (GTM tag broken), not behavioural. |
| GA4 Traffic Drop Alert | The complement. Traffic-drop alert fires when sessions tank; this alert fires when CR tanks while sessions hold. Different root causes. |
| Cross-channel: Revenue at Risk from Incident | If a monitoring incident is open concurrent with this alert, the two corroborate. |
| Stripe Charge Failure Rate | The payment-side truth source. Spiking charge failures + this alert = payment provider is the cause. |
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.
| Reason | Direction of divergence |
|---|---|
| Polling lag. We refresh every 15 minutes. A regression at 10:02 may not surface until 10:17. | 0, 15 min lag |
| Baseline cold-start. Properties under 30 days old don’t have a stable σ; we use a flatter aggregate and flag the alert as low-confidence. | First 30 days only |
| Promotion-end suppression. The end of a sitewide sale produces a real CR drop that’s expected; we suppress alerts during configured promotion-end windows. | Suppressed during configured windows |
| Bot-share cross-check. If bot share spikes concurrent with the CR drop, the engine downgrades the alert to “warn” rather than “page” and asks for human confirmation. | Variable |
| Card | Expected relationship | What divergences mean |
|---|---|---|
shopify.ecommerce_conversion_rate | Shopify CR drops with a similar shape, ~10, 30 minutes after this alert (commerce platforms have order-creation lag from carts in flight). | Shopify CR steady AND this alert fires = measurement issue (GTM tag broken), not behavioural. Use Property Health to confirm. |
bigcommerce.ecommerce_conversion_rate | Same shape. | Same. |
adobe_commerce.ecommerce_conversion_rate | Same shape. | Same. |
stripe.charge_failure_rate | Spiking charge-failures + this alert = payment provider is the cause. | Charge-failure flat + this alert = checkout UX or analytics tag, not payment. |
shopify.checkout_started_count | If checkout-started count is healthy but purchases are dropping, the failure is in the final payment step. | Checkout-started also dropping = the failure is upstream (cart, PDP). |
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.