High-LTV customers refunding repeatedly, leading indicator of churn. Trigger a save-flow campaign before they go silent.
At a glance
High-LTV WooCommerce customers refunding repeatedly. Leading indicator of churn. Trigger a save-flow campaign before they go silent.
Calculation
Calculated automatically from your WooCommerce 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 homewares brand on managed-Woo with strong repeat purchase behaviour. 90D window: 14 Jan 26 to 14 Apr 26.
The card flags 32 customers totalling $45,440 LTV at risk. Three observations:
- High-LTV refunders are a red flag, not a problem customer. These are the merchant’s best customers, they buy a lot, and when product / fit / quality fails they refund rather than absorb. Losing 32 customers worth $45,440 LTV typically costs more than the refund expense itself. The save-flow message (“we noticed your last few orders had returns, can we help?”) often retains them.
- Self-hosted variance is the recurring theme. On self-hosted Woo with sync lag, refund events sometimes appear in the index hours late. The at-risk set may briefly under-count when a refund is pending sync. Managed-Woo with reliable cron eliminates this.
- Plugin-induced data shape variance: Subscriptions plugin. WooCommerce Subscriptions cancellations are not always refunds (sometimes pro-rata refund, sometimes no-refund cancellation). The card joins on refund events specifically, so subscription churn-without-refund is invisible here. Pair with Customer Churn for the full picture.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in WooCommerce Admin: Woo does not surface this combined view natively. Closest manual approximation: WP Admin → WooCommerce → Customers, filtered by spend > $500 and refund count > 1. Why our number may differ from a manual segment:
Cross-connector reconciliation:
Known limitations / merchant FAQs
Self-hosted vs managed-Woo, why does it matter? Sync gaps under-count refunds briefly on self-hosted, the at-risk set updates late. Managed-Woo is steadier. Status-filter selection, why exclude guests? Guests have no LTV history (no_customer_user link). Including them would conflate one-time buyers with at-risk repeat customers.
Refund-object accounting, why 2+ events?
A single refund is normal (sizing, damage). Two refunds in 90 days is the early signal of dissatisfaction; three+ is severe.
Plugin-induced data shape variance, what plugins change behaviour?
- WooCommerce Subscriptions: cancellations may not be refunds; pair with Customer Churn.
- Smart Coupons / Store Credit: refunds-as-store-credit do not create refund posts in some configurations; verify in your store.
- B2B / Wholesale plugins: bulk credit-notes for wholesale returns may not appear as refund posts.
- Match LTV threshold ($500) and refund-count threshold (2+) explicitly.
- Match the 90D window.
- Confirm currency normalisation if multi-currency.
- If gap remains, contact support.