The de-identified daily returns view. One row per (return_day, product_category, return_reason). `returns_count` is the number of return *requests*; `refunded_amount` sums money only for returns that reached `refunded` — the two diverge because requests can be pending or rejected. The customer linkage present in `stg_postgres__returns` is dropped here. To compute a return RATE, pair returns_count with order volume from `metric_revenue_by_month` (orders_count) or `mart_orders_daily`.
- highTreating `returns_count` as refunds
`returns_count` counts every return request, including `requested`, `approved`, and `rejected`. Only `refunded_amount` reflects money actually returned. Use refunded_amount for financial leakage, returns_count for operational volume.
- highComputing a return rate from this mart alone
This mart has no order/sales denominator. A return RATE needs order volume from `metric_revenue_by_month` (orders_count) or `mart_orders_daily` over the same window — dividing returns_count by anything inside this mart is wrong.
- “Which product categories have the most returns this quarter?”
- “Where is refund money leaking — by category and reason?”