SQL, data modeling, data quality, EDA, visualization · insight-0059
Classify an outlier as error, rare truth or regime change before deciding what to do with it
- Evidence type
- documented fact
- Difficulty
- medium
- Roles
- Data scientist, Data analyst
- Industries
- aviation, retail, manufacturing
Summary: situation, action, reason, boundary
Situation
One flight shows ten times its usual passengers, or one day's sales are far above every previous day.
Action
Check physical limits and related fields first (passengers versus capacity, revenue versus fare times passengers), then the event calendar and the source system. Correct or remove proven errors, keep rare truths and model them, and treat sustained shifts as a structural break.
Reason
Statistical outlier tests flag points for investigation; they cannot say whether a point is wrong, and they assume a distribution the data may not follow.
Boundary
EDA, data-quality rules, training-data cleaning and KPI monitoring.
Symptom or risk
Deleting real extremes hides risk and demand peaks; keeping errors corrupts means, variances and models.
Exceptions
Automated pipelines at scale may need rule-based quarantine first and review later.
Trade-offs
Investigation costs analyst time; robust methods reduce the impact while you investigate.
Pitfalls
Removing values beyond 3 standard deviations on heavy-tailed data, which deletes legitimate high-value customers.
Example
Synthetic airline data: flight_day_raw contains one passengers value about 10x normal; comparing it with that flight's capacity is the first check.
Lessons and concepts
Claims and their sources
An outlier that cannot be shown to be bad data should not simply be deleted; outlier tests assume approximate normality, and labelling points for investigation is distinct from formal identification.