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.
| What it counts | SUM(customer_LTV) WHERE customer has 2+ refund events in last 90D AND lifetime value > $500. Joins Woo customer / order / refund data. |
| REST API endpoint | Woo: /customers, /orders, /orders/{id}/refunds. Aggregated client-side. |
| VAT / tax treatment | LTV computed on order.total (tax-inclusive). |
| Status filter | Customers with _customer_user > 0 (logged-in registered customers; guests are excluded because no LTV history). |
| Refunds | The trigger metric. 2+ refund events in 90D classifies as “at-risk”. |
| Cancelled / failed orders | Excluded from LTV. |
| Currency | LTV summed in store currency. Multi-currency stores need filter alignment. |
| Channels / sources | All Woo orders contribute to LTV; refunds across all channels count toward the trigger. |
| Self-hosted vs managed-Woo | Self-hosted with sync gaps may miss refund events for hours, briefly under-flag the at-risk set. Managed-Woo is steadier. |
| Time window | 90D |
| Alert trigger | >$5K LTV at risk (sum of at-risk LTV across all flagged customers in the window) |
| Roles | owner, marketing, finance, operations |
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.| Cohort | Count | Avg LTV | At-risk LTV |
|---|---|---|---|
| All registered customers | 12,400 | $186 | n/a |
| Customers with 2+ refunds in 90D | 84 | $640 | $53,760 |
| … and lifetime value > $500 (this card) | 32 | $1,420 | $45,440 |
- 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
| Card | Why pair it with Refund-Driven Churn |
|---|---|
| WC Customer Churn | Broader churn view (includes silent churn). |
| WC Refund Rate | Store-level refund signal. |
| WC Top Customers | The high-LTV customer list, this card is a subset. |
| WC Top Refunded Products | Identifies the SKUs driving refunds. |
| Klaviyo High-Value At-Risk | Email save-flow trigger. |
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:| Reason | Direction |
|---|---|
| Time-zone. UTC vs WP-site. | Boundary effects |
| Self-hosted server uptime. Sync gaps under-count refunds briefly. | Self-resolves |
| Plugin-version compatibility. WooCommerce Subscriptions cancellations may or may not produce refund events. | Either |
| Refund-object aggregation. WC creates one post per refund event; multi-step refunds can over-count toward the 2+ trigger. The card de-duplicates by order. | Without de-dup, ours higher |
| Currency plugin. LTV needs single-currency normalisation. | Material for multi-currency |
| Card | Expected relationship |
|---|---|
klaviyo.klv_high_value_at_risk | Email-side at-risk list. Should overlap with this card’s at-risk customers. |
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.