
Shopify Admin Exchange Vs Refund Ratio
- 7 installs
- 173 repo stars
- Updated June 26, 2026
- 40rty-ai/shopify-admin-skills
shopify-admin-exchange-vs-refund-ratio is a Shopify Admin skill that reports the share of returns resolved as exchanges, store credit, or cash refunds.
About
A Shopify Admin skill that analyzes return resolutions and calculates the split between exchanges (revenue kept), store credit (deferred), and cash refunds (revenue lost). It supports an optional prior-period comparison to show the trend. It is read-only and uses the Shopify Admin returns and orders GraphQL queries. Operators use it to track how much return-driven revenue is being recovered.
- Splits returns into exchange / store credit / refund
- Tracks revenue-recovery rate with optional period comparison
- Read-only Shopify Admin returns and orders queries
Shopify Admin Exchange Vs Refund Ratio by the numbers
- 7 all-time installs (skills.sh)
- Ranked #1,587 of 2,715 Automation & Workflows skills by installs in the Skillselion catalog
- Data as of Aug 1, 2026 (Skillselion catalog sync)
shopify-admin-exchange-vs-refund-ratio capabilities & compatibility
Free; requires an authenticated Shopify CLI session with read_orders and read_returns scopes.
- Capabilities
- returns analytics · revenue reporting · kpi tracking
- Use cases
- data analysis
- Pricing
- Free
What shopify-admin-exchange-vs-refund-ratio says it does
Analyzes return resolutions to calculate the split between exchanges (revenue retained), store credit (revenue deferred), and refunds (revenue lost).
Read-only skill — no mutations are executed. Safe to run at any time.
npx skills add https://github.com/40rty-ai/shopify-admin-skills --skill shopify-admin-exchange-vs-refund-ratioAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 7 |
|---|---|
| repo stars | ★ 173 |
| Last updated | June 26, 2026 |
| Repository | 40rty-ai/shopify-admin-skills ↗ |
What it does
Measure what share of Shopify returns are resolved as exchanges, store credit, or cash refunds to track revenue recovery over a period.
Who is it for?
Tracking revenue recovery from returns as exchanges vs refunds over time.
Skip if: Processing returns or issuing refunds; it only reports resolutions.
When should I use this skill?
During periodic ops or finance reviews of return-handling performance.
What you get
A breakdown of return resolutions by exchange, store credit, and refund with optional trend.
- Resolution breakdown by exchange/store credit/refund
- Optional prior-period comparison
By the numbers
- Default 30-day lookback window
- 3 resolution categories tracked
Files
Purpose
Analyzes return resolutions to calculate the split between exchanges (revenue retained), store credit (revenue deferred), and refunds (revenue lost). Tracks this as a revenue recovery metric over time. Read-only — no mutations.
Prerequisites
- Authenticated Shopify CLI session:
shopify store auth --store <domain> --scopes read_orders,read_returns - API scopes:
read_orders,read_returns
Parameters
| Parameter | Type | Required | Default | Description |
|---|---|---|---|---|
| store | string | yes | — | Store domain (e.g., mystore.myshopify.com) |
| days_back | integer | no | 30 | Lookback window for return resolutions |
| compare_days_back | integer | no | 0 | Optional prior period for comparison (0 = no comparison) |
| format | string | no | human | Output format: human or json |
Safety
ℹ️ Read-only skill — no mutations are executed. Safe to run at any time.
Workflow Steps
1. OPERATION: returns — query Inputs: query: "created_at:>='<NOW - days_back days>'", first: 250, pagination cursor Expected output: Returns with refunds { totalRefundedSet }, exchangeLineItems, and resolution status
2. Categorize each return resolution:
- Exchange: return has
exchangeLineItemswith quantity > 0 - Store credit: return has
refundswith gift card or store credit payment - Refund: return has cash/card refund with no exchange
3. OPERATION: orders — query (if compare_days_back > 0) Inputs: Same logic for prior period to compute trend
GraphQL Operations
# returns:query — validated against api_version 2025-01
query ReturnResolutions($query: String!, $after: String) {
returns(first: 250, after: $after, query: $query) {
edges {
node {
id
status
createdAt
totalQuantity
order {
id
name
}
exchangeLineItems(first: 10) {
edges {
node {
id
quantity
lineItem {
variant {
id
title
}
}
}
}
}
refunds(first: 5) {
id
totalRefundedSet {
shopMoney {
amount
currencyCode
}
}
}
returnLineItems(first: 20) {
edges {
node {
refundableQuantity
returnReason
}
}
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}# orders:query — validated against api_version 2025-01
query OrdersInPeriod($query: String!, $after: String) {
orders(first: 250, after: $after, query: $query) {
edges {
node {
id
name
totalPriceSet {
shopMoney {
amount
currencyCode
}
}
}
}
pageInfo {
hasNextPage
endCursor
}
}
}Session Tracking
Claude MUST emit the following output at each stage. This is mandatory.
On start, emit:
╔══════════════════════════════════════════════╗
║ SKILL: Exchange vs Refund Ratio ║
║ Store: <store domain> ║
║ Started: <YYYY-MM-DD HH:MM UTC> ║
╚══════════════════════════════════════════════╝After each step, emit:
[N/TOTAL] <QUERY|MUTATION> <OperationName>
→ Params: <brief summary of key inputs>
→ Result: <count or outcome>On completion, emit:
For format: human (default):
══════════════════════════════════════════════
EXCHANGE vs REFUND RATIO (<days_back> days)
Total returns resolved: <n>
Resolution breakdown:
Exchange (revenue kept): <n> (<pct>%)
Store credit (deferred): <n> (<pct>%)
Refund (revenue lost): <n> (<pct>%)
Revenue recovery rate: <pct>%
(exchanges + store credit as % of all returns)
Output: exchange_refund_ratio_<date>.csv
══════════════════════════════════════════════For format: json, emit:
{
"skill": "exchange-vs-refund-ratio",
"store": "<domain>",
"period_days": 30,
"total_returns": 0,
"exchanges": { "count": 0, "pct": 0 },
"store_credit": { "count": 0, "pct": 0 },
"refunds": { "count": 0, "pct": 0 },
"revenue_recovery_rate_pct": 0,
"output_file": "exchange_refund_ratio_<date>.csv"
}Output Format
CSV file exchange_refund_ratio_<YYYY-MM-DD>.csv with columns: return_id, order_name, resolution_type, exchange_sku, refund_amount, currency, created_at
Error Handling
| Error | Cause | Recovery |
|---|---|---|
THROTTLED | API rate limit exceeded | Wait 2 seconds, retry up to 3 times |
| No resolved returns in window | No completed returns in period | Exit with summary: 0 returns |
| Exchange line items empty but status indicates exchange | In-progress exchange | Count as pending, exclude from ratio |
Best Practices
- A revenue recovery rate above 30% (exchanges + store credit) is generally a strong signal for fashion/apparel; set your own benchmark based on category.
- Use
compare_days_backto track whether returns policy changes (e.g., "exchange only" periods) improved the recovery rate. - Pair with
return-reason-analysis— high "wrong size" return reasons paired with low exchange rates may indicate size guidance issues in product listings. - Run before and after launching an exchange incentive (e.g., bonus store credit for exchanging instead of refunding) to measure impact.
Related skills
FAQ
Can it compare two time periods?
Yes. Set compare_days_back to a non-zero value to compute a prior-period comparison and trend.
How does it classify a resolution?
A return with exchangeLineItems is an exchange, a gift-card/store-credit refund is store credit, and a cash/card refund with no exchange is a refund.