> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Conversion-Rate Drop Alert, Google Analytics 4 > Cleanest canary for checkout regressions, fires before refund-rate or fulfilment cards catch on. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Analytics](/nerve-centre/connectors#connectors-by-type) > 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](/nerve-centre/kpi-cards/google-analytics/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 | Three numbered observations: 1. **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 `purchase` event has stopped firing. **The card doesn't tell you which; it tells you this is real and to drop everything.** 2. **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. 3. **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](/nerve-centre/kpi-cards/google-analytics/ga4-property-health), if amber, the drop may be measurement-side, (d) check [GA4 Real-Time Purchases](/nerve-centre/kpi-cards/google-analytics/real-time-purchases), is the live `purchase` event 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](/nerve-centre/kpi-cards/google-analytics/checkout-completion-rate) for funnel-step view. 4. **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. 5. **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". **Rule of thumb.** Alert fires = stop and run a real checkout from a clean browser. The cost of a false alert investigation (5 minutes) is dwarfed by the cost of a real undetected checkout regression (an hour of zero conversions). ## Sibling cards merchants should reference together | Card | Why pair it with Conversion-Rate Drop Alert | | --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | [GA4 Conversion Rate](/nerve-centre/kpi-cards/google-analytics/ecommerce-conversion-rate) | The metric this alert is built on. Use to see CR over a wider window. | | [GA4 Real-Time Purchases](/nerve-centre/kpi-cards/google-analytics/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](/nerve-centre/kpi-cards/google-analytics/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](/nerve-centre/kpi-cards/google-analytics/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](/nerve-centre/kpi-cards/google-analytics/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](/nerve-centre/kpi-cards/google-analytics/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-platform: Revenue at Risk from Incident](/nerve-centre/kpi-cards/google-analytics/revenue-at-risk) | If a monitoring incident is open concurrent with this alert, the two corroborate. | | [Stripe Charge Failure Rate](/nerve-centre/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](https://analytics.google.com/)** 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. **Why our alert may legitimately differ from a manual GA4 check (rare):** | 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 | **Cross-connector reconciliation, the IMPORTANT one:** This is a GA4-only alert at the technical level, but it correlates with several truth-side signals: | Card | Expected relationship | What divergences mean | | ---------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`shopify.ecommerce_conversion_rate`](/nerve-centre/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](/nerve-centre/kpi-cards/google-analytics/ga4-property-health) to confirm. | | [`bigcommerce.ecommerce_conversion_rate`](/nerve-centre/bigcommerce/ecommerce_conversion_rate) | Same shape. | Same. | | [`adobe_commerce.ecommerce_conversion_rate`](/nerve-centre/adobe_commerce/ecommerce_conversion_rate) | Same shape. | Same. | | [`stripe.charge_failure_rate`](/nerve-centre/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`](/nerve-centre/shopify/checkout_started) | 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). | **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 GA4 `purchase` 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. *** ### Tracked live in Vortex IQ Nerve Centre *Conversion-Rate Drop Alert* is one of hundreds of KPI pulses Vortex IQ tracks across Google Analytics 4 and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.