Why this matters
Returns are not one metric. A size-exchange flow, a defective SKU, and a buyer-remorse refund have different fixes. The agent needs the full path to recommend the right response.
What you get
- Return request volume by SKU and reason
- Exchange completion versus refund completion
- Refund dollars by segment
- Whether returners buy again
Walk through it
You
Are returns becoming a retention problem?
Agent
I’ll group return requests by reason and compare refunds, exchanges, and repeat purchase behavior.
Endpoint: POST /v1/projects/:project_id/analytics/query
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fanalytics%2Fquery&method=post
Custom HogQL goes in the OpenAPI-defined `query` field.
Concept fields:
query: "SELECT properties.return_reason AS reason, properties.sku AS sku, countIf(event = 'return_requested') AS requested, countIf(event = 'exchange_completed') AS exchanged, countIf(event = 'refund_completed') AS refunded, sumIf(toFloat(properties.refund_amount), event = 'refund_completed') AS refund_amount FROM events WHERE event IN ('return_requested','exchange_completed','refund_completed') AND timestamp > now() - INTERVAL 60 DAY GROUP BY reason, sku ORDER BY refund_amount DESC LIMIT 25"The output
The agent returns return reasons, SKUs, exchange rates, and refund impact. It should suggest merchandising, support, fulfillment, or product-page fixes based on the dominant pattern.
Setting it up
Emit events from your returns flow and payment system with a shared order id. Include return reason and SKU as normalized fields.
Variations
- “Which SKUs drive the most refunds?”
- “Show exchanges versus refunds by size issue.”
- “Find return reasons associated with later cancellation, without claiming prediction.”