Approved monthly returns, built on `mart_returns_daily`. `returns_count` is the number of return requests; `refunded_amount` is realised refunds only (returns that reached `refunded`). `avg_refund_per_return` is a formula measure (sum(refunded_amount) / nullif(sum(returns_count), 0)) so it stays correct across any window. There is NO sales denominator here — to compute a return RATE, pair `returns_count` with `orders_count` from `revenue_by_month` over the same window.
- highTreating `returns_count` as refunds
`returns_count` counts every request (requested/approved/received/ refunded/rejected). Only `refunded_amount` is money actually returned. Use refunded_amount for financial leakage, returns_count for operational volume.
- highComputing a return rate from this metric alone
This metric has no order/sales denominator. A return RATE = returns_count / orders_count needs `orders_count` from `revenue_by_month` over the same window. Dividing by any measure here is wrong.
- mediumRecomputing `avg_refund_per_return` client-side
`avg_refund_per_return` is a formula measure (sum/sum). Dividing two already-aggregated outputs across a multi-month window yields a different (biased) number.
- “How many returns and how much refunded per month over the last 6 months?”
- “Which product categories drove the most refunded value this year?”
- “What are the top return reasons by refunded value?”
- revenue_by_month
Provides `orders_count` — the denominator for a true return rate, and the revenue context for refund-leakage analysis.
- product_reviews
Returns for `defective` / `damaged_in_transit` reasons corroborate low review scores; cross-check categories that spike in both.