Data analysis
Returns and refunds data
Separate aftersales requests from product lines without duplication.
Two sources distinguish aftersales request workload from product-line issues. Shop aftersales authorization and synchronized coverage are required.
All tables contain fictional sample data, not actual requests. Requested amounts are not completed refunds. Example states illustrate business meaning. Unavailable values are not automatically zero.
#Aftersales request detail
Count requests and examine reasons and states. Each row is one Shop aftersales request, with request/order identifiers, type, latest state, reason, initiator, return method/logistics, timestamps, and request-level amounts.
Query requests created in the last 30 days, including cancellations, rejections, and replacements. Count by type and current state, separating requested amounts from completed refunds.
#Sample raw detail
| Request | Created | Type | Latest state | Reason | Requested total (USD) |
|---|---|---|---|---|---|
| DEMO-RT01 | 2026-10-13 | Return/refund | Processing | Damaged product | 60.00 |
| DEMO-RT02 | 2026-10-14 | Replacement | Pending review | Wrong size | — |
| DEMO-RT03 | 2026-10-14 | Refund | Rejected | No longer needed | 40.00 |
There are three requests and 100 USD of known requested amounts, not 100 USD of completed refunds. Some are processing or rejected, and the replacement has no refund amount. Filter by Shop-local request creation date; states are current, not historical as-of snapshots.
#Sample AI-derived summary
| Type | Requests | Requests with an amount | Known requested amount (USD) |
|---|---|---|---|
| Return/refund | 1 | 1 | 60.00 |
| Replacement | 1 | 0 | — |
| Refund | 1 | 1 | 40.00 |
Keep requests without product lines or matching orders in request counts. Successfully product-matched records alone do not represent all aftersales work.
#Aftersales product-line detail
Find products and SKUs with repeated issues. A row is one product line under an aftersales request, retaining request/order-line identifiers, product, SKU, reason, state, and line-level merchandise, shipping, tax, and total amounts.
Expand DEMO-RT01 and DEMO-RT03 by product line and summarize reasons by SKU. Use line-level amounts, not repeated request totals.
#Sample raw detail
| Request | Return line | Product | Seller SKU | Latest state | Line requested amount (USD) |
|---|---|---|---|---|---|
| DEMO-RT01 | DEMO-RL01 | Cloud Blanket | CB-BLUE | Processing | 40.00 |
| DEMO-RT01 | DEMO-RL02 | Bedside Lamp | BL-WHITE | Processing | 20.00 |
| DEMO-RT03 | DEMO-RL03 | Cloud Blanket | CB-BLUE | Rejected | 40.00 |
DEMO-RT01 has two lines but one request, totaling 40 + 20 = 60 USD. Repeating its 60 USD request total on both rows would incorrectly produce 120. DEMO-RT02 is absent from this line example but must not disappear from request totals.
An order line can have several requests. “Requests,” “affected orders,” and “affected product lines” are different counts. Keep missing amounts, cancellations, and rejections visible rather than silently dropping them.
Return to Business data. Combine reviews and order detail to investigate product issues.