Tutorials › Introduction to Statistics › An Outlier Flag Is Not Proof of Bad Data

Comparing Groups and Handling Outliers · Tutorial 188 of 996

An Outlier Flag Is Not Proof of Bad Data

Learn how to check the source and context of a flagged value, then report it without confusing statistical unusualness with bad data.

Beginner 9 min read

What You'll Learn

  • Distinguish a 1.5-IQR flag from a confirmed data error
  • Recognize what the outlier rule can and cannot establish
  • Check an unusual value against its context and original records
  • Decide whether a value is a verified extreme, a confirmed error, or unresolved
  • Report a flagged observation transparently without silently deleting it

What an Outlier Flag Tells You

The 1.5-IQR rule identifies observations that lie unusually far from the middle half of a data set. That makes a flag useful: it draws attention to a value worth examining. But the rule only uses the numerical arrangement of the recorded data. It does not know how a value was measured, entered, or produced. A value can be genuinely unusual and accurately recorded; a value can also be an error without crossing either fence.

This distinction matters whenever a summary or comparison is based on recorded measurements. Removing a valid extreme changes the account of what was observed. Keeping an incorrect value as if it were valid can also mislead. The appropriate decision comes from checking the value against its context and source, not from the flag alone.

Definition: For a quantitative data set, let \(Q_1\) and \(Q_3\) be its first and third quartiles, and let \(IQR=Q_3-Q_1\). The 1.5-IQR fences are \(Q_1-1.5(IQR)\) and \(Q_3+1.5(IQR)\). A recorded value below the lower fence or above the upper fence is flagged by the rule. A flag describes its position relative to the data; it does not establish that the value is erroneous.

The rule is a descriptive screening convention, not a test of whether an observation is correct. It does not calculate the probability that a value is an error, and it does not say that an observation beyond a fence must be excluded. Conversely, a value inside the fences is not guaranteed to be correct. An extra zero, a misplaced decimal point, or a unit mistake might produce a value that is not flagged, depending on the rest of the data.

Check the Observation, Not Just Its Position

A useful check begins with the meaning and units of the variable. Ask whether the value could occur in the setting, whether it is consistent with the way the quantity was measured, and whether anything about the record suggests a transcription or coding mistake. “It seems surprising” is a reason to investigate, not enough evidence to change the data.

If possible, compare the data entry with its source: a paper form, instrument output, database field, or contemporaneous log. Check that the correct person or item is attached to the value, that the decimal and units were transferred correctly, and that the value has not been copied into the wrong variable. When appropriate, a repeat measurement or an independent record may help. Each check must be interpreted in context: a repeat measurement can differ from the first because the quantity genuinely changed or because measurement itself varies.

1
Identify the flag.
Record which value is outside a fence and confirm the variable’s units and the data used to calculate the quartiles.
2
Check context.
Consider what the variable measures and whether a value of this size is possible or plausible in the setting. Plausibility alone does not prove correctness or error.
3
Check the source.
Compare the recorded value with available original records, identifiers, units, and measurement notes. Correct it only when there is evidence supporting a correction.
4
State what is known.
Classify the observation as a confirmed error, a verified unusual value, or unresolved, and report the flag and the evidence relevant to that decision.

These categories describe the evidence available, not permanent labels attached to a person or measurement. A confirmed error is supported by a source check showing that the recorded entry does not represent the intended observation. A verified unusual value has been checked and is supported as an accurate observation, even if it is rare or extreme. An unresolved value lacks enough evidence to decide between those possibilities. Keep the distinction visible in any analysis or report.

Worked Examples

Worked Example: A Confirmed Data-Entry Error

A hypothetical clinic records the number of minutes each of eight patients waited. The values are \(12, 13, 14, 14, 15, 16, 17,\) and \(31\) minutes. Using the median-of-halves convention, the lower half is \(12, 13, 14, 14\) and the upper half is \(15, 16, 17, 31\).

The quartiles are the medians of these halves:

$$ Q_1=\frac{13+14}{2}=13.5,\qquad Q_3=\frac{16+17}{2}=16.5 $$

Therefore,

$$ IQR=16.5-13.5=3,\qquad \text{upper fence}=16.5+1.5(3)=21 $$

The value \(31\) minutes is above the upper fence of \(21\) minutes, so it is flagged. The researcher then checks the original time sheet: the entry for this patient reads \(13\), but the value transferred to the data file is \(31\). The source supports a correction from \(31\) to \(13\) minutes. The reason for correcting the entry is the source record, not the fact that \(31\) crossed the fence. The correction should be documented so the recorded data and analysis can be traced.

Worked Example: A Verified Unusual Observation

A hypothetical weather station records daily rainfall, in millimeters, over eight selected days: \(0, 1, 2, 2, 3, 4, 5,\) and \(28\). The lower half is \(0, 1, 2, 2\), and the upper half is \(3, 4, 5, 28\). Thus,

$$ Q_1=\frac{1+2}{2}=1.5,\qquad Q_3=\frac{4+5}{2}=4.5,\qquad IQR=4.5-1.5=3 $$

The upper fence is

$$ Q_3+1.5(IQR)=4.5+1.5(3)=9\text{ mm} $$

The observation of \(28\) mm is above \(9\) mm and is flagged. In this hypothetical case, the station’s original gauge log also records \(28\) mm for the correct date, and a maintenance note does not identify a measurement problem. The source check supports treating \(28\) mm as an unusual recorded rainfall amount, not as an entry error. It should remain in the data, with its unusual status described where relevant. The flag alone did not verify it; the source check supplied the relevant evidence.

Worked Example: A Flag With Insufficient Source Evidence

A hypothetical service records the waiting times, in minutes, of eight visitors: \(8, 9, 9, 10, 10, 11, 12,\) and \(58\). The lower half is \(8, 9, 9, 10\), and the upper half is \(10, 11, 12, 58\). The quartiles and spread are

$$ Q_1=\frac{9+9}{2}=9,\qquad Q_3=\frac{11+12}{2}=11.5,\qquad IQR=11.5-9=2.5 $$

The upper fence is

$$ 11.5+1.5(2.5)=15.25\text{ minutes} $$

The \(58\)-minute value is flagged. A wait of \(58\) minutes is possible in this setting, but the original intake sheet and timestamp are no longer available. The remaining record does not establish whether \(58\) is correct or was entered in error. The appropriate conclusion is that the observation is flagged and unresolved. Calling it an error would go beyond the evidence, while describing it as verified would do the same. Report the uncertainty rather than silently changing or omitting the value.

Why the Flag Cannot Decide

The reason can be seen by separating two questions. The fence calculation asks, “Where does this number sit relative to the middle half of these recorded values?” A source check asks, “Does this recorded number accurately represent the intended observation?” These questions use different information. The first can be answered using the data values; the second requires information about measurement, recording, or context.

For example, the same numerical value could be an accurately measured rare event in one setting and a transcription mistake in another. Its position relative to \(Q_1\) and \(Q_3\) would not reveal which story is true. Even a value that appears physically implausible should prompt a check of units, definitions, and the data source before it is changed. A mistaken unit conversion may be correctable; a genuinely extreme event may instead be what the observation captured.

A defensible correction is tied to evidence. If a source record clearly shows a transcription error, correct the entry and document the correction. If checks support the recorded value, retain it as an unusual observation. If the source is unavailable or conflicting, preserve the value as recorded and state that its status could not be resolved. These choices make clear both what the data show and what the checks were able to establish.

Common Mistake: Deleting Every Flag

Wrong reasoning: “The value is beyond the 1.5-IQR fence, so it must be bad data and should be removed.” This treats a screening rule as a test of data accuracy. It can discard a genuine observation and change the account of the data without evidence.

Correction: A flag identifies a value for review; it does not supply a reason for deletion. Check the context and available source records. If they confirm an error, correct it transparently. If they support the value, retain and describe it. If they do not settle the question, report it as unresolved rather than presenting a guess as a fact.

Key takeaway: “Flagged by the 1.5-IQR rule” is a statement about a value’s position in a distribution. “Data-entry error” is a claim about how the value was produced or recorded. The latter requires evidence beyond the fence calculation.

Check Your Understanding

For each question, distinguish what the outlier rule establishes from what would require additional evidence.

  1. A measurement lies above the upper 1.5-IQR fence. What does the flag establish, and what does it not establish?
  2. A flagged value is inconsistent with a handwritten source form, which clearly shows a different value for the same observation. What evidence supports changing the entry?
  3. A flagged rainfall measurement matches the station log. Should it be removed merely because it is unusual? Explain.
  4. A flagged waiting time is plausible, but the original records are missing. How should its status be described?
  5. Can an observation inside the fences still be a data-entry error? Give a brief reason.