Chapters

25 Imputation and Noise Filtering

analytics-ml
data
quality
imputation

25.1 Start With the Story

Repair a Gap Without Hiding It

Picture a cold-room chart with six missing minutes just before an alarm. The analyst can carry the last value forward, draw a line across the gap, or leave it empty. Each choice changes what a later manager may believe about the food and the fault.

Start with what the reading means. Record whether it is a level, count, switch event, or slow trend. Keep the raw row, gap start, gap end, repair rule, reason, and version beside the repaired result. Mark made values so they can never look like direct observations.

Test the rule on known gaps of different length and during fast change. Compare alerts made from raw and repaired data. Check delay, false alarms, missed alarms, and the result after a restart. A smooth line is not proof that the missing event never happened.

Keep any urgent local alarm based on evidence the device can still see. A later repair may support review or study, but it must not silently rewrite the record used for a safety action.

This opening does not choose one repair for every signal. Practitioner matches the rule to the meaning and the decision. Under the Hood examines noise shape, window choice, bias, model checks, and how each change affects later work.

Use a short release check. Is the raw gap still visible? Is each made value marked? Does the rule fit this kind of reading? Did the alarm change? Can another person run the same repair? If any answer is no, do not use the fixed series for a live choice.

Picture an IoT team using the ideas in Imputation and Noise Filtering during a live operations review. A device has produced messy evidence, an analytic step is about to change an alert or control decision, and someone has to explain why the result should be trusted.

Read this page as that path from sensor evidence to accountable action. Start with what the system observes, keep the model or data treatment visible, and finish with the check that would convince an operator, maintainer, or auditor to act.

25.2 Learning Objectives

By the end of this chapter, you will be able to:

  • Implement Missing Data Handling: Apply appropriate imputation strategies (forward-fill, interpolation, seasonal decomposition) for different sensor types
  • Compare Imputation Methods: Evaluate trade-offs between forward-fill, interpolation, and seasonal decomposition based on data characteristics
  • Design Noise Filters: Implement moving average, median, and exponential smoothing filters and assess their signal conditioning performance
  • Distinguish Strategy by Sensor Type: Justify the correct imputation and filtering approach based on sensor semantics and physical behavior

25.3 Imputation Filtering Check

In 60 Seconds

Missing and noisy sensor readings corrupt every downstream analysis, making data imputation (filling gaps) and filtering (smoothing noise) essential preprocessing steps before any IoT analytics pipeline can produce reliable results. The choice of imputation strategy — forward-fill, interpolation, or model-based — fundamentally affects anomaly detection sensitivity and ML model accuracy.

The mathematical gist. Sampling every 60 seconds means fs=1/60f_s=1/60 Hz and a Nyquist ceiling of 1/1201/120 Hz, so the fastest unaliased cycle lasts 120 seconds. A 90-second HVAC cycle would fold into a false 180-second trend before any imputation runs. Separately, a 12-bit ADC over 0–100% humidity has a 0.0244% step, 0.00705% RMS quantisation noise, and a 74.0 dB ideal SNR ceiling. Filling gaps cannot restore information acquisition never captured.

Math Bridge · guided foundationsWhat can no imputation method recover?Let Data Dora connect sample interval, aliasing, ADC steps, and the limits of gap filling.
Chapter Roadmap

This chapter has two jobs: repair missing values and quiet noisy values without hiding what happened.

  1. First you separate missing data from noisy data, then choose an imputation method that matches the sensor’s meaning.
  2. Then you compare forward-fill, linear interpolation, and seasonal fill using the simulators and gap calculators.
  3. Next you move from gap repair into filtering: moving average, median, exponential smoothing, and combined pipelines.
  4. After that you choose a strategy from the decision framework, including the correct order of validation before imputation.
  5. Finally you test the workflow with quizzes, a label diagram, and a code challenge.

Checkpoint callouts recap the main decisions. Longer calculators and worked examples are useful deep dives when you need the numbers, but you can skim them on a first pass.

25.4 Prerequisites

Before diving into this chapter, you should be familiar with:

Missing data and noise are inevitable in real IoT deployments. Sensors lose power, networks drop packets, and electronic noise corrupts readings. Rather than discard incomplete data, we can intelligently fill gaps and smooth noise.

Two key challenges:

ChallengeCauseSolution
Missing ValuesBattery death, network outage, sensor failureImputation (filling gaps)
Noisy SignalsElectrical interference, quantization, vibrationFiltering (smoothing)

Important distinction:

  • Missing: No data point received at all
  • Noisy: Data received but corrupted or fluctuating

Key question this chapter answers: “How do I fill gaps in sensor data and smooth out noise without losing important information?”

Imputation and Filtering Basics

Core Concept: Missing value imputation fills data gaps using neighboring or historical values, while noise filtering smooths random fluctuations to reveal the underlying signal - both must be matched to sensor semantics.

Why It Matters: Analytics and ML models require complete data series. Gaps cause errors or require discarding entire time windows. Noise obscures real patterns and triggers false alerts. Proper handling preserves data integrity while enabling downstream processing.

Key Takeaway: Match your strategy to sensor type - use forward-fill for slow-changing values (temperature), zero for event sensors (motion), and median filter for spike removal. Never interpolate binary/categorical data or forward-fill event streams.

25.5 Missing Value Imputation

  • ~10 min | - - Intermediate | - P10.C09.U04

The first half of the chapter is about deciding what a gap means. A missing temperature reading, a missing motion event, and a missing daily cycle do not deserve the same treatment.

Key Concepts

  • Missing data imputation: The process of estimating and filling in missing sensor readings using statistical or model-based methods rather than discarding incomplete records.
  • Forward-fill (Last Observation Carried Forward): An imputation strategy that replaces a missing value with the most recent valid reading — appropriate for slowly changing sensors but misleading for rapidly varying signals.
  • Linear interpolation: Estimating a missing value by drawing a straight line between the surrounding valid readings — appropriate for sensors with smooth, continuous dynamics.
  • Moving average filter: A signal smoothing technique that replaces each reading with the mean of a surrounding window, attenuating high-frequency noise at the cost of introducing lag.
  • Median filter: A non-linear filter that replaces each reading with the median of its window, highly effective at removing impulse noise (transient spikes) without distorting edges.
  • Missingness mechanism: The reason data is missing — Missing Completely at Random (MCAR), Missing at Random (MAR), or Missing Not at Random (MNAR) — which determines which imputation methods are statistically valid.
Data DoraCheckpoint: Gap Semantics

You now know:

  • Missing data means no point arrived; noisy data means a point arrived but may be corrupted.
  • A 30 second PIR outage can be filled as zero/no motion, but interpolation would invent a fractional event.
  • Forward-fill belongs with slowly changing signals; interpolation belongs with smooth trends; seasonal fill belongs with repeated patterns.

25.6 Forward Fill for Sensor Data

Best for slowly-changing values like temperature:

class ForwardFillImputer:
    def __init__(self, max_gap=60):  # Maximum gap in samples
        self.last_valid = None
        self.gap_count = 0
        self.max_gap = max_gap

    def impute(self, value, is_valid):
        if is_valid:
            self.last_valid = value
            self.gap_count = 0
            return value, "original"

        if self.last_valid is None:
            return None, "no_history"

        self.gap_count += 1
        if self.gap_count > self.max_gap:
            return None, "gap_too_large"

        return self.last_valid, "imputed_ffill"
Try It: Forward Fill Simulator

25.7 Linear Interpolation

Forward-fill answers “what if the last value still held?” Interpolation asks a different question: if the signal changed smoothly between two known readings, what values plausibly sat inside the gap?

Better for trending values when future data is available:

def linear_interpolate(data, timestamps):
    """
    Interpolate missing values (None/NaN) using linear interpolation.
    Requires knowledge of surrounding valid points.
    """
    import numpy as np

    data = np.array(data, dtype=float)
    timestamps = np.array(timestamps, dtype=float)

    valid_mask = ~np.isnan(data)
    valid_indices = np.where(valid_mask)[0]

    if len(valid_indices) < 2:
        return data

    # Interpolate
    interpolated = np.interp(
        timestamps,
        timestamps[valid_mask],
        data[valid_mask]
    )

    return interpolated
Interpolation vs Forward Fill

25.8 Seasonal Decomposition Fill

Some data repeats. When temperature follows a daily cycle, a method that remembers the phase of that cycle can be more honest than a straight line across the gap.

For data with known patterns (e.g., temperature with daily cycles):

def seasonal_fill(data, period=24):
    """
    Fill missing values using seasonal pattern from historical data.
    period: number of samples in one cycle (e.g., 24 for hourly data with daily cycle)
    """
    import numpy as np

    data = np.array(data, dtype=float)
    n = len(data)

    # Calculate seasonal pattern from valid data
    seasonal = np.zeros(period)
    counts = np.zeros(period)

    for i, val in enumerate(data):
        if not np.isnan(val):
            seasonal[i % period] += val
            counts[i % period] += 1

    # Average seasonal values
    with np.errstate(divide='ignore', invalid='ignore'):
        seasonal = np.where(counts > 0, seasonal / counts, np.nan)

    # Fill missing with seasonal pattern
    filled = data.copy()
    for i in range(n):
        if np.isnan(filled[i]) and not np.isnan(seasonal[i % period]):
            filled[i] = seasonal[i % period]

    return filled
Try It: Seasonal Decomposition Fill

Wrong Imputation Strategy

The mistake: Using forward-fill for event-driven sensors (motion, door open/close) or interpolation for categorical data.

Symptoms:

  • Motion sensor shows constant “motion detected” during sensor offline period
  • Door sensor shows “open” for hours when sensor battery died while door was open
  • Analytics show unrealistic patterns during imputed periods

Why it happens: One-size-fits-all imputation applied without considering sensor semantics.

The fix: Always match imputation strategy to sensor type. See the Decision Framework later in this chapter for a complete sensor-to-strategy mapping table and decision tree.

Prevention: Create sensor metadata that specifies the imputation strategy for each sensor type in your deployment.

How long can you safely forward-fill temperature data?

For a typical indoor temperature sensor:

  • Normal change rate: 0.5°C per hour (HVAC cycles)
  • Maximum change rate: 3°C per hour (HVAC failure, door open)
  • Sensor sampling: Every 60 seconds

Gap duration analysis:

Gap DurationExpected ChangeForward-Fill ErrorAcceptable?
1 minute0.008°C (normal)~0.01°C✓ Excellent
5 minutes0.042°C~0.05°C✓ Very good
30 minutes0.25°C~0.3°C✓ Good (trend analysis OK)
2 hours1.0°C~1.5°C✗ Poor (alert thresholds invalid)

Formula for maximum safe gap:

tmax=ϵacceptablermaxt_{max} = \frac{\epsilon_{acceptable}}{r_{max}}

Where ϵacceptable\epsilon_{acceptable} is the maximum tolerable error and rmaxr_{max} is the maximum expected change rate.

Example: For ±1°C acceptable error and 3°C/hour max rate:

tmax=1°C3°C/hour=0.33 hours=20 minutest_{max} = \frac{1°C}{3°C/\text{hour}} = 0.33 \text{ hours} = 20 \text{ minutes}

Recommendation: Forward-fill temperature for max 20 minutes. Beyond that, flag as “sensor offline” rather than impute.

25.9 Try It: Forward-Fill Gap Calculator

Read the Try It: Forward-Fill Gap Calculator material as a decision path rather than as isolated entries. First identify the operating condition in each entry and keep its units, timing, source, and assumed system state attached to it. Next compare the entries at the point where responsibility changes between device, gateway, network, analytic service, and operator; that hand-off is where apparently similar choices often produce different outcomes. Then follow the failure case: ask what becomes stale, delayed, unavailable, or unsafe, who detects it, and what evidence permits recovery. Finally connect the result to the chapter’s running design record by naming the selected behavior, the rejected alternative, the measurement that justifies the choice, and the condition that forces a recheck. That order turns the examples or comparison into an auditable engineering argument.

Data DoraCheckpoint: Imputation Boundaries

You now know:

  • The safe forward-fill window comes from acceptable error divided by maximum rate of change.
  • With a 1°C error limit and 3°C/hour maximum rate, the chapter’s example gives a 20 minute limit.
  • The strategy table later keeps the same discipline: temperature often allows 10-30 minutes, periodic data can use seasonal fill up to 6 hours, and event gaps over 1 hour should still be flagged.

25.10 Noise Filtering Techniques

  • ~15 min | - - - Advanced | - P10.C09.U05

Once the gaps are accounted for, the next problem is different: readings are present, but the series is jagged, spiky, or too noisy for a reliable decision.

25.11 Moving Average Filter

Simple and effective for steady-state noise reduction:

class MovingAverageFilter:
    def __init__(self, window_size=5):
        self.window_size = window_size
        self.buffer = []

    def filter(self, value):
        self.buffer.append(value)
        if len(self.buffer) > self.window_size:
            self.buffer.pop(0)

        return sum(self.buffer) / len(self.buffer)
Try It: Moving Average Noise Reduction

25.12 Median Filter

Moving averages reduce random variation, but a single bad spike still enters the average. The median filter is the next tool because it can ignore a spike when most nearby readings are sane.

Excellent for removing spike noise while preserving edges:

class MedianFilter:
    def __init__(self, window_size=5):
        self.window_size = window_size
        self.buffer = []

    def filter(self, value):
        self.buffer.append(value)
        if len(self.buffer) > self.window_size:
            self.buffer.pop(0)

        sorted_buffer = sorted(self.buffer)
        mid = len(sorted_buffer) // 2

        if len(sorted_buffer) % 2 == 0:
            return (sorted_buffer[mid - 1] + sorted_buffer[mid]) / 2
        return sorted_buffer[mid]
Median vs Moving Average

25.13 Exponential Smoothing

After windowed filters, exponential smoothing gives you a streaming option: each new reading nudges the estimate without waiting for a full centered window.

Provides weighted average with more weight on recent values:

class ExponentialSmoothingFilter:
    def __init__(self, alpha=0.3):
        """
        alpha: smoothing factor (0-1)
        Higher alpha = more weight on recent values = less smoothing
        Lower alpha = more weight on history = more smoothing
        """
        self.alpha = alpha
        self.smoothed = None

    def filter(self, value):
        if self.smoothed is None:
            self.smoothed = value
        else:
            self.smoothed = self.alpha * value + (1 - self.alpha) * self.smoothed

        return self.smoothed

25.14 Filter Comparison

25.15 Moving Average

  • Latency: (N-1)/2 samples
  • Edge preservation: Poor
  • Spike removal: Moderate
  • Best for: Steady-state signals

25.16 Median

  • Latency: (N-1)/2 samples
  • Edge preservation: Excellent
  • Spike removal: Excellent
  • Best for: Spike-contaminated data

25.17 Exponential

  • Latency: Continuous
  • Edge preservation: Good
  • Spike removal: Moderate
  • Best for: Real-time smoothing

25.18 Kalman

  • Latency: Minimal
  • Edge preservation: Excellent
  • Spike removal: Excellent
  • Best for: Known dynamics and sensor fusion

How does filter window size affect noise reduction and latency?

For a moving average filter with Gaussian noise (σ = 2.0°C) on temperature sensor:

Noise reduction formula:

σfiltered=σoriginalN\sigma_{filtered} = \frac{\sigma_{original}}{\sqrt{N}}

Where NN is the window size.

Window Size (N)Noise ReductionLatency (samples)Temperature Example
3σ/3=0.58σ\sigma / \sqrt{3} = 0.58\sigma1.02.0°C → 1.15°C noise
5σ/5=0.45σ\sigma / \sqrt{5} = 0.45\sigma2.02.0°C → 0.89°C noise
10σ/10=0.32σ\sigma / \sqrt{10} = 0.32\sigma4.52.0°C → 0.63°C noise
20σ/20=0.22σ\sigma / \sqrt{20} = 0.22\sigma9.52.0°C → 0.45°C noise

Trade-off: Larger window → better noise rejection BUT longer delay detecting real changes.

Latency calculation: Output lags input by N12\frac{N-1}{2} samples. For N=10N=10 at 1 Hz sampling → 4.5 second delay.

Practical rule: Choose NN such that latency is < 10% of the timescale you care about. If monitoring hourly HVAC cycles (3600s), 5-10 sample window (2-4.5s latency) is acceptable. If detecting rapid door opening events (10s timescale), use N=3N=3 (1.0s latency max).

Data DoraCheckpoint: Filter Trade-Offs

You now know:

  • Moving average noise falls as sigma divided by square root of N, but latency grows as (N-1)/2 samples.
  • At N=10 and 1 Hz, that latency is 4.5 seconds; a 100 point moving average at 1 Hz later becomes a 50 second lag.
  • Median filters handle sparse spikes; exponential smoothing is useful when a real-time stream cannot wait for a centered window.

25.19 Try It: Filter Window Size Calculator

25.20 Try It: Exponential Smoothing Explorer

25.21 Choosing the Right Filter

The examples above show the mechanics. This section turns them into an engineering choice: identify the noise, decide whether edges matter, then pick the simplest filter that preserves the signal you care about.

def choose_filter(signal_characteristics):
    """
    Guide for selecting appropriate noise filter based on signal characteristics.
    """
    recommendations = {
        'steady_state_with_gaussian_noise': {
            'filter': 'MovingAverage',
            'reason': 'Averages out random noise effectively',
            'window_size': 5  # Adjust based on noise frequency
        },
        'spiky_noise_impulse': {
            'filter': 'MedianFilter',
            'reason': 'Completely ignores outlier spikes',
            'window_size': 5  # Odd number works best
        },
        'real_time_tracking': {
            'filter': 'ExponentialSmoothing',
            'reason': 'No latency, responsive to changes',
            'alpha': 0.3  # Lower = smoother, higher = more responsive
        },
        'sensor_fusion_known_dynamics': {
            'filter': 'KalmanFilter',
            'reason': 'Optimal estimation with uncertainty tracking',
            'params': 'process_noise, measurement_noise'
        },
        'edge_preserving': {
            'filter': 'MedianFilter',
            'reason': 'Preserves sharp transitions in data',
            'window_size': 3
        }
    }
    return recommendations.get(signal_characteristics, recommendations['steady_state_with_gaussian_noise'])
Try It: Filter Selection Advisor

25.22 Combining Filters

For robust noise removal, filters can be cascaded:

class CombinedFilter:
    """
    Two-stage filter: Median first (remove spikes), then exponential smooth.
    """
    def __init__(self, median_window=5, exp_alpha=0.3):
        self.median_filter = MedianFilter(median_window)
        self.exp_filter = ExponentialSmoothingFilter(exp_alpha)

    def filter(self, value):
        # Stage 1: Remove spikes with median
        despike = self.median_filter.filter(value)
        # Stage 2: Smooth remaining noise
        smooth = self.exp_filter.filter(despike)
        return smooth

# Usage
combined = CombinedFilter(median_window=5, exp_alpha=0.2)
for reading in sensor_stream:
    clean_value = combined.filter(reading)
Two-Stage Filter Pipeline

Scenario: You have a temperature sensor monitoring a cold storage facility. The sensor reports every 10 seconds. You’ve observed occasional spikes due to electrical interference when the cooling compressor starts (5-10C jumps), and you need to filter these without losing legitimate temperature trends.

Given:

  • Sampling rate: 0.1 Hz (1 sample per 10 seconds)
  • Normal temperature: -18C ± 2C
  • Compressor noise: Random spikes to -8C or -28C (duration: 1-2 samples)
  • Legitimate temperature changes: 0.5C per minute maximum

Question: Should you use a moving average or median filter, and what window size?

Solution:

Step 1: Analyze the noise characteristics

  • Spike duration: 1-2 samples = 10-20 seconds
  • Spike frequency: Approximately 5% of readings (every 200 seconds when compressor cycles)
  • Spike magnitude: 10C deviation (huge compared to normal 2C variation)

Step 2: Calculate required window size

For moving average:

  • Window needs to span spike duration
  • 3-sample window: averages noise into adjacent readings
  • Example: [-18, -28, -18] → average = -21.3C (still shows distortion)

For median filter:

  • Window needs odd number of samples
  • 3-sample window: [-18, -28, -18] → median = -18C (spike completely removed!)
  • 5-sample window: [-18, -18, -28, -18, -18] → median = -18C (still perfect)

Step 3: Verify edge preservation

Legitimate temperature change over 1 minute:

  • Rate: 0.5C/min = 0.083C per 10 seconds
  • Over 5 samples: [-18.0, -18.1, -18.2, -18.3, -18.4]
  • Median of 5: -18.2C (preserves trend!)

Step 4: Calculate latency

Window size 5 = (5-1)/2 = 2 samples delay = 20 seconds latency

For cold storage monitoring (not time-critical), 20 seconds is acceptable.

Answer: Use 5-sample median filter

Why:

  • Completely removes 1-2 sample spikes
  • Preserves legitimate temperature trends
  • No tuning parameters (unlike moving average weights)
  • Latency (20s) acceptable for this application

Implementation:

median_filter = MedianFilter(window_size=5)
for reading in sensor_stream:
    clean_temp = median_filter.filter(reading)
    if clean_temp < -20:  # After filtering, threshold check is reliable
        trigger_high_temp_alarm()

Key Insight: Median filters excel when noise is sparse spikes rather than continuous Gaussian noise. The window should be large enough to ensure spikes are minority values (< 50%) within the window.

When sensor data goes missing, selecting the correct imputation strategy depends on sensor characteristics and downstream requirements. Use this framework to guide your decision:

Sensor CharacteristicImputation StrategyRationaleMax Gap Duration
Slowly changing continuous (temperature, humidity)Forward-fill or linear interpolationPhysical inertia prevents rapid changes10-30 minutes
Event-driven binary (motion detector, door switch)Zero/False for missing periodsAbsence of event signal = no event occurredUnlimited (but flag gaps >1 hour)
Monotonic counter (energy meter, flow meter)Zero increment for missing periodNo reading = no consumption during gapUp to 1 day
Periodic with known pattern (daily temperature cycle)Seasonal decompositionLeverage historical patternUp to 6 hours
High-frequency volatile (stock price, vibration)Do not impute - mark as missingInterpolation creates false dataN/A - preserve gaps
Redundant sensor arrayUse nearby sensor + bias correctionSpatial correlation for better estimateDepends on sensor density

Decision Tree:

  • is the sensor event-driven?

    • YES → Use zero/default state for missing periods
    • NO → Continue to step 2
  • does the signal change slowly? (Rate < 10% per time constant)

    • YES → Forward-fill acceptable for gaps < 10x sampling interval
    • NO → Continue to step 3
  • is there a known periodic pattern?

    • YES → Use seasonal decomposition fill
    • NO → Continue to step 4
  • are there nearby sensors measuring the same quantity?

    • YES → Use spatial interpolation from neighbors
    • NO → Use linear interpolation or mark as missing

Example Application:

def select_imputation_strategy(sensor_type, gap_duration_minutes):
    if sensor_type == "motion_detector":
        return "zero_fill"  # No motion during gap
    elif sensor_type == "temperature":
        if gap_duration_minutes < 30:
            return "forward_fill"
        elif gap_duration_minutes < 360:
            return "seasonal_fill"  # Use daily pattern
        else:
            return "mark_missing"  # Gap too long
    elif sensor_type == "energy_meter":
        return "zero_increment"  # No consumption
    elif sensor_type == "vibration":
        return "mark_missing"  # Cannot safely interpolate

Warning Signs of Wrong Strategy:

  • Motion sensor shows continuous “detected” during power outage → Used forward-fill instead of zero
  • Temperature shows impossible linear ramp over 6-hour gap → Used interpolation instead of seasonal pattern
  • Energy meter shows zero consumption for entire day → Used zero_increment for too-long gap (should alarm)
Detect Outliers Before Imputing

The Mistake: Running imputation before outlier detection, causing outliers to be forward-filled or interpolated into the data stream, permanently corrupting adjacent readings.

Why It Happens: Data quality pipelines are often built incrementally. Engineers add imputation first (to handle missing data), then later realize they need outlier detection. By then, the pipeline order is established and changing it requires refactoring.

Example of the Problem:

# WRONG: Impute first, detect outliers second
readings = [22.1, 22.3, 99.9, None, None, None, 22.8]  # 99.9 is sensor fault

# Step 1: Forward-fill (MISTAKE - happens before outlier removal)
imputed = forward_fill(readings)
# Result: [22.1, 22.3, 99.9, 99.9, 99.9, 99.9, 22.8]

# Step 2: Outlier detection
cleaned = remove_outliers(imputed, threshold=3_sigma)
# Result: [22.1, 22.3, REMOVED, REMOVED, REMOVED, REMOVED, 22.8]
# Lost 4 data points! The None values became 99.9 outliers.

The Fix: Always apply outlier detection and validation BEFORE imputation:

# CORRECT: Validate first, impute second
readings = [22.1, 22.3, 99.9, None, None, None, 22.8]

# Step 1: Outlier detection and removal (mark as None)
validated = remove_outliers(readings, threshold=3_sigma)
# Result: [22.1, 22.3, None, None, None, None, 22.8]

# Step 2: Forward-fill ONLY the validated stream
imputed = forward_fill(validated)
# Result: [22.1, 22.3, 22.3, 22.3, 22.3, 22.3, 22.8]
# Correctly preserved legitimate data!

Correct Pipeline Order:

  1. Range Validation → Mark out-of-range values as None
  2. Rate-of-Change Validation → Mark impossible jumps as None
  3. Outlier Detection → Mark statistical outliers as None
  4. Missing Value Imputation → Fill None values using appropriate strategy
  5. Noise Filtering → Apply smoothing to cleaned data

Real-World Impact: A temperature monitoring system in a pharmaceutical warehouse experienced this bug. A faulty sensor spiked to 85C for one reading before going offline. The spike was forward-filled for 30 minutes (the gap duration), triggering false temperature excursion alarms and requiring destruction of $50,000 worth of temperature-sensitive drugs. Root cause: imputation ran before outlier removal in the data pipeline.

Prevention Checklist:

  • Range validation is the FIRST step in your pipeline
  • Outlier detection runs BEFORE any imputation
  • Unit tests verify corrupted readings don’t propagate through imputation
  • Your data quality framework explicitly enforces stage ordering
Data DoraCheckpoint: Pipeline Order

You now know:

  • Validation must run before imputation, or a bad value can be copied into the gap.
  • The warehouse example shows the cost: one 85C spike was forward-filled for 30 minutes and forced a $50,000 destruction decision.
  • A defensible pipeline is range validation, rate-of-change validation, outlier detection, imputation, then filtering.

25.23 Knowledge Check

25.24 Quiz: Missing Data and Filtering

25.25 Interactive Quiz: Match Concepts

25.26 Interactive Quiz: Sequence the Steps

Common Pitfalls

Forward-filling works for temperature that changes by 0.5°C per minute but creates flat-line artefacts for high-frequency vibration data. Match the imputation method to the signal dynamics.

If downstream analytics cannot distinguish real readings from imputed ones, anomaly detectors may flag imputed values as anomalies or ML models may learn from artefacts. Always add an imputation flag column alongside filled values.

Global mean imputation destroys temporal patterns (seasonality, trends) that are the most valuable features in IoT data. Use time-local methods (linear interpolation, seasonal decomposition imputation) instead.

A 100-point moving average on a 1 Hz sensor introduces 50-second lag — unacceptable for real-time anomaly detection. Balance noise suppression against lag, or use an exponential moving average when a lower-latency smoother is acceptable.

25.27 Label the Diagram

25.28 Code Challenge

25.29 Missing-Data Repair Contracts

The chapter above covers forward-fill, interpolation, seasonal fill, moving average filters, median filters, exponential smoothing, calculators, and practice quizzes. Continue to Missing-Data Repair and Filtering Contracts for the deeper L2 material: missingness mechanisms, repair quality flags, impulse-noise filters, held-out replay validation, and MCAR/MAR/MNAR bias boundaries.

25.30 Summary

Missing value imputation and noise filtering are essential for producing clean, complete sensor data:

  • Forward Fill: Simple and effective for slowly-changing continuous values (temperature, humidity)
  • Linear Interpolation: Better for trending data when you have values on both sides of the gap
  • Seasonal Fill: Use when data has known periodic patterns (daily temperature cycles)
  • Sensor-Specific Imputation: Motion sensors get zero, state sensors get “unknown”, counters get zero increment
  • Moving Average: Good for steady-state Gaussian noise, but blurs edges
  • Median Filter: Excellent for spike removal, preserves sharp transitions
  • Exponential Smoothing: Real-time with no latency, tunable responsiveness

Critical Design Principle: Always match your imputation and filtering strategy to the sensor type and data characteristics. A one-size-fits-all approach will produce incorrect results for at least some of your sensors.

Concept Relationships

Builds On:

Enables:

25.31 See Also

Data Quality Pipeline:

Filtering Techniques:

Applications:

25.32 What’s Next

If you want to…Read this
Understand data quality validation before imputationData Quality Validation
Apply preprocessing in the broader pipeline contextData Quality and Preprocessing
Dig deeper into repair contracts and missingness biasMissing-Data Repair and Filtering Contracts
Practise normalisation techniques in the labData Quality Normalisation Lab
Apply clean data to anomaly detectionAnomaly Detection Overview
Return to the module overviewBig Data Overview