experiment-results-interpreter
Interprets the results of a valid online controlled experiment, one whose harness, SRM, and telemetry have already been confirmed. Covers the distinction between practical and statistical significance, reading confidence intervals instead of binary p-values, novelty and primacy week-over-week decay that causes post-ship reversion, interaction effects from concurrent experiments, Simpson's paradox in segmented results, and the ordered guardrail-check sequence required before a ship decision. Use when a data scientist or PM is ready to draw conclusions from an experiment whose telemetry and randomisation have already passed the ab-test-validity-checklist. Distinct from ab-test-validity-checklist (harness setup and SRM detection) and from interaction-effect overlap auditing during experiment design.
Install with skills.sh (any agent)
npx skills add testland/qa --skill experiment-results-interpreterexperiment-results-interpreter
Overview
The ab-test-validity-checklist skill confirms that an experiment was run correctly - clean SRM, honest peeking discipline, pre-declared OEC. This skill covers the next question: given a valid experiment, what does the result actually mean, and is it safe to ship?
The two most common failure modes at this stage, per Kohavi, Tang, Xu Trustworthy Online Controlled Experiments (Cambridge Univ. Press, 2020, ISBN 9781108724265), are:
This skill is a pure reference for data scientists and PMs reading final experiment dashboards.
When to use
How to use
Work through the six interpretation steps in order. Each step has a hard stop: if a step blocks, do not proceed to the next.
Step 1 - Practical significance before statistical significance
A statistically significant effect can still be too small to matter: results "may be statistically significant but not practically significant" (Nielsen Norman Group, sources).
The minimum practically significant effect (MPSE) must be declared in the pre-registration (proposal.yml). At read-time:
| Question | How to answer |
|---|---|
| Is the point estimate above the MPSE? | Compare OEC lift to the pre-declared threshold |
| Is the confidence interval entirely above the MPSE? | If the lower bound falls below the MPSE, treat as inconclusive |
| Would a 0.1% conversion lift justify the maintenance cost? | Engineering and product judgement, not statistics |
A statistically significant result with a point estimate well below the MPSE is a no-ship unless the maintenance cost is zero and the direction is consistent with strategy.
Step 2 - Confidence intervals, not just p-values
A 95% confidence interval gives the plausible range of the true effect - "both directionality and magnitude of effects simultaneously" (Statsig, sources) - which a binary p-value cannot.
Reading a result:
| CI position | Interpretation |
|---|---|
| Entirely above zero and above MPSE | Strong positive - candidate for ship |
| Entirely above zero, partially below MPSE | Positive but magnitude uncertain - extend or accept lower bound as the working estimate |
| Crosses zero | Inconclusive; do not ship on this signal |
| Entirely below zero | Negative treatment effect - do not ship |
Width matters. A narrow CI means high power and a precise estimate; a wide CI means the experiment was underpowered, so extending runtime or pooling more traffic will narrow it. Variance-reduction techniques (CUPED) narrow the CI without inflating the false-positive rate (Microsoft ExP, sources) - prefer platforms that apply it by default.
Do not convert CI edges back to p-values to decide - the CI is the complete picture.
Step 3 - Novelty and primacy effects
A statistically and practically significant result in week 1 may not persist. Two opposing artefacts corrupt early-period estimates:
Novelty effect: users react to the mere newness of a change; engagement (clicks, session length) inflates above the true long-run level, then decays.
Primacy effect (resistance to change): new UI or workflows initially hurt task-completion because users must relearn existing habits; the treatment appears worse early, then improves as users adapt. Kohavi et al. note novelty and primacy are "significant causes of treatment effects changing over time but are not the sole causes" (sources).
Detection and mitigation:
| Signal | Method |
|---|---|
| Week 1 lift much larger than week 2+ | Segment metric by experiment week; compute week-over-week trend |
| Effect reversal after ship | Look for Kendall's tau trending toward zero over 14+ day window |
| New-user cohort differs from returning-user cohort | Segment by first_exposure_date - new users see no novelty decay |
Microsoft ExP found "14-day surprises" - the second week's estimate falling outside the first week's 3-sigma CI - at roughly 4% of experiments, far more than the theoretical rate (sources). Minimum run time: two full weeks before drawing ship conclusions from experiments that change UI patterns; feature launches with no UX learning curve may need only one week.
Step 4 - Interaction effects
An experiment running concurrently with other experiments may have its treatment effect inflated, deflated, or reversed by interference.
Two types:
Between-experiment interaction: variant A of experiment X and variant B of experiment Y are assigned to overlapping user populations. If the two treatments interact (positively or negatively), the OEC measured for X is partly caused by Y's presence (Microsoft ExP, "A/B Interactions: A Call to Relax", sources).
Treatment spillover: a social or marketplace product where treating some users changes outcomes for untreated users in the same experiment (network effects). The control group is contaminated; the measured effect is attenuated. Kohavi et al. (ISBN 9781108724265) categorise this as a stable unit treatment value assumption (SUTVA) violation.
Detection checklist:
| Check | Pass criterion |
|---|---|
| Concurrent experiment audit | List all experiments running in the same user population during the experiment window |
| Mutual-exclusion / interaction check | For each concurrent experiment: did assignment overlap create a joint condition that was never intended? |
| SUTVA plausibility | Is the metric a per-user metric (e.g., clicks) or a network metric (e.g., messages sent to others)? Network metrics need holdout or cluster-level randomisation |
If a significant interaction is identified, the measured effect is confounded. Options: (a) isolate with mutual exclusion and re-run, (b) include the interaction term in a factorial model, (c) block ship pending analysis.
Step 5 - Simpson's paradox
The aggregate OEC lift may be positive while every segment shows a negative or neutral lift - or vice versa. This is Simpson's paradox.
Simpson's paradox is when "a trend appears in several groups of data but disappears or reverses when the groups are combined" (Wikipedia, sources).
In A/B testing, it surfaces when:
Detection:
For each major segment (device, country, user-cohort, new vs returning):
1. Compute per-segment OEC lift and CI.
2. Verify direction is consistent with the aggregate result.
3. Check that per-segment traffic allocation matches the overall ratio.If direction flips in a large segment: the aggregate result is misleading. Segment-level results are the truth; the aggregate is an artefact of unequal allocation. Do not ship on a positive aggregate with a negative segment that represents > 20% of users.
The ab-test-validity-checklist Step 7 includes a "segment-stability" gate for this reason - this skill provides the interpretive depth behind that gate.
Step 6 - Guardrail check before ship
Per guardrail-metrics-reference: no ship decision is valid without confirming that no guardrail metric has breached its block threshold.
Ordered check:
1. Load the guardrail dashboard for the experiment.
2. For each declared guardrail metric:
a. Is the observed change within the alert threshold? (investigate, but not blocked)
b. Does the observed change breach the block threshold? (STOP - no-ship)
3. If any guardrail is on alert: document the finding and make an
explicit call (accepted risk + rationale OR extend experiment).
4. If all guardrails are within alert thresholds: proceed to ship.Common guardrail check failures before ship:
| Anti-pattern | Consequence |
|---|---|
| OEC positive, latency guardrail in alert band, ship anyway | Regression ships; support tickets spike |
| Checking guardrails at 80% of sample (early) | Underpowered - guardrail CIs wide; false safe signal |
| Ignoring guardrails with wide CIs because "p > 0.05" | Wide CI is not clearance; it means underpowered, not unaffected |
| Trust guardrail omitted (opt-out rate) | Long-term retention damage, not captured by OEC |
Measuring only the OEC can "disregard important information" (Nielsen Norman Group, sources) - always check guardrails alongside it.
Example
Scenario: Redesigned onboarding flow experiment. Declared OEC: 7-day activation rate. MPSE: +0.5pp absolute. Alpha 0.05, 80% power. Ran 14 days. Result reads: lift = +1.2pp (95% CI: +0.3pp, +2.1pp).
Step 1 - Practical significance: Point estimate +1.2pp > MPSE +0.5pp. Lower CI bound +0.3pp is below MPSE. Minimum realistic effect is 0.3pp - marginal. Discuss with product whether 0.3pp justifies the complexity.
Step 2 - CI read: CI entirely above zero; statistically significant. Width (1.8pp) is moderate. Acceptable - not underpowered.
Step 3 - Novelty check: Week 1 lift was +2.1pp; week 2 lift was +0.9pp. Declining trend. Novelty effect likely inflating week 1. Use week 2 estimate (+0.9pp) as the stable-state estimate - still above MPSE.
Step 4 - Interaction: No other experiment running in onboarding funnel. SUTVA: metric is per-user (not network). Clear.
Step 5 - Simpson's: Mobile segment (45% of traffic): lift +0.7pp. Desktop segment (55%): lift +1.6pp. Directions consistent; no paradox.
Step 6 - Guardrails: API p95 latency +3% (alert threshold +5% or +50ms block). Within alert, no breach. DAU stable. Opt-out rate flat. All green.
Ship decision: Ship, citing week-2 stable estimate +0.9pp and clean guardrails. Document novelty decay in the ship note.
Anti-patterns
| Anti-pattern | Why it fails | Fix |
|---|---|---|
| Ship on week-1 lift alone | Novelty effect inflates early results; may revert | Run at least 2 weeks; compare week 1 vs week 2 |
| Treat p-value < 0.05 as "the result" | Binary; ignores magnitude, direction, and CI width | Read the CI; compare CI to MPSE |
| Skip segment analysis | Simpson's paradox hidden in aggregate | Always segment by device, new vs returning, country |
| Ignore guardrail alerts as "not significant" | Wide CI is not clearance | Investigate every alert before ship |
| Ship on practical but not statistical significance | Effect may be noise at that magnitude | Wait for power target |
| Treat post-ship metric as experiment validation | Observational data after ship mixes causation | Experiment result is causal; post-ship is not |
| Combine result across concurrent experiments without interaction check | Confounded OEC | Audit the concurrent experiment list |
| Ship "because the direction is right" on a CI that crosses zero | Inconclusive result | Extend runtime or accept null |
Limitations
References
Full source attributions and verbatim quotes: references/sources.md. Primary source is Kohavi, Tang, Xu, Trustworthy Online Controlled Experiments (Cambridge Univ. Press, 2020, ISBN 9781108724265); companion catalogs ab-test-validity-checklist, guardrail-metrics-reference, peeking-problem-reference.
Sources and verbatim citations
View source (opens in new window)Sources and verbatim citations
Full source attributions for the interpretation steps in SKILL.md. Each inline [sources](references/sources.md) link points here.
Practical vs statistical significance (Step 1)
Nielsen Norman Group, A/B testing guide: results "may be statistically significant but not practically significant" - a test can show reliable differences that lack meaningful business value. nngroup.com/articles/ab-testing/ (opens in new window)
Confidence intervals (Step 2)
Statsig confidence-interval docs: "A 95% confidence interval should contain the true effect 95% of the time"; it is "an intuitive way to quantify the uncertainty" that gives "both directionality and magnitude of effects simultaneously." docs.statsig.com/experiments/statistical-methods/confidence-intervals (opens in new window)
Microsoft ExP variance-reduction research: CUPED and similar techniques produce "narrower confidence intervals, with values that are closer to the estimated effect" without sacrificing the false-positive rate. microsoft.com/en-us/research/group/experimentation-platform-exp/articles/deep-dive-into-variance-reduction/ (opens in new window)
Novelty and primacy effects (Step 3)
Kohavi, Tang, Xu, Trustworthy Online Controlled Experiments (Cambridge Univ. Press, 2020, ISBN 9781108724265): "novelty and primacy effects are significant causes of treatment effects changing over time but are not the sole causes."
Microsoft ExP external-validity research: "14-day surprises" - the second week's estimate falling outside the first week's 3-sigma confidence interval - occurred at roughly 4% of experiments, far more than the theoretical rate. microsoft.com/en-us/research/group/experimentation-platform-exp/articles/external-validity-of-online-experiments-can-we-predict-the-future/ (opens in new window)
Wikipedia, novelty effect: a temporary boost from "introducing new elements on some activity or behavior" rather than underlying improvement. en.wikipedia.org/wiki/Novelty_effect (opens in new window)
Interaction effects (Step 4)
Microsoft ExP, "A/B Interactions: A Call to Relax": addresses A/B interactions in concurrent experiment design alongside the pitfalls of even tiny SRMs. microsoft.com/en-us/research/group/experimentation-platform-exp/articles/ (opens in new window)
Kohavi et al. (ISBN 9781108724265) categorise treatment spillover as a stable unit treatment value assumption (SUTVA) violation.
Simpson's paradox (Step 5)
Wikipedia, Simpson's paradox: "a trend appears in several groups of data but disappears or reverses when the groups are combined." Canonical Berkeley admissions example: men were admitted at higher aggregate rates (44% vs 35%) while women had better odds in most individual departments, because women applied to more competitive departments. en.wikipedia.org/wiki/Simpson%27s_paradox (opens in new window)
Guardrails (Step 6)
Nielsen Norman Group: "if you measure only one metric to determine whether your test is successful, you might disregard important information." nngroup.com/articles/ab-testing/ (opens in new window)
Companion catalogs
ab-test-validity-checklist, guardrail-metrics-reference, peeking-problem-reference.
Related skills
ab-test-validity-checklist
Workflow skill that builds an A/B-test validity checklist from an experiment proposal, walking the canonical design-correctness gates - pre-registered OEC/power/guardrails, randomization unit + SRM check, assignment integrity, telemetry, peeking discipline, novelty/primacy, post-experiment SRM re-check - into a per-experiment checklist + sign-off form. Use when launching, auditing, or governing an experiment. For pitfall mechanics use guardrail-metrics-reference or peeking-problem-reference; to read an already-valid result use experiment-results-interpreter; for per-SDK harness tests use optimizely-test or statsig-test - this gates DESIGN, not SDK code.
amplitude-experiment-test
Wraps Amplitude Experiment SDK testing patterns: client initialization with API key (or a bootstrapped local flag config for offline tests), the fetch / variant API, exposure-event suppression in tests, and assignment-integrity tests. Use when writing tests for code that uses Amplitude Experiment for A/B testing or flag management.
guardrail-metrics-reference
Pure-reference catalog of guardrail-metric methodology for online controlled experiments. Defines guardrail metrics (metrics that must NOT degrade for an experiment to ship, even if the primary metric improves), the standard guardrail set (latency / errors / engagement / opt-out), the relationship to OEC (Overall Evaluation Criterion) per Kohavi et al., and pre-commitment of the metric set. The quantitative evaluation mechanics (per-metric alert/block thresholds, Bonferroni / Benjamini-Hochberg multiple-comparison correction) live in references/. Use when designing the metric set for a new experiment, auditing existing experiment configs, or reviewing experiment results before ship-decisions.
optimizely-test
Wraps Optimizely Feature Experimentation SDK testing patterns - client init from a fixture datafile (offline-friendly), the decide / decideAll v5 API, forced-decisions for per-test arm pinning (fixing which variation a user gets), OptimizelyUserContext + activate/track events, assignment-integrity (deterministic bucketing) tests. Use when writing A/B tests or feature-flag tests for Optimizely-instrumented application code. For another experimentation SDK use the matching harness - statsig-test, vwo-test, amplitude-experiment-test, or split-io-test; for experiment DESIGN gates not SDK code use ab-test-validity-checklist.
peeking-problem-reference
Pure-reference catalog of the peeking problem in online A/B testing. Defines the problem (repeatedly looking at experiment results inflates the false-positive rate above the declared alpha because each look is a separate test), the canonical mitigations (fixed-horizon test with pre-declared sample size; sequential testing with alpha-spending functions e.g., O'Brien-Fleming, Pocock; always-valid inference / mSPRT per Johari et al.), and the policy choices (data-peek schedule, stop-early thresholds, decision-time guard rails). Use when designing an experimentation platform's stop-early policy or auditing why a result was declared significant.
split-io-test
Wraps Split.io (Harness FME) SDK testing patterns: hermetic localhost/offline mode with an in-memory features map (JavaScript/browser) or a YAML fixture file (Node.js server-side), getTreatment and getTreatmentWithConfig evaluation, the SDK_READY event and whenReady() promise, impression listener verification, sync.impressionsMode configuration, and CI setup. Use when writing tests for application code instrumented with the Split.io or Harness Feature Management & Experimentation SDK.
statsig-test
Wraps Statsig SDK testing patterns - server-side statsig.initialize with an API key, gate / experiment / dynamic-config evaluation (checkGate, getExperiment, getConfig), local-evaluation offline mode, overrideGate / overrideConfig to force a user into an arm, assignment-integrity tests. Use when writing tests for Statsig-instrumented application code. For another experimentation SDK use the matching harness - optimizely-test, vwo-test, amplitude-experiment-test, or split-io-test; for experiment DESIGN gates not SDK code use ab-test-validity-checklist.
vwo-test
Wraps VWO (Visual Website Optimizer) SDK testing patterns: SDK initialization with the settings file (offline-capable), `getFeatureVariableValue` and `activate` API, force-bucketing for per-test assignment, and assignment-integrity tests against the bucketing algorithm. Use when writing tests for VWO-instrumented application code.