Abandoned cart recovery for Shopify and WooCommerce
Recovery covers eligible, tracked shopper activity after a cart, product view, or lifecycle event. It can draft a store-aware message when identity, consent, suppression, journey, connection, and service conditions permit. This page covers the three recovery surfaces and how to wire them up.
The three recovery surfaces
| Surface | Trigger | Timing |
|---|---|---|
| Cart recovery email | Shopper added items (with a known email) but didn’t check out. | Cart flips to “abandoned” after ~60 minutes idle; a scan runs every 15 minutes. |
| Browse rescue | Shopper dwelled 30+ seconds on a product page without carting. | Scanned every 30 minutes, roughly 30–60 minutes after the visit. |
| Post-purchase / win-back | 30+ days since last order (default). | Checked daily; enrolls into a three-step drip (immediately, +7 days, +21 days). |
Plans and channels
What makes Zubby’s recovery different
- AI-drafted bodies - not a template with merge tags. Every send is written fresh: the AI drafts three candidate subject lines and a short body that names the actual items left behind, follows your brand-voice constraints, rotates angles so consecutive sends never repeat, and writes in the shopper’s language.
- Discounts stay under your control - a campaign step only mentions a discount when you flip its Include discount code toggle, and the chat agent only resolves offers from the discount rules you define under
Dashboard → Rules. Review generated copy to check that any promised discount matches an approved offer. - Built-in restraint - one active enrollment per shopper per journey, a 72-hour re-entry window, and optional quiet hours. These controls limit repeat contact; they do not replace consent, suppression tests, or a suitable contact policy.
- Conversion-aware - when the shopper’s order lands, the cart is marked purchased and its recovery messages are marked converted, so the revenue shows up attributed in your analytics.
Setting it up
- Connect a sending mailbox under
Integrations → Email- Microsoft 365, Gmail, or SMTP. Recovery emails send from your own address, which is why replies land in your real inbox and deliverability rides on your domain. A configured platform sender may be eligible as a fallback; verify its domain, consent, suppression, and delivery result before rollout. - Create a campaign from
Dashboard → Recovery. Each step has a delay, a tone, a channel (email, SMS, or web push), free-text instructions for the AI, and toggles for including products and a discount code. - Pair it with on-site rescue at
Dashboard → Rescue- when a shopper idles with a cart and their risk score crosses your threshold, the widget fires a rescue playbook (reassurance, urgency, incentive, or helpful) before they ever leave. Off-site email is the safety net; on-site rescue is the first line. - Verify a controlled delivery. A configured workflow is not proof that an eligible shopper entered or that the connected channel accepted the message. Test one eligible and one suppressed case before wider rollout.
Attribution
Opens are tracked with a pixel, clicks route through a signed redirect keyed to the message, and conversions are matched server-side: when an order comes in, Zubby ties it back to the same cart and marks the recovery messages converted. This association is an attribution rule, not proof that the message caused the order. The funnel (sent → opened → clicked → converted) is charted on the Recovery page.
Deliverability & consent
For your connected mailbox, check the sending domain’s SPF/DKIM setup. A configured platform-sender fallback uses its own sending path; confirm the actual From, reply-to, authentication, and delivery result in a controlled test. Connecting a mailbox does not guarantee inbox placement. Every email carries a signed unsubscribe link plus RFC 8058 one-click List-Unsubscribe headers, and unsubscribed addresses go on a per-store suppression list that is checked before every send. SMS steps append “Reply STOP” with a signed preferences link.
Don’t over-mail
Browse abandonment specifics
Browse rescue works from page-view signals the widget records: which product a shopper viewed and how long they dwelled there. A session qualifies when it includes a product page with 30+ seconds of dwell and no cart. The generated message references the actual product they hesitated on, not a guessed one.
Two prerequisites: the shopper’s email must be known (captured as a lead through the widget), and an active recovery campaign must exist to supply the tone and instructions. The widget records page-view signals automatically on supported Shopify and WooCommerce installs. Custom or headless embeds must be tested to confirm the page and product context your storefront supplies is sufficient before enabling browse recovery.
Win-back specifics
A daily scan finds shoppers with at least one order and no purchase in 30+ days, then enrolls them in the winback journey - a three-step drip that opens soft (“here’s what’s new”), reinforces value a week later, and only offers a gentle, time-bound incentive on the final touch, and only if you have discounts enabled. Shoppers already in an active winback enrollment are never enrolled twice.
Next: journeys
Recovery sequences are powered by the journeys engine, which also supports multi-step drips across seventeen triggers - back in stock, price drop, post purchase, birthdays, replenishment, and more. See Journeys & sequences.