Experimentation Metrics and Statistical Power

• Choosing a single primary metric that aligns with business impact
• Power analysis and sample size calculation for product experiments
• Avoiding the usual statistical traps: peeking, multiple comparisons, and p-hacking
• Reading results: statistical significance, practical significance, and communicating uncertainty
• A step-by-step checklist to run well-powered, trustworthy experiments

An underpowered experiment feels productive but is mostly noise: it produces non-answers that keep teams iterating on guesses rather than shipping impact, and it hides meaningful wins behind random variation. A clear, pre‑specified approach to experiment metrics, sample size calculation, and power analysis is the single biggest lever you have to turn ambiguous results into confident decisions.

The challenge

You run dozens of experiments but still get one-line results that spark more meetings than action: "statistically significant, but not sure it's real," or "no lift — maybe underpowered." Symptoms include tiny MDEs that blow your budget, frequent early stopping that later evaporates, messy metric lists that create competing winners, and a culture that mistakes p‑values for proof. That confusion costs weeks, misallocates engineering time, and erodes trust in the experimentation platform and its outputs.

Choosing a single primary metric that aligns with business impact

Pick one primary metric that maps closely to the business outcome you will act on, and treat everything else as diagnostics or guardrails. Primary metrics should be directly attributable to the change, sensitive enough to detect plausible effects, and stable enough to avoid wild week-to-week swings.

• What to prefer as a primary metric:

  • For checkout changes: purchase conversion or revenue per user (RPU) when you can control for skew; use truncated or log‑transformed revenue if a small number of outliers dominate. Actionability matters more than cleverness.
  • For onboarding: activation rate within a pre-specified window (e.g., day 7). Choose a window that balances speed for powering vs. fidelity to long-term value.
  • For recommendation algorithms: downstream retention or repeated-engagement metrics if you can reasonably observe them in the experiment timeframe.

• What to put in guardrails:

  • Do-no-harm metrics such as error rates, crash rate, page load time, refund rate, CSAT, and key retention windows. Guardrails prevent short-term wins that damage quality or lifetime value. Optimizely’s guidance and scorecard features are a good reference for this approach.

• Metric design rules I use as platform PM:

  • Pick one clear decision metric per experiment and lock it in the pre‑spec. Secondary metrics explain mechanism; guardrails block regressions.
  • Prefer user/account‑level metrics over event‑level counts when appropriate (to avoid heavy-tail domination).
  • Define numerator and denominator precisely in the hypothesis (e.g., users with at least one purchase within 14 days / exposed users).
  • Predefine the direction of the test (one‑sided vs two‑sided) only when there is a strong, justifiable prior.

Callout: A sloppy metric spec is the fastest way to invalidate results. Lock the metric, the unit of analysis, and the evaluation window in your experiment registration.

[Citation: Optimizely metrics docs and guardrail guidance.]

Power analysis and sample size calculation for product experiments

Power answers a practical question: how likely will this test detect the minimum effect you care about? Formally, statistical power = 1 − β, where β is the Type II error rate. A test with 80% power misses a true MDE one time in five; at 90%, it misses one in ten.

Key inputs to any sample size calculation:

• Baseline conversion or baseline mean (call it p1 or μ1).
• Minimum Detectable Effect (MDE) — expressed in absolute (percentage points) or relative (%) terms.
• Significance level alpha (Type I error, commonly 0.05).
• Desired power (commonly 0.8 or 0.9).
• Allocation ratio (typically 1:1) and clustering or dependence (account for intra-cluster correlation for account-level tests).
• Expected running window and seasonality constraints (plan for at least one or two full business cycles).

A compact formula (two independent proportions, equal allocation) you will see in power references is:

n_per_group = ((Z_{1-α/2} + Z_{1-β})^2 * (p1(1−p1) + p2(1−p2))) / (p2 − p1)^2

This is the standard two‑sample proportions sizing equation and appears in common references and power calculators.

Practical numeric intuition (useful decision rule):

• Small baseline rates + small absolute MDE → very large N.
• Higher baseline rates or larger absolute MDE → much smaller N.
• Example (two-sided α=0.05, power=0.8; z-sum ≈ 2.8):
  • Baseline 5% → detect +0.5 percentage points (5.0% → 5.5%): ~31k users per arm (total ~62k). (calculation using the formula above).
  • Baseline 10% → detect +1 percentage point (10% → 11%): ~14.7k users per arm (total ~29.4k).
  • Baseline 10% → detect +2 percentage points: ~3.7k users per arm (total ~7.4k).

Those orders-of-magnitude numbers match what industry calculators report and demonstrate why teams set realistic MDEs rather than chasing micro-lifts via enormous samples. Use a reputable sample size calculator or statsmodels to produce exact numbers for your setup.

Python example using statsmodels (practical snippet):

# Python (statsmodels)
from statsmodels.stats.proportion import proportion_effectsize
from statsmodels.stats.power import NormalIndPower

p_control = 0.10
p_treatment = 0.11   # absolute rates (10% -> 11%)
effect = proportion_effectsize(p_treatment, p_control)  # arcsin transform
alpha = 0.05
power = 0.8

analysis = NormalIndPower()
n_per_group = analysis.solve_power(effect_size=effect, alpha=alpha, power=power, ratio=1)
print(f"Required users per arm: {int(n_per_group):,}")

(See the statsmodels docs for proportion_effectsize and NormalIndPower usage.)

Practical caveats that change your N:

• Clustering (randomizing by account or household) increases required sample size via the design effect; multiply N by 1 + (m − 1)ρ where m is cluster size and ρ is ICC.
• Correlated metrics and repeated measures require paired or longitudinal power approaches.
• Long-tailed revenue → use transformations, robust estimators, or trimmed-mean approaches and power calculations aligned with those estimators.
• Short test windows relative to business cycles cause bias; plan for full cycles.

Industry calculators like Evan Miller’s A/B tools are helpful sanity checks and make clear how baseline and MDE interact with power and N.

Avoiding the usual statistical traps: peeking, multiple comparisons, and p-hacking

Peeking (continuous monitoring)

• Repeatedly checking classical fixed‑sample p‑values inflates the Type I error — a 5% nominal alpha quickly becomes tens of percent if teams stop the test the first time it crosses p < 0.05. Simulations and applied research document this effect in A/A and A/B settings.
• Modern practice: either lock a fixed‑horizon plan (precompute sample size and only analyze at the end) or use sequential / always-valid methods (mSPRT, alpha‑spending, or always‑valid p‑values) that control Type I error under continuous monitoring. The literature and commercial engines (e.g., Optimizely’s Stats Engine) describe implementations and trade-offs between speed and sample efficiency.

Multiple comparisons

• Running many metrics or many variants multiplies your false positive risk. Traditional control is FWER (Bonferroni/Holm); modern experimentation at scale often uses FDR (Benjamini–Hochberg) to preserve power while limiting the expected proportion of false discoveries. Choose the correction strategy that matches your decision framework: strict FWER control if any false positive is catastrophic; FDR if you tolerate some false discoveries in exchange for higher detection power.

P‑hacking and researcher degrees of freedom

• Undisclosed flexibility in stopping rules, data exclusions, covariate specifications, and outcome definitions can elevate false positive rates dramatically. The empirical work on “False‑Positive Psychology” shows how easy it is to manufacture apparent significance through analytic flexibility; the ASA also warns about misuse and misinterpretation of p‑values. Pre-registration of your metric, analysis plan, and stop rules removes the main sources of p‑hacking.

Operational controls to stop these traps (methods referenced above):

• Pre-register: primary metric, unit of analysis, MDE, alpha, power, and stopping rule.
• Use sequential testing frameworks when you must peek; use fixed-horizon tests when you cannot.
• Apply multiplicity control for many simultaneous tests or hierarchical testing with gating.
• Report effect sizes and confidence intervals, not just p‑values (see next section).

[Citations: Optimizely on sequential/frequentist tradeoffs; Johari et al. on always‑valid inference; Benjamini & Hochberg on FDR; Simmons et al. and ASA on p‑value misuse.]

Reading results: statistical significance, practical significance, and communicating uncertainty

Statistical significance is only one input to a decision. Your output to stakeholders should emphasize three things in this order: (1) point estimate (effect size), (2) uncertainty (confidence or credible intervals), and (3) business interpretation (what that effect means for revenue, retention, or cost).

• Prefer effect size + interval over a lone p value. A 95% CI that contains trivial harms and meaningful gains tells a different story than a p = 0.04 line in your scoreboard. The “New Statistics” approach—effect sizes and CIs—provides a clearer decision signal.
• Distinguish statistical significance from practical significance. A 0.2% lift on a 10M monthly active user base may be a multi-million dollar outcome and worth shipping; conversely a tiny lift detected on 10M users may be operational noise if it degrades retention or quality.
• Be explicit about uncertainty: show the CI, potential revenue impact ranges, and the probability that the true effect exceeds your business threshold (e.g., P(lift ≥ MDE) = 72%).
• Use graphical communication: forest plots or simple bar charts with CIs and annotated revenue impact translate better to execs than raw tables.

Report card layout I use:

• Primary metric: effect (absolute and relative), 95% CI, p (for transparency), and probability of exceeding MDE.
• Guardrails: same layout, but call out any breaches.
• Power post hoc: if the test is inconclusive, report the achieved power for the prespecified MDE (or the MDE you could detect given the realized N).

[Cite: Cumming and Bayesian New Statistics literature for emphasis on estimation and intervals.]

A step-by-step checklist to run well-powered, trustworthy experiments

Below is a compact, actionable checklist and templates I expect on an experimentation platform’s experiment creation flow. Use it as a gating checklist before the experiment launches.

1) Hypothesis & metric lock

• Hypothesis: one sentence (change → expected direction → rationale).
• Primary metric: exact name, numerator, denominator, unit of analysis.
• Secondary metrics & guardrails: explicit list and thresholds.

2) Pre-registration fields (fill before launch)

experiment_id: EXP-2025-1234
title: 'New CTA copy on checkout'
hypothesis: 'Changing CTA will increase purchase rate by X'
primary_metric:
  name: 'purchase_within_7d_per_exposed_user'
  numerator: 'users with purchase in 7 days'
  denominator: 'unique users exposed to variant'
unit_of_analysis: 'user_id'
alpha: 0.05
power: 0.8
MDE_absolute: 0.01   # 1 percentage point
allocation: {control: 0.5, treatment: 0.5}
stopping_rule: 'fixed-horizon; analyze at N per arm or >=7 days, whichever comes later'
guardrails:
  - metric: 'app_crash_rate'
    threshold: '+0.5pp relative'
  - metric: 'median_page_load_ms'
    threshold: '+100ms absolute'

3) Sample size & runtime calculation

• Compute N per arm using a validated calculator or statsmodels.
• Check arrival rate and ensure N can be collected without confounders; estimate calendar time and include at least one full business cycle.

4) Instrumentation & quality checks

• Verify exposure logging, deduping by user_id, event schema, and timestamp alignment.
• Add automated SRM (Sample Ratio Mismatch) and log smoke checks pre-launch.

5) Run guardrail monitoring

• Configure automated alerts for guardrails (e.g., Slack/email) for early operational failures (not for deciding statistical significance).
• If a guardrail breach is operational (e.g., crash spike), pause the experiment immediately.

6) Analysis & decision

• Use the pre-registered analysis method (fixed-horizon or sequential). If sequential, use always-valid procedures; if fixed, only analyze after conditions met.
• Report effect size, CI, p (for transparency), probability of exceeding MDE, and guardrail outcomes.
• Decision rule is based on the pre-specified threshold and guardrail status (ship/iterate/stop).

7) Documentation & learning

• Publish the experiment record with results, instrumentation notes, and next steps. Capture negative results—they are as valuable as positive ones.

Quick reference table — sample size realities

(Use these as planning orders of magnitude; compute exact N with your instrumented calculator.)

Sources

Type I and Type II Errors and Statistical Power - StatPearls - Definition of statistical power, relationship between power and Type II error, and factors (effect size, variance, sample size, alpha) that determine power.

Sample Size Calculator (Evan’s Awesome A/B Tools) - Practical calculators and discussion of MDE, baseline, and how sample sizes explode for small absolute lifts.

statsmodels — Power and Sample Size Calculations (TTestIndPower) - API and examples for programmatic power analysis using statsmodels.

Two-proportion Z-test (Wikipedia) - Standard formula for two‑sample proportion tests and sample size derivations used in power/sample size calculations.

Statistical analysis methods overview — Optimizely Support - Explanation of fixed‑horizon versus sequential analysis methods, guardrails, and practical platform trade-offs.

Always Valid Inference: Bringing Sequential Analysis to A/B Testing (Johari et al., arXiv / Operations Research) - Theoretical and practical methods for always‑valid p‑values and sequential tests suitable for continuous monitoring.

Controlling the False Discovery Rate: A Practical and Powerful Approach to Multiple Testing (Benjamini & Hochberg, 1995) - The original FDR procedure and discussion of power advantages over strict FWER methods.

American Statistical Association: Statement on Statistical Significance and P-values (2016) - Principles describing the limits of p‑values and recommendations for reporting and inference.

False-Positive Psychology: Undisclosed flexibility in data collection and analysis allows presenting anything as significant (Simmons, Nelson & Simonsohn, 2011) - Demonstration of how undisclosed analytic flexibility inflates false positives and recommendation to pre-register.

Why Most Published Research Findings Are False (Ioannidis, 2005) - Discussion of publication bias, low power, and structural drivers of high false positive rates in published research.

Understanding and implementing guardrail metrics — Optimizely blog - Practical guidance for defining guardrails and integrating them into experiment scorecards.

statsmodels.stats.proportion.proportion_effectsize — statsmodels documentation - The proportion_effectsize function and the arcsine transform used for power calculations on proportions.

Understanding The New Statistics: Effect Sizes, Confidence Intervals, and Meta-Analysis (Geoff Cumming) - Advocacy of estimation (effect sizes + CIs) over ritualized null hypothesis significance testing and concrete communication patterns for uncertainty.