How to tell if an outlier is a data error or a real signal
Treat an outlier as a question, not a deletion instruction. Verify source history and units, compare the value with domain constraints and peer groups, inspect related fields and time context, reproduce the calculation, and classify it as error, rare valid event, structural change, or unresolved. Apply corrections only with evidence and keep the original plus the decision trail.
Why the obvious method fails
Automatic outlier rules flag expected enterprise accounts, promotions, outages, seasonal peaks, and regime changes alongside decimal mistakes and duplicate joins. Removing them can erase the most important business events.
Detection and diagnosis are separate
A detector answers which values deserve attention. Diagnosis answers why they differ and what should happen. Combining the two encourages automatic deletion based on a threshold.
Robust statistics reduce sensitivity to skew, but domain context remains essential.
Use multivariate context
A revenue spike with matching units, orders, and campaign activity may be real. Revenue alone rising while all driver fields remain flat suggests a unit, formula, or duplication issue.
Time context can reveal regime shifts that should be modeled separately rather than capped away.
A useful mental model
- Statistical extremeness does not prove a data error.
- Compare within relevant peer groups and time regimes.
- Check units, joins, duplicated events, and derived calculations first.
- Preserve valid extremes and document any treatment.
From the field · Sports performance coach
Decide whether an athlete's performance spike is real
A GPS export shows one athlete running much faster than their previous best. The value could reflect genuine progress, a shortened course, a unit change, a device dropout, or an incorrectly assigned athlete ID.
Columns used in the example
athlete_id · session_id · timestamp · distance · duration · pace · device_id · course
Follow it with your own file
- Check units, derived formulas, device status, course length, and source assignment.
- Compare neighboring timestamps and independent timing evidence.
- Review the athlete's history and peer distribution without deleting the point.
- Classify it as confirmed signal, corrected error, excluded with reason, or unresolved.
Check: Any correction must preserve the raw observation and its reason. Recalculate summaries with and without the point and record whether the decision conclusion changes.
Outlier treatments and their risks
| Treatment | Use when | Risk |
|---|---|---|
| Correct | Source error is proven | Replacing with an assumed value |
| Retain and flag | Rare event is valid | Downstream models may need robustness |
| Cap or transform | Model objective justifies it | Hides business magnitude |
| Exclude | Scope rule is explicit | Biased results if applied after seeing outcome |
Patterns that need context
- An extreme begins after a source-system change.
- The value is plausible but unusual for its global distribution.
- Several related measures move together.
- The outlier disappears when duplicated join rows are fixed.
A method you can follow
- Detect robustly: Use IQR, median absolute deviation, percentiles, and peer-group rules rather than one global standard-deviation threshold.
- Verify lineage and mechanics: Trace source row, units, parsing, formulas, aggregations, and join number of unique values.
- Add business context: Compare peers, calendar events, operational incidents, caps, and known constraints.
- Classify and treat: Correct proven errors, retain valid events, model structural changes, and leave unresolved cases flagged.
Doing these steps in Prepyr
Prepyr accepts CSV files only. Export the worksheet or table you need as a UTF-8 CSV first; workbook formulas, formatting, macros, charts, and other sheets will not be included. Describe the result you need: Investigate whether an outlier is a data error or a genuine operational signal. Check the columns selected, preview any proposed changes, and compare the output with the source before applying or exporting it.
Prepyr steps used here: Outlier detection · Row lineage · Version history · Changed Row review
What to verify before acting
- Source row traceable
- Units verified
- Join multiplicity checked
- Peer group appropriate
- Related fields inspected
- Treatment reversible
An anomaly register that protects rare but valid events, corrects proven defects, and separates unexplained observations from confident conclusions.
Questions readers usually ask next
Should I remove values beyond 3 standard deviations?
Not automatically. That rule assumes a suitable distribution and no meaningful rare events.
What is the safest default treatment?
Retain and flag while investigating; preserve the original even after a correction.
Can an outlier indicate a trend?
A sequence of unusual points may signal a new regime rather than isolated anomalies.