The numerator and denominator must describe the same population. If the denominator is units of a SKU sold in January, the numerator should be returned units from those January sales, observed over a defined period.

“By SKU” should usually mean the variant-level SKU stored at the time of sale. That matters when a product has different sizes or colors with very different outcomes. Shopify notes that SKUs are case-sensitive and that a SKU added after an order was placed does not appear retroactively in historical reporting.

The January point stays at 12% even if several of its returned units were physically received in February. The return event is attached to the January sale cohort because January produced both the sold units and the later returns.

The March point should not be compared until every included order has had the full 30-day observation window. Showing it early can make the product look artificially healthy.

A finite window answers a precise question: what share of sold units came back within 14, 30, 45, 60, or 90 days? A lifetime-to-date view instead counts all attributed returns observed as of today.

• Match the window to the merchant's actual return policy and typical processing delay.
• Use the same window for every cohort in a trend comparison.
• Hide or visibly flag finite-window cohorts that have not matured.
• Label a lifetime result “as of today” because it can still change.

Shopify return rules can begin from delivery and use preset or custom durations. Your measurement window should therefore be explicit, not assumed from a calendar month.

A physical return and a refund are related, but they are not the same event. A returned item can exist without an immediate refund, and a refund can be issued without a physical item coming back.

• Count a return without a refund when reliable item-level return evidence exists.
• Count a refund without a physical return only when it is clearly attributable to a SKU and your business definition includes it.
• When both records refer to the same line item, count the returned unit once.
• Track unattributed partial refunds separately from the main SKU numerator.
• Define exchanges consistently so the returned side is counted once and the replacement is not mistaken for another return.

• Dividing returns processed this month by units sold this month.
• Counting a return record and its related refund as two returned units.
• Mixing physical returns with every cancellation, order edit, and sales reversal.
• Treating an in-progress return request as a completed return without documenting the choice.
• Comparing cohorts with different observation windows.
• Treating the newest month as complete before its return window has elapsed.
• Ignoring missing or reused SKUs that prevent reliable variant-level attribution.

Should I use order return rate or unit return rate?

Use unit return rate for SKU analysis. An order can contain several products, so an order-level rate cannot tell you which SKU produced the return.

Can a true unit-level cohort return rate exceed 100%?

A correctly deduplicated rate for the same population should not exceed 100%. If it does, investigate duplicated events, quantity attribution, exchanges, and denominator completeness.

Why does my monthly report still look strange?

Read why Shopify return rates can look wrong for the processing-month explanation, then work through the return leakage checklist.