All articles
IntelligenceAug 2, 2026 · 7 min

Attributing Return Rate to Root Causes

DA
Defne Aksoy
Head of Product

Our return rate is twenty-eight percent is a symptom, not a diagnosis. It tells you how much is coming back and nothing about why, and you cannot fix a number you cannot decompose. Every merchant with a returns problem has heard the headline rate quoted in a meeting, watched everyone nod gravely, and then watched nothing change, because a blended percentage gives no one an action. Attribution is the discipline that turns that dead number into a work list: it splits one aggregate rate into named causes, and it assigns each cause to a team that can actually move it. Without attribution you are managing a thermometer; with it you are managing a set of specific, ownable problems.

The mechanics are less complicated than the politics. Technically, attribution means classifying every return into a small set of root causes using structured reason data, then rolling those causes up to see where the volume concentrates. Organizationally, it means naming an owner for each cause, which is the part that makes people uncomfortable, because a return attributed to no one is a return fixed by no one. This piece covers the causes worth separating, why the reason taxonomy underneath them is the whole game, and how to assign ownership so attribution produces fixes instead of a nicer-looking dashboard.

The five root causes worth separating

Most returns resolve into five root causes, and the reason to keep them distinct is that each one has a different owner and a different fix. Lumping them together as generic returns is what keeps a return rate stuck, because the interventions for a fit problem and a supplier-quality problem share almost nothing. The table maps each cause to the signal that identifies it, the team that owns it, and the fix that actually moves it.

Root causeSignal that identifies itOwnerTypical fix
Fit and sizingReason code too small or too large; clustering by sizeProduct and merchandisingSize chart, per-product fit notes, size recommendation
Quality and defectReason defective; a SKU-level spike or supplier batchSupplier and QASupplier scorecard, incoming inspection
Expectation gapNot as described or material felt cheapPDP and contentBetter imagery, fabric detail, scale references
Damage in transitArrived damaged, correlated to carrier or laneLogistics and packagingPackaging redesign, carrier review
Delivery and fulfillmentWrong item, or arrived too lateWarehouse and operationsPick accuracy, delivery SLA

The single most valuable split in that table is fit versus expectation gap, because they look similar in raw complaints and demand opposite fixes. A fit return means the product is fine but the size guidance failed, and it is owned by whoever controls sizing. An expectation-gap return means the size was right but the product did not match what the listing promised, and it is owned by whoever controls the product page. Conflate them and you will redesign a size chart to fix a photography problem. Getting the split right depends entirely on the quality of your reason codes, which is why taxonomy design comes first, as we cover in return-reason taxonomy design.

The taxonomy is the whole game

Attribution is only ever as good as the reason data feeding it, and this is where most programs quietly fail. Free-text return reasons are unusable at scale, because too small, runs small, and sizing off are the same cause wearing three different phrasings, and no rollup can group them reliably. A structured, two-tier taxonomy, a top-level cause plus a specific sub-reason, is the input that makes attribution possible at all. It is worth remembering that a large share of expectation-gap returns trace back to the product page itself, and detailed page-experience research from groups such as the Baymard Institute has long documented how missing detail, poor imagery, and thin specifications drive both failed purchases and the returns that follow. Feed that structured reason data into merchandising analysis, as we detail in product return analytics for merchandising, and the expectation-gap cause resolves from a vague complaint into a specific list of pages to fix.

A return rate without attribution is a thermometer. A return rate broken into owned causes is a work list. Only one of them ever gets shorter.

Assigning owners is the hard part

The data work is the easy half; the accountability work is where attribution programs live or die. A cause with no named owner is a cause nobody fixes, no matter how cleanly your dashboard displays it, because the return rate is everybody's problem in the abstract and therefore nobody's problem in practice. The discipline is to attach each root cause to a specific team and a specific metric that team is measured on. Fit-driven returns become a number the merchandising team owns. Defect returns become a number the supplier-quality team owns, ideally reflected in a supplier scorecard so the cost flows back to its source. Expectation-gap returns become a number the content team owns. When each cause has an owner who sees it on their own scorecard, the attribution stops being an interesting report and starts being pressure applied at the right place.

Closing the loop into a flywheel

Attribution is not a one-time analysis; it is the input to a loop that compounds. Each resolved return produces a structured reason and a graded condition, that data sharpens the attribution, the sharper attribution drives a more precise fix, and the fix reduces the next cohort of returns for that cause, a cycle we describe in returns as a data flywheel. This is where ResReturn's structured return reasons and condition grading feed directly into attribution: because the reason is captured as structured data at intake and the item's condition is graded on receipt, the same event that resolves a customer's return also files a clean data point against the right root cause and the right owner. The return you process today becomes the evidence that lowers next quarter's rate, but only if the reason it happened was captured cleanly enough to attribute.

  • Resolve every return into one of five root causes: fit, quality, expectation gap, damage, or delivery, because each has a different owner and fix.
  • Guard the fit-versus-expectation split; the first is a sizing problem, the second is a product-page problem, and they demand opposite work.
  • Build a structured, two-tier reason taxonomy first; free-text reasons cannot be attributed reliably at scale.
  • Give every root cause a named owner and a metric on their scorecard, or the cause stays everyone's problem and nobody's job.
  • Feed structured reasons and graded condition back into attribution, so each processed return sharpens the next quarter's fix.
What does it mean to attribute a return rate to root causes?

It means splitting one blended return rate into the specific reasons behind it, such as fit, quality defects, expectation gaps, transit damage, and fulfillment errors, then assigning each reason to the team that can fix it. A headline rate gives no one an action; an attributed rate gives each owner a specific, measurable problem to reduce.

Why separate fit returns from expectation-gap returns?

Because they look alike in raw complaints but need opposite fixes. A fit return means the product is fine and the size guidance failed, owned by merchandising. An expectation-gap return means the size was right but the listing oversold the product, owned by the content or PDP team. Conflating them leads you to fix a size chart when the real problem is photography, or the reverse.

Do I need structured reason codes to do attribution?

Effectively, yes. Free-text reasons cannot be grouped reliably at scale, because the same cause appears in many phrasings and no rollup can reconcile them. A structured, two-tier taxonomy of a top-level cause plus a specific sub-reason is the minimum input that makes attribution accurate rather than a guess dressed up as a chart.

How do I make attribution actually reduce returns?

Give every root cause a named owner and put that cause on the owner's scorecard, so it becomes their measured responsibility rather than a shared abstraction. Then close the loop: feed structured reasons and graded condition back into the analysis so each resolved return sharpens the next fix. Attribution without ownership produces a nicer dashboard and the same return rate.

See it on your own returns.

Start free