Refund-rate anomaly. Catches batch-quality issues, broken sizing, or coupon misuse before the support inbox does.
At a glance
Real-time refund-rate anomaly: 24-hour rolling refund rate has crossed 2× the 30-day baseline. Catches batch-quality breakdowns, broken-sizing returns, fraud waves, and coupon-stacking abuse before the support inbox catches up.
| What it counts | (refunds_24h ÷ orders_24h) > 2 × (refunds_30D ÷ orders_30D). Both rates use refund-creation date in the numerator and order-creation date in the denominator. Each refund record is one count regardless of value. |
| VAT / tax treatment | Not applicable, rate metric. |
| Shipping | Not applicable directly; refunded shipping doesn’t change the count. |
| Discounts | Not applicable. |
| Refunds | This is the metric. |
| Cancelled / voided orders | Excluded from refund count (cancellations create different events). |
| Currency | Multi-currency safe (rate metric). |
| Channels / sources | All channels. POS refunds at till count if Shopify creates a refund record (most do). |
| Time window | RT (5-min poll cadence) |
| Alert trigger | rolling 24h refund rate >2× 30D baseline. Configurable. |
| Sentiment key | refund_rate |
| Roles | owner, operations, finance |
Calculation
Calculated automatically from your Shopify 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 UK womenswear brand on Shopify Plus, normal refund rate ~6.8% (returns-friendly fashion). Friday 09 May 26, 16:00 BST. The alert fires: trailing 24h refund rate = 14.2%, 2.09× the 30D baseline of 6.8%. Decomposition of the 24h refund pool:| Refund reason cluster | Count | Share | Note |
|---|---|---|---|
| ”Wrong size” / “didn’t fit” | 41 | 38% | Up 3× normal |
| ”Quality issue” / “stitching” | 28 | 26% | Up 5× normal |
| ”Not as pictured” | 14 | 13% | Normal |
| ”Changed mind” | 12 | 11% | Normal |
| ”Late delivery” | 8 | 7% | Normal |
| ”Damaged in transit” | 5 | 5% | Normal |
| Total 24h refunds | 108 | 100% |
- The signal is concentrated. Of 108 refunds in 24h, 69 (64%) are sizing or quality issues; both are up sharply vs baseline. This is a product-quality event, not a generic refund-rate drift.
- The cause is likely a single SKU or batch. Drilling into product-level: the new “Verona dress” launched 02 May, customers returning since 06-08 May. 47 of 108 refunds are this single SKU. The dress’s measurements are running 1-1.5 sizes small.
- The action is immediate. Pause Verona-dress ads (Google, Meta), update the PDP with revised sizing guidance, email Verona-buyers proactively offering pre-paid return labels with the next size up.
- The financial impact is real. 47 dress refunds × £85 average = £4,000 of refund value already booked, with more in the pipeline (the cohort is still receiving and trying on). Pair with Refund Value for the running total.
- The repeat-rate impact is bigger. Customers who refund typically don’t reorder for 90+ days. 47 customers is a 3-month repeat-cohort hit. Cross-reference Repeat Customer Rate over the next quarter for the lagging effect.
- POS interplay. If the brand has a London showroom, customers can return the dress in person; that creates a refund without a returns-API record but still surfaces here. The split between online-returns and in-store-returns helps localise the issue: heavy in-store returns suggest the photography / sizing chart is the culprit.
Sibling cards merchants should reference together
The refund-spike alert is the trigger. The diagnostic cards:| Card | Why pair it with this alert |
|---|---|
| Refund Rate | The 30D rolling rate this alert deviates from. Use to confirm the spike is acute, not part of a slow drift. |
| Refund Count | Order-count companion. Refund value spike with flat count = high-value-item issue; rising count = systematic. |
| Refund Value | The £-impact view. Pair to compute the running £ at risk. |
| Top Refunding Customers | Customer-level drill-down. Flag potential refund fraud or chronic-returner accounts. |
| Customer Feedback Spike Alert | Companion canary; usually fires hours before this for product-quality events. |
| Top Products by Revenue | SKU drill-down; concentrated refunds usually trace to a single SKU. |
| Refund Status | Process state of the return cohort; helps see whether refunds are flowing through cleanly. |
| Repeat Customer Rate | The lagging consequence; refund spikes hurt repeat rate 60-90 days later. |
Reconciling against the vendor’s own dashboard
Where to look in Shopify Admin: Shopify doesn’t expose a single refund-rate-anomaly alert; reconstruct from:- Analytics → Reports → “Returns” filtered to the same 24h window: gives the count and value.
- Orders → Filter by Refunded with date range last 24h: gives the order list.
- Apps like Loop Returns / Returnly / AfterShip Returns: their dashboards expose return-rate trends.
| Reason | Direction | Why |
|---|---|---|
| Refund timing definition | Either | We use refund-record creation timestamp; some Shopify reports use original-order date. The two diverge sharply during refund waves. |
| Time zone | Boundary 24h window | UTC vs store time zone. |
| Partial refunds | Counting | We count one refund record per Shopify refund event. A partial-then-full refund on the same order creates two records and counts as two. |
| Returns app integration | Either | Apps like Loop create their own refund records via Shopify Refund API; usually counted same as native, but watch for duplication if the app retries. |
| Sync lag | Ours lower for “right now” | Most-recent 5 to 15 minutes of refund-creation may not be in. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
stripe.stripe_refunds | Should track within 5% for Stripe-gateway orders | Refunds on PayPal, Apple Pay, etc, route through their respective gateways and won’t appear in Stripe. |
paypal.paypal_refund_count | Same logic | Single-gateway view. |
klaviyo.kl_unsubscribe_rate | Lagging correlation | Refund-spike events typically drive unsubscribe spikes 7-14 days later. |
Known limitations / merchant FAQs
Why is the multiplier 2×? Should I tune it? 2× is a generic anomaly threshold. Tune based on your category and volume:- Low-refund-rate categories (electronics, beauty, B2B): 2× is too tight; small absolute spikes trip it. Use 3-4×.
- High-refund-rate categories (fashion, footwear): 2× works.
- Subscription / consumables: 2× is fine, refund pattern is steady.
- Customer accounts with very recent first orders + refunds.
- High-velocity multi-SKU orders refunded within hours.
- Repeated chargebacks on the same payment instrument.
- Open the refund list filtered to last 24h. Sort by refund value desc and reason cluster.
- Identify the cause cluster: sizing? quality? damage? changed-mind? Each has a different remedy.
- Identify the SKU concentration: are 50%+ of refunds on one SKU? That SKU is the issue. Pause its ads, update its PDP, email its buyers.
- Identify customer concentration: are 10%+ of refunds from one customer? Possible fraud. Investigate.
- Communicate proactively with customers in the at-risk cohort: those who bought the same SKU in the last 7-14 days but haven’t refunded. Offer pre-paid returns or apology credit.
- Document the cause in your ops playbook. Refund spikes from the same root cause should not recur.