Outlier handling: rules before results

Retail data contains implausible values: a store-week with ten times normal volume, a price of zero, a negative unit count from a mishandled return. Some are errors, some are real events, and the difference is not always visible in the data.

How they are handled changes results, which is why the rule has to be written before the result is seen.

Why does the ordering matter so much?

Because an outlier rule chosen after the analysis is a way of choosing the answer. Removing the observations that contradict a conclusion is indistinguishable, in the output, from removing the observations that were errors.

Writing the rule first removes that discretion. It also makes the analysis reproducible, which is the property that lets somebody else check it.

What kinds of outlier occur?

Data errors: a decimal misplaced, a duplicated file, a unit-of-measure mismatch. Operational events: a store that hosted an event, a bulk purchase, a supply interruption. And genuine extremes: a real week that was simply exceptional.

The response differs by kind. Errors should be corrected or removed; operational events should be flagged and kept; genuine extremes should usually be kept, because removing them removes the phenomenon.

How do you tell them apart?

By looking, which is the part no rule replaces. A flagged value should be traced back — to a store, a week, an item — and explained where possible. An outlier with a known cause is information; one with no explanation is a risk.

Automated rules identify candidates. People decide, and the decision should be recorded.

What rules are defensible?

Ones stated in advance with a reason. A cap at a stated multiple of a store's own median, exclusion of negative values with a documented treatment for returns, and a review threshold above which a human looks. Any of those is defensible; the indefensible version is "we removed the ones that looked wrong."

Document the count. A rule that removes a trivial fraction is unremarkable; one that removes a large share is a finding about the data, not a cleaning step.

What about winsorising and trimming?

Both are standard: trimming removes extreme observations, winsorising caps them at a percentile. Each changes the result and each is legitimate when stated.

What is not legitimate is applying them silently. A mean computed after trimming is a trimmed mean and should be labelled as one.

How does this interact with aggregation?

Outliers at store level can wash out in a market total and still matter for a store-level analysis. A rule appropriate for one level may be wrong at another, so the rule belongs to the analysis rather than to the dataset.

That is why a cleaned dataset with no record of what was cleaned is a problem. The next analyst inherits decisions they cannot see.

What should be reported?

The rule, the number of observations affected, and whether results are sensitive to it. The sensitivity check is the useful part: running the analysis with and without the rule and reporting both takes minutes and settles the question.

If the conclusion changes when the rule changes, the conclusion is about the rule.