Cart Rescue

Cart Rescue is Zubby’s live, in-session intervention. While a shopper is still on your store, the widget quietly watches for hesitation - an idle cart, a bounce back and forth on the shipping page, an exit-intent mouse movement - accumulates those signals into a risk score, and when the score crosses your threshold the AI opens the chat and starts a conversation designed to remove the blocker. The whole point is to act before the shopper leaves, while recovery emails act after.

Where it lives

Dashboard → Cart Rescue - performance KPIs (rescues triggered, engagement rate, conversion rate over the last 30 days), a trigger→engaged→converted funnel chart, a plain-English preview of your current trigger, and the editable configuration form.
The detection itself runs inside the storefront widget - no extra script or pixel is needed.

How hesitation is scored

Rather than firing on a single event, the widget keeps a running risk score per session and adds points as signals stack up. Any one signal is weak evidence; several together are a shopper about to walk. The signals and their weights:

Signal	Points	When it fires
Idle cart	+40	The shopper has a cart and has been inactive for longer than your idle timeout. Any mouse, scroll, or key activity resets the timer.
Repeated page visits	+30	The shopper hits the same shipping or checkout page a second time - the classic “checking the shipping cost again” pattern.
Exit intent	+25	The cursor moves toward closing the tab or leaving the page.
Chat opened, no typing	+20	The shopper opened the widget but typed nothing - they have a question they can’t articulate.

When the cumulative score reaches your risk threshold (default 75), the rescue fires: the widget opens, a hidden system instruction tells the AI the shopper appears hesitant and which playbook to use, and the AI opens the conversation. Each session gets at most one rescue - once triggered, the widget will not nag the same shopper again.

Why a score, not a single trigger

With the default threshold of 75, no single signal is enough - an idle cart (40) plus a repeat checkout visit (30) still needs one more signal. Lowering the threshold to 40 makes idle-cart alone sufficient. That is the whole tuning surface: the threshold decides how much evidence you demand before interrupting a shopper.

Configuration

Settings are stored on the widget config and take effect on the next widget load. The form on the Cart Rescue page exposes four controls:

Enabled - the master switch (default on). Turning it off disables all hesitation detection; the rest of the widget is unaffected.
Idle cart timeout - 10–300 seconds, default 60, with quick presets at 30/45/60/90/120s. How long a shopper with a cart can sit inactive before the idle signal counts.
Risk score threshold - 25–100, default 75. The slider is labeled Aggressive (25), Balanced (60), Conservative (100). Higher means fewer, more-targeted rescues.
Playbook - the messaging strategy the AI uses in the rescue conversation (below).

The green “Rescue is live” preview pane above the form restates your current config as one sentence - “when a shopper sits idle for 60s with a cart and their risk score reaches 75+, the AI fires the reassurance playbook” - so you can sanity-check a change before saving.

The four playbooks

Playbook	Strategy
Reassurance (default)	Calm, confidence-building - leads with guarantees, return policy, and shipping answers. Best default because most hesitation is trust-shaped.
Urgency	Gentle scarcity - low-stock and limited-time framing. Use sparingly; it reads pushy on considered purchases.
Incentive	Offer-led - a discount code or free shipping to close the sale. A hypothesis to test against a non-discount message; it can reduce margin.
Helpful	Concierge mode - asks what the blocker is and offers human-style help. Good for complex or high-consideration catalogs.

Outcomes: how rescue is measured

Every trigger writes a rescue event carrying the trigger type, the risk score at firing, and an outcome that only ever upgrades:

Ignored - the default. The rescue fired; the shopper never responded.
Engaged - the shopper replied in the rescue conversation.
Converted - an order came in that matches the rescued cart. This is set server-side by order attribution when the purchase webhook arrives, so it survives the shopper closing the tab and checking out later.

The dashboard’s three KPIs and the funnel chart are direct counts over these outcomes: engagement rate is engaged ÷ triggered, conversion rate is converted ÷ triggered. A cart that already converted is never re-rescued, and outcomes never downgrade - a converted rescue stays converted.

Rescue vs. recovery - pre- vs. post-abandonment

Two layers, one funnel

Rescue and recovery are complementary, not alternatives. Rescue works the seconds before abandonment, inside the session, with zero contact info required. Recovery works the hours after, by email, and needs an address. A cart that rescue saves never enters the recovery pipeline - which is exactly the goal: the cheapest save is the one that happens before the shopper leaves.

Tuning advice

Start at the defaults (60s / 75 / reassurance) and let a week of data accumulate before touching anything.
Low trigger volume? Lower the threshold toward 60 or shorten the idle timeout. Low engagement rate with healthy volume? You are interrupting too early - raise the threshold instead.
There is no universal rescue-conversion benchmark. Use the Overview funnel with a documented baseline and eligible holdout before changing thresholds.
Try one playbook change at a time. Switching playbook and threshold together makes the funnel unreadable.

Gotchas

Rescue needs to see the cart. The Shopify theme embed and the WooCommerce widget bridge push cart state automatically; on a custom embed you must supply cart context yourself or idle-cart and conversion matching cannot work.
The rescue page requires the recovery capability on your team role - teammates without it are redirected. See Team & roles.
Config changes apply on the shopper’s next page load, not to sessions already in flight.
“No rescue events yet” on a new store is normal - events only appear once real shoppers with real carts hesitate.

Cart & browse recovery - the post-abandonment email layer.
Widget overview - how the widget boots and what it can see.
Dashboard overview - where rescue KPIs roll up.
A/B testing - measure playbook changes properly.

Example: intervene only when the cart is known

A shopper with a known cart pauses long enough to meet your configured threshold. Test that the selected message appears once as intended, then test a guest with no cart context and a page excluded by your settings. A hesitation score is a heuristic, not a calibrated purchase probability. Core Cart Rescue and Growth proactive engagement have different triggers and gates; check the settings for the surface you enable. Shopify holdout reporting has linked-order and uncertainty limits in Analytics.