Detecting Return Spikes Before They Cost You

By the time a monthly return rate report shows a problem, the batch has shipped, the season has turned and the money is gone. Return data is inherently lagged: an item sold today comes back in three weeks, which means the signal you are watching describes decisions customers made a month ago.

Useful detection accepts that lag and works around it, rather than pretending a faster dashboard makes the underlying delay disappear.

The Denominator Problem

The most common mistake in spike detection is dividing today's returns by today's orders. Those two numbers describe different cohorts. If sales doubled last week, today's ratio falls even when nothing improved; if a promotion ended, the ratio spikes without any change in product quality.

The correct denominator is the cohort that the returns came from. Measure returns from orders placed in a given week as a share of that week's orders, and let the number mature over the return window. This is slower and it is the only version that means anything, which is the same argument made in cohort analysis of returners.

Watch Leading Indicators, Not the Rate

Because the rate is lagged, the practical answer is to alert on things that move earlier. Support contacts mentioning a product move within hours. Return initiations in the portal move days before the parcel arrives. First-scan events tell you a return is in flight before your warehouse sees it.

None of these are the return rate, and that is the point. They are correlated enough to justify a look and fast enough to matter. Merchants already capturing first-scan events have the cheapest of these signals available with no additional instrumentation.

Alert on Rate of Change, Not on Level

A fixed threshold produces alerts on every high-return category permanently and never fires on the category that quietly doubled from a low base. Swimwear at thirty percent is normal; a homeware SKU going from two percent to six percent is an emergency that no absolute threshold will catch.

Detect on relative change against the item's own history, with a minimum volume floor so small numbers do not generate noise. The statistical methods here are ordinary process control rather than anything exotic, and the reference literature on measurement and control published by bodies such as NIST is more than sufficient grounding.

• Compare each SKU against its own baseline, never against a global threshold.
• Set a minimum unit volume before an alert can fire.
• Alert on reason-mix change as well as on rate change.
• Route alerts to the person who can act, not to a shared dashboard nobody opens.
• Record every alert outcome; an alert nobody actioned is a tuning problem.

Alerting on a high return rate tells you about swimwear. Alerting on a changed return rate tells you about a problem.

Distinguish the Four Causes

A spike has a small number of possible explanations, and separating them determines who gets the ticket. A quality change affects one SKU across all channels. A fulfilment error affects orders picked in one window or one location. A listing error affects one channel or one locale. And a demand-mix change affects nothing about the product at all: you simply sold to a different population.

Building the alert so that it carries the breakdown by channel, location and time window turns a notification into a diagnosis. Without it, every alert starts with the same twenty minutes of manual slicing, which is why most alerting programmes are abandoned within a quarter. The dimensions needed are the ones already present in return rate root cause attribution.

The New Product Exception

New products have no baseline, which is exactly when detection matters most because a bad first batch can consume an entire season. The workable substitute is a category baseline and a deliberately tighter early window: for the first few hundred units, compare against similar products rather than against the item's own non-existent history.

This is also the moment when comment labels outperform reason codes, because a genuinely new defect will not have a matching dropdown option yet and will land in free text first. Pairing early-window monitoring with the text signal described in clustering return comments is the fastest warning available on a launch.