Blog
Why a Counterfactual Baseline Matters
When an initiative, operation, or intervention (IO) begins, the most important evaluation question often becomes: What would have happened without it? A counterfactual baseline is your best answer—an evidence-based projection of the expected trajectory using only the pre-IO trend. Done well, it lets you quantify incremental impact, communicate results credibly, and avoid misleading “before vs. after” comparisons that ignore existing momentum, seasonality, or regression to the mean.
This guide walks through a practical process for building a counterfactual baseline from pre-IO data, validating it, and using it responsibly.
Step 1: Define the Outcome and the “IO Start” Clearly
Start by pinning down three essentials:
- Outcome metric: what you’re projecting (e.g., weekly incidents, revenue per user, defect rate).
- Unit of analysis: by region, site, customer cohort, team, etc.
- Intervention start date/time: the earliest point the operation could plausibly influence the outcome.
Actionable checks:
- If rollout was phased, define a start date per unit (not one global date).
- If anticipation effects are possible (people changed behavior before launch), consider an “announcement date” and test sensitivity.
Step 2: Assemble and Clean the Pre-IO Time Series
Your counterfactual is only as good as your pre-period.
Minimum data guidance (rule-of-thumb, not absolute):
- Capture enough cycles to see patterns (e.g., multiple weeks across seasons, or multiple months across quarters).
- Ensure you have consistent measurement definitions across the pre-period.
Prepare the dataset:
- Confirm the timestamp granularity (daily/weekly/monthly) and align it to how decisions are made.
- Handle missing values explicitly:
- If a missing value means “zero occurred,” encode zero.
- If it means “unknown,” leave missing and impute cautiously (or restrict the window).
- Identify outliers and special events in pre-IO:
- Strikes, outages, policy changes, atypical campaigns, one-time incidents.
Practical tip: Create a “pre-IO events log” and decide whether each event is part of normal operations or a distortion to exclude.
Step 3: Visualize the Pre-IO Trend and Diagnose Structure
Before modeling, learn what the data is doing. Plot the outcome over time and check:
- Trend: rising, falling, flat, or changing slope.
- Seasonality: day-of-week effects, month-end spikes, quarterly cycles.
- Structural breaks: sudden level shifts unrelated to the IO.
- Variance patterns: stable variance vs. increasing volatility over time.
Ask:
- Is a simple line plausible?
- Does the outcome have a natural floor at zero or a saturation ceiling?
- Are there known drivers (volume, staffing levels, traffic) that should be accounted for?
This step helps you choose a model that is simple enough to explain yet accurate enough to be useful.
Step 4: Choose a Baseline Modeling Approach (Start Simple)
Your goal is not to build the most complex forecast. Your goal is a credible counterfactual. Start with simpler approaches and only add complexity when diagnostics demand it.
Option A: Linear Trend Extrapolation
Use when:
- Pre-IO trend is approximately linear.
- Seasonality is weak or already adjusted.
How:
- Fit a line to pre-IO data (time as predictor).
- Extrapolate into the post-IO window.
Watch-outs:
- Linear models can drift unrealistically over long horizons.
- Sensitive to outliers and structural breaks.
Option B: Piecewise (Segmented) Trend
Use when:
- There’s a clear pre-IO change in slope due to a known, non-IO reason.
How:
- Split pre-IO period into segments and model separately.
- Continue the most recent stable segment into the post-period.
Watch-outs:
- Don’t “hunt” for breakpoints to manufacture a narrative. Use documented operational context.
Option C: Seasonal Baseline (Seasonal Means + Trend)
Use when:
- Strong periodic effects exist (e.g., weekday patterns, seasonal peaks).
How:
- Decompose into:
- Seasonal component (average for each weekday/month)
- Underlying trend (smoothed or regression)
- Forecast by combining both.
Watch-outs:
- Seasonal patterns can shift; validate with holdout testing.
Option D: Time-Series Models (e.g., Exponential Smoothing / ARIMA-like)
Use when:
- Autocorrelation is strong and simple trend models underfit.
- You have sufficient pre-IO length to estimate parameters.
How:
- Fit the model on pre-IO, generate forecasts with prediction intervals.
Watch-outs:
- Easy to overfit; ensure the model generalizes in backtesting.
- Explainability matters—keep configuration defensible.
Option E: Covariate-Adjusted Baseline (Regression With Drivers)
Use when:
- Outcome is heavily driven by volume or other measurable factors (traffic, demand, staffing).
- Those drivers are not affected by IO (or you can use pre-IO relationships carefully).
How:
- Model outcome as a function of time + drivers.
- Forecast post-IO by projecting drivers (or using observed drivers if not impacted).
Watch-outs:
- If the IO affects drivers (e.g., a new process changes volume), using post-IO drivers can “bake in” the effect and bias results.
Step 5: Train Only on Pre-IO Data and Backtest Rigorously
To assess whether your baseline is credible, simulate the evaluation in the pre-period:
- Pick a “fake intervention date” inside the pre-IO window.
- Train your baseline on data before that date.
- Forecast the next period.
- Compare forecast vs. actual.
- Repeat with multiple cut points (rolling-origin backtesting).
Track performance with metrics appropriate to your domain:
- Absolute error (easy to interpret)
- Percent error (careful when values are near zero)
- Bias (systematic over- or under-prediction)
Decision rule:
- Prefer the simplest model that shows low bias and stable errors across backtests.
Step 6: Generate the Counterfactual and Include Uncertainty
A single projected line invites overconfidence. Provide:
- Point forecast (expected baseline)
- Prediction interval (credible range of plausible outcomes)
Practical guidance:
- Wider intervals are not a failure—they’re honesty about volatility.
- Use intervals to avoid “false precision” when reporting effect sizes.
If you’re presenting to stakeholders, frame it as:
- “Expected without IO” (baseline)
- “Observed with IO”
- “Estimated impact” = observed − baseline (with a range)
Step 7: Calculate Impact in a Way That Matches Decision Needs
Choose an impact measure that aligns with how outcomes are used:
- Level difference: average post-IO outcome vs. baseline
- Cumulative impact: sum of differences over time (useful for cost/benefit)
- Percent change vs baseline: helpful for comparability across units
- Time-to-effect: how quickly the observed series diverges from baseline
Be explicit about the evaluation window:
- Short windows can miss delayed effects.
- Long windows risk contamination by other changes (policy updates, market shifts).
Step 8: Run Sensitivity Checks to Guard Against Misleading Conclusions
Counterfactual baselines are assumptions formalized in math. Stress-test them.
Do at least three sensitivity checks:
- Different pre-IO windows: exclude early data or include more history.
- Alternative model forms: linear vs seasonal vs time-series.
- Outlier handling: include vs exclude known anomalies.
If results flip sign depending on reasonable choices, report that instability rather than forcing a definitive claim.
Step 9: Common Pitfalls (and How to Avoid Them)
-
Using post-IO data to tune the baseline
Fix: lock model choices using pre-IO backtesting only. -
Ignoring seasonality
Fix: include seasonal components or compare against same-period history. -
Confusing correlation for IO impact
Fix: document concurrent changes and consider a complementary approach (e.g., matched comparison group) if feasible. -
Overextending forecasts too far
Fix: limit interpretation to a timeframe where pre-IO dynamics are likely still relevant. -
Outcome definition drift
Fix: verify that measurement and reporting didn’t change at IO start.
A Practical Workflow You Can Reuse
- Define outcome, unit, and IO start date(s)
- Build a clean pre-IO time series with an events log
- Visualize and diagnose trend/seasonality/breaks
- Start with a simple baseline model; add complexity only if needed
- Backtest with rolling-origin validation
- Forecast counterfactual with prediction intervals
- Compute impact (level and cumulative) and communicate uncertainty
- Run sensitivity checks and document assumptions
A well-built counterfactual baseline won’t eliminate ambiguity—but it will replace guesswork with a disciplined, testable projection rooted in the pre-IO trend.