RETURNS · DATA · ANALYTICS · 17 FEBRUARY 2026 · 6 MIN READ

Returns data is product data

A return is a customer telling you what was wrong with a specific variant, at their own expense. Most stores file that under logistics and never let it reach the people who buy and describe the products.

A quarter of work on a board, the week in progress marked

Which products are described wrongly, sized wrongly, photographed wrongly, or made badly — and which are simply bought on approval. Every return carries a reason, a variant, a date and a note, and Shopify stores all four against the original fulfilled line item. Joined to units sold, that gives you a return rate per variant with a cause attached, which is the closest thing in ecommerce to a defect report from a paying customer. Most stores never make the join, because returns reporting is owned by operations and the decisions it should inform — buying, copy, photography, size charts, delisting — are owned by everyone else.

IN SHORT

A return rate is only readable per variant and normalised by units sold; ranked by raw count it will simply list your bestsellers.
Shopify records a standardised return reason, a free-text reason note of up to 255 characters, and a separate customer note of up to 300 characters describing the item.
The `returnReason` enum is deprecated in the Admin GraphQL API in favour of `returnReasonDefinition`, which exposes a stable `handle` and a localised `name` from an expanded Shopify-maintained taxonomy.
Size too large and size too small are separate reasons, so a consistent skew in one direction is a size chart fix while an even spread is a fit or consistency problem.
The reverse fulfillment disposition — restocked, not restocked, missing, or processing required — is what turns a return count into a cost per variant.
The useful unit of analysis is the variant and the batch, not the product: one colourway or one production run usually carries the problem.
Nobody needs to buy a returns analytics product to do this. The data is in the Admin API and the join is a spreadsheet.

Two reports, and the missing join

Almost every store has returns reporting of some kind. It answers operational questions: how many returns came in this month, how long they take to process, what they cost in labour and postage, whether the queue is growing. It is owned by whoever runs fulfilment, and it is read by whoever runs fulfilment.

Separately, almost every store has merchandising reporting: units sold, sell-through, margin, what to reorder. It is owned by buying and trading.

The interesting information lives in the join, and the join is usually nobody’s job. A return is an event that names a variant, a reason, a date and a customer’s own description of what was wrong. Attach it to the sales data for that variant and you have a per-variant defect rate with a cause. Leave it in the operations report and you have a queue length.

This is not an analytics tooling problem. The data is already structured, already in the Admin API, and already joinable by the product variant that both sides key on. What is missing is a monthly hour and a named person.

What Shopify records against a return, field by field

Worth reading the schema before deciding you need a platform to give you the data, because more of it is there than most merchants use. In the Admin GraphQL API, a Return belongs to an Order and holds returnLineItems, each of which carries:

A standardised reason. returnReasonDefinition gives a stable handle and a localised, user-facing name, drawn from what Shopify describes as an expanded library of return reasons available to all merchants. The older returnReason enum field — the fixed set of colour, defective, not as described, size too large, size too small, style, unwanted, wrong item, unknown and other — is marked deprecated in favour of it. If your reporting keys on the enum, that is a thing to migrate before it becomes a thing to fix.
A reason note, returnReasonNote, up to 255 characters, described as additional information about the reason for the return.
A customer note, customerNote, up to 300 characters, described as a note from the customer that describes the item to be returned. This is separate from the reason note and it is the one written in the buyer’s own words.
The original fulfilled line item. fulfillmentLineItem links back to what actually shipped, which is what makes the join to the variant, the order date and the sales data possible at all.
Quantities at every stage — returned, processable, processed, unprocessed, refundable, refunded — so a return in progress is distinguishable from a return completed.
A restocking fee, per line item, where one applies.
Timestamps on the return itself — createdAt, requestApprovedAt and closedAt — from which the time a return spends waiting is arithmetic rather than a guess.

Reading the reasons as instructions to specific people

A reason code is only useful if it routes to an owner. The standardised vocabulary makes that routing mechanical, which is the whole point of having a closed set rather than a text box.

Size too large and size too small are separate values, and the split is the diagnosis. Returns skewed to one direction are a size chart and copy problem with a cheap fix: change the guidance, or state plainly that the item runs small. Returns spread evenly across both directions are a different thing entirely — either the fit is genuinely difficult to communicate, or the manufacturing is inconsistent between units. The first is a content brief. The second is a conversation with a supplier.

Not as described and colour are photography and copy. They are the cheapest returns to remove and the most commonly ignored, because the fix belongs to marketing and the cost lands on operations. A variant returning repeatedly for colour usually has one photograph doing too much work under one lighting setup.

Defective is quality control, and it wants a date range. Group these by order date rather than by product and you will often find them clustered — one production run, one shipment, one packaging change. A defect rate spread evenly across a year is a design problem; a defect rate concentrated in six weeks is a batch, and the supplier conversation is a specific one rather than a general complaint.

Wrong item is a pick-and-pack failure, not a product failure, and it belongs to the warehouse or the 3PL. It is worth separating from the rest before anyone draws conclusions about the catalogue.

Unwanted is the floor. Some proportion of what you sell is bought on approval and knowing which part of your return rate is that is as valuable as the rest, because it is the part no content change will move.

One caution that undermines all of the above if you ignore it: the reason is chosen by whoever creates the return, and if your agents default to whatever is quickest, the vocabulary degrades into a single value that means nothing. Audit a sample against the customer notes once a quarter. If the reason and the note disagree often, fix the agent guidance before you trust a single chart.

Disposition is where a return count becomes a cost

A returned unit is not a recovered unit. Shopify tracks what happened to the goods through the reverse fulfillment order, and the disposition types are a short, honest list: restocked, not restocked, missing, and processing required — that last one meaning an item needing further work before it can be restocked or discarded.

That distinction is what turns a returns report into a financial one. Two variants with the same return rate are not equally expensive if one comes back sellable and the other comes back as NOT_RESTOCKED. A product with a modest return rate and near-total write-off can easily be worse than a high-return product that goes straight back on the shelf — and the raw return count, which is what most dashboards show, cannot tell them apart.

The same field settles arguments about packaging. If returns of a fragile item disproportionately arrive not restockable, the problem may be the return journey rather than the product, and the cheapest intervention is a better returns label and a line of instruction in the box.

Normalise it, or you will just rank your bestsellers

The single most common way this analysis goes wrong is ranking variants by number of returns. That produces a list of the things you sell most of, which you already had.

The figure that means something is returns as a proportion of units sold, per variant, over a window long enough that the denominator is not tiny. A variant that sold eleven units and had two returned is noise; treat it as a signal and you will delist something that was fine. Set a minimum volume before a variant enters the ranking at all, and be honest that below it you are reading anecdotes.

Two refinements are worth the effort once the basic rate exists. Cohort by order date, so a change to the product page, the size chart or the supplier has a before and an after rather than a blended average that hides both. And hold the window open long enough — a return raised near the end of your return window against an order placed weeks earlier will make a recent cohort look better than it is, so compare like-aged cohorts or wait for the window to close before judging.

There is also a shipping-back-and-forth cost per return that varies by destination and weight, and a labour cost per return that varies by disposition. Neither needs to be precise. A rough cost per return applied consistently is enough to rank products by what they cost you, which is the ranking that gets a delisting decision made.

What we would talk you out of

Buying returns analytics as a product. Returns platforms sell dashboards and the dashboards are fine, but the analysis above is a query against data you already own and a join to sales data the platform does not have. If the case for buying rests on the reporting rather than on automated approval or multi-region labels, the reporting is not what you are short of — the monthly hour is.

Treating the return rate as the target. It can be driven to zero by making returns difficult, which raises support volume, kills repeat purchase and does not fix a single product. The target is the cause, and the measure of success is the return rate falling for the variants you actually changed.

Analysing at product level. Most return problems belong to one variant, one colourway or one production run. Aggregate to the product and you will average a genuine problem into invisibility.

The honest summary: returns data is the only feedback channel where a customer pays postage and spends their own time to tell you something specific about a specific thing you sold them. Reading it monthly and routing it to buying, content and QC is a cheap habit with no software attached. If you would like the join built once and handed over as a report someone can actually read — rather than another dashboard — that is the kind of work our [Shopify support and store management](/services/support) engagements cover.

Questions this raises

What can returns data tell you about your products?

Which variants are described, sized or photographed wrongly, which are badly made, and which are simply bought on approval. Each return carries a standardised reason, the original fulfilled line item and a customer note, so joined to units sold it gives you a per-variant return rate with a cause attached — the closest thing ecommerce has to a defect report from a paying customer.

How do you calculate a return rate properly?

Returns as a proportion of units sold, per variant, over a window long enough that the denominator is meaningful — and with a minimum volume threshold below which a variant does not enter the ranking. Ranking by raw return count simply lists your bestsellers. Cohort by order date if you want to see whether a change worked.

Where does Shopify store return reasons?

On the return line item in the Admin GraphQL API. `returnReasonDefinition` provides a stable handle and a localised name from Shopify’s return reason taxonomy, alongside a `returnReasonNote` of up to 255 characters and a separate `customerNote` of up to 300 characters written by the buyer. The older `returnReason` enum field is deprecated in favour of the definition object.

What does the reverse fulfillment disposition tell you?

What happened to the goods. The types are restocked, not restocked, missing, and processing required — an item needing further work before it can be restocked or discarded. It is the field that turns a return count into a cost, because two variants with the same return rate are not equally expensive if one comes back sellable and the other does not.

Do you need a returns platform to analyse returns?

No. The reasons, notes, quantities, dispositions and timestamps are all in the Admin API, and the join to sales data is a spreadsheet. Buy a platform for automated approval, multi-region labels or routing across warehouses if you need those. Buying one for the reporting usually means paying a subscription to avoid scheduling an hour a month.

How do you spot a manufacturing problem in returns data?

Group defective returns by order date rather than by product. A defect rate spread evenly across a year points at the design; one concentrated in a few weeks points at a batch, a shipment or a packaging change — which makes the supplier conversation a specific one with dates attached rather than a general complaint.

Free store audit

A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.

GET THE AUDIT