Skip to content
AI.info

Evaluation

Online Controlled Experiments and A/B Testing

Design online experiments with valid randomization units, sample-ratio checks, guardrails, power, interference analysis, and long-term interpretation.

By the end you can

An online experiment estimates a policy difference

An A/B test does not ask whether one model predicts labels better. It asks what happens when eligible units are randomly assigned to different product experiences.

For one week, from 11 to 18 January 2012, Facebook randomly assigned 689,003 users to News Feeds with either less positive or less negative content. The result appeared in PNAS in 2014. “We show, via a massive (N = 689,003) experiment on Facebook, that emotional states can be transferred to others via emotional contagion, leading people to experience the same emotions without their awareness,” the study's three authors wrote in its significance statement. Nobody was surveyed. Nobody was asked. The feed itself was the instrument. The difference between the arms was the difference between two versions of the product.

The same paper is the standard warning about what randomization does not license. It drew a formal editorial expression of concern over informed consent. Cornell, confirming its two co-authors, Jeffrey Hancock and Jamie Guillory, stated that the researchers never saw the content of actual posts. Randomization supports a counterfactual comparison only when assignment, exposure, measurement and analysis follow the design. And only within what the assigned units have agreed to.

An experiment evaluates the intervention created by the system, not the model in isolation.

Case

One idea in three: an experimentation platform reports its own hit rate

Microsoft published its own hit rate in 2009. Of well-designed experiments meant to improve a key metric, “only about one-third were successful at improving the key metric”. A 2013 paper from the same team repeats the figure, and reports Bing running over 200 concurrent experiments on a given day. Most ideas fail.

Visual

The experimental chain

Eligibility, random assignment, exposure, outcome measurement, analysis. A break in any link invalidates the comparison, and link two is the one that fails without a visible symptom.

Assignment is not a fresh start. Microsoft ran a 7-day A/A check, then a 47-day A/B experiment, then kept watching the same buckets after the experiment was over. The carryover effect only died out around the third week after the experiment ended. In a second case the buckets had not recovered after three months.

Google measured the same shape from the other side. Jake Brutlag injected server-side delay into search and reported the aftermath in 2009: “Users exposed to the 400 ms delay for six weeks did 0.21% fewer searches on average during the five week period after we stopped injecting the delay.” The delay was gone. The users were not the same users.

That is what an A/A test is for. Microsoft's mitigation was re-randomizing the bucket system between experiments. A unit carries the last experience it was given into its next assignment. The chain has to be rebuilt, not merely re-pointed, before the next comparison is read.

FigureProcess · 5 steps
  1. 1. Eligibility

    Define which users, sessions, tenants, or devices can enter the experiment.

  2. 2. Random assignment

    Assign units to control or treatment using a stable mechanism.

  3. 3. Exposure

    Confirm which experience each unit actually received and for how long.

  4. 4. Outcome measurement

    Compute primary and guardrail metrics from comparable instrumentation.

  5. 5. Analysis

    Estimate effects, uncertainty, heterogeneity, and experiment-integrity checks.

Comparison

Randomization and analysis units must fit the interaction

Choosing a convenient row can violate independence, and the size of that violation is measurable rather than rhetorical.

LinkedIn ran a cluster-randomized network A/B test on the Netherlands sub-network: about 6.1 million users, average internal degree 93.0. It split that network into 600 shards, 300 assigned to treatment and 300 to control. They ran for two weeks, after an A/A check. The average treatment effect on social gestures was 0.168 under the SUTVA assumption, which holds that each user's outcome depends only on that user's own assignment. Under exposure models that allow spillover, the same experiment gave 0.264 to 0.714. “The ATE estimates with consideration of network effect are all larger than the estimate under SUTVA,” the 2015 paper reports. The user-level number was not noisy. It was low, and by how much depended entirely on which assumption was being made about the network.

Facebook built its own cluster-randomized framework for the same reason: one “that accounts for interference between experimental units”, with two case studies that “capture significant network effects”. Cluster randomization costs independent units and demands cluster-aware variance. User randomization costs an unknown amount of the effect whenever the users talk to each other.

FigureComparison · 4 columns

User randomization

One user remains in one variant across sessions.

  • Good for repeated experience
  • Supports user-level outcomes
  • Needs identity stability
  • Can have cross-user spillover

Session randomization

Each session can receive a different variant.

  • Fast exposure
  • Useful for transient changes
  • Can contaminate learning
  • Not suitable for persistent state

Cluster randomization

Assign stores, households, teams, or regions together.

  • Reduces interference
  • Fewer independent units
  • Requires cluster-aware variance
  • Can create imbalance

Request randomization

Assign individual calls or queries.

  • High sample count
  • Useful for stateless backend tests
  • Ignores repeated-user effects
  • Can create inconsistent experiences

Example

How long is long enough: a 60-day half-life

A two-week read is not a small version of the long-term result. It is the first few percent of a curve whose timescale has been measured.

  • Measured learning: Google fitted an exponential model to ads blindness and published the timescale in 2015. “The half-life of learning ln(2)/β was approximately 60 days (see Figure 3), or β ≈ 0.012 per day.”
  • Study length: That half-life sets the calendar rather than the release schedule — “we now typically run long-term desktop experiments for 90 days”, and even 90 days capture only about 65% of the eventual effect.
  • The other direction: Microsoft found the same slowness after a bad experience, reporting that “Even after three months, the user buckets still had not fully recovered to their pre-experiment levels.”
  • What a fortnight can show: novelty in a changed interface, a guardrail such as skip rate moving against the headline metric, and household accounts mixing treatment and control — all real, all read at day fourteen of a mechanism with a 60-day half-life.
  • Decision: Treat the short-term number as the start of that curve. Extend the test, run the long-term arm, or hold the rollout until the timescale of the mechanism has actually elapsed.

Key idea

Sample-ratio mismatch is a smoke alarm

If observed assignment counts differ materially from the expected allocation, the cause may be a randomization bug, logging loss, eligibility asymmetry, filtering after assignment, or treatment-induced missingness.

Do not interpret outcome metrics before diagnosing sample-ratio mismatch. The issue can signal that treatment and control no longer represent comparable populations.

A statistically significant product metric is meaningless if experiment assignment is broken.

Case

Sample-ratio mismatch as a fever, across four companies

Sample-ratio mismatch has its own taxonomy, built by Fabijan and colleagues across four software companies and more than 25 products. They describe it in medical terms. “Just like fever is a symptom for multiple types of illness, an SRM is a symptom for a variety of data quality issues.” Ignoring one can ship a bad change as a good one.

Power begins with the smallest effect that matters

Sample-size planning requires the baseline variance, randomization unit, expected traffic, target effect, significance policy, and desired power. Designing only for statistical detectability can create tests large enough to find effects too small to justify action.

Traffic is not the only lever, and it is rarely the cheapest. Interleaved evaluation was validated on commercial search logs and published in 2012, measured against the best absolute click metric, Clicks@1. “There is only one pair for which interleaving was less sensitive than Clicks@1. In all others, interleaving was much more sensitive, significantly reducing the number of queries needed by over an order of magnitude,” Chapelle and Joachims report. Airbnb said in 2025 that its interleaving and counterfactual evaluation “increased the sensitivity of experiments by a factor of up to 100 (depending on the approach and metrics) compared to traditional A/B testing”. Same decision, an order of magnitude to a hundredfold less data. The comparison was designed differently.

Variance reduction is the second lever. It has to be specified before the result is read, not chosen after it. Microsoft introduced CUPED in 2013, and the abstract opens with the number: “The results on Bing’s experimentation system are very successful: we can reduce variance by about 50%, effectively achieving the same statistical power with only half of the users, or half the duration.” The conclusion gives the individual experiments — “variance reductions of 45%, 52% and 49% with one week of experiment and one week of pre-experiment data”. ShareChat deployed the same family of adjustments and reported in 2024 that “we can either improve A/B-test confidence in 77% of cases, or can retain the same level of confidence with 30% fewer data points”. Neither lever needs one extra user.

Power analysis should start from a decision-relevant effect, not from available traffic alone.

Steps

Run a trustworthy online experiment

Precommit the design and monitor integrity from launch. Step one is where most of the trouble is avoided: naming the mechanism, the primary outcome, the guardrails and the practical threshold. The obvious metric can move the wrong way and still be correctly measured.

Microsoft published one such case in 2012. “When Bing had a bug in an experiment, which resulted in very poor results being shown to users, two key organizational metrics improved significantly: distinct queries per user went up over 10%, and revenue per user went up over 30%!” Degrading the product raised both headline numbers, because a user who cannot find an answer searches again. Google's mobile ad-load cut ran the other way. Its own 2015 paper reports that “Reducing the mobile ad load strongly improved the user experience but was a substantially short-term revenue negative change; with our work, the long-term revenue impact was shown to be neutral.” One change looked good and was not. The other looked bad and was not.

Neither case is settled by better statistics on the metric that moved. Both are settled by choosing, before launch, which quantity the team has agreed to be steered by. Then validate instrumentation with A/A tests, invariant metrics and sample-ratio monitoring. Analyze effects with intervals and heterogeneity. Decide under a rule written down in advance.

FigureProcess · 5 steps
  1. 1. Write the hypothesis

    Name the mechanism, primary outcome, guardrails, and practical effect threshold.

  2. 2. Choose units

    Align eligibility, randomization, exposure, and analysis with repeated behavior and spillovers.

  3. 3. Validate instrumentation

    Use A/A tests, invariant metrics, logging checks, and sample-ratio monitoring.

  4. 4. Analyze effects

    Report point estimates, intervals, heterogeneity, novelty, and missingness.

  5. 5. Decide and follow up

    Roll out, iterate, stop, or run longer-term confirmation under a documented rule.

Analogy

Two city districts assigned different traffic rules

Drivers do not stay inside the district that was assigned to them. Two comparable districts can be given two traffic policies, and travel time, accidents and spillover into neighboring roads can all be measured. The comparison holds only while the policies stay where they were put.

Traffic engineers cannot hold cars at the district line, and a product team cannot stop one household from sharing an account. Whoever runs the test has to assign at the unit the treatment can actually be kept inside. Otherwise the two arms leak into each other, and the difference between them is not the difference that was tested. LinkedIn's 600 shards are the same move as closing a district to through traffic: expensive, coarse, and the only way to know how much of the effect was crossing the line.

Randomization works at the level where treatment can remain meaningfully separated.

Position

An offline win is a hypothesis about production, not a result

Microsoft published its own hit rate, which is rarer than it should be. Of well-designed and executed experiments that were designed to improve a key metric, only about one third improved that metric. These were not careless ideas. Each was a change some team believed in enough to specify, build, instrument and put behind randomization. About two thirds of them did not improve the metric they were built to improve.

That ratio is the argument against reading an offline gain as a result. An offline comparison asks whether one system predicts labels better. An experiment asks what happens when eligible units are randomly assigned to different experiences. Those are different quantities. The second also has to survive the plumbing: the sample-ratio taxonomy drawn from four software companies and more than 25 products exists because ignoring one mismatch can ship a bad change as a good one. An offline improvement is a good reason to run the test. It is not the outcome of the test, and a release note that treats it as one is reporting a hypothesis.

Even the test itself is a claim about one population, one period and one assumption set. The same LinkedIn experiment gave 0.168, or up to 0.714 once spillover was modelled. The same Bing bug raised queries per user over 10% and revenue per user over 30% while making search worse. What survives is not a number. It is a design that names, in advance, which number would count.

At Microsoft, about two thirds of well-designed experiments did not improve the metric they were designed to improve.

Key takeaways