WebmasterID logoWebmasterID
Conversion & funnels

Traffic allocation in experiments

Traffic allocation decides what fraction of eligible users enter an experiment and how that fraction divides among variants. A 50/50 split between two arms maximises statistical power for a fixed sample; ramping exposure limits blast radius. Allocation is a deliberate trade-off between speed, risk, and the number of variants. This page explains the levers.

Partially verified

Two separate decisions

Allocation has two layers. First, what share of eligible traffic enters the experiment at all (you might expose only 20% while you watch for problems). Second, how that exposed traffic divides across the control and variants. Both affect how fast you can read a result.

Power and the even split

For two arms and a fixed total sample, an equal 50/50 split gives the most statistical power, because power depends on the smaller arm. Skewing traffic toward the variant does not speed up a clean A/B test — it starves the control and slows detection. Uneven splits make sense for other reasons (limiting risk), not for power.

Checking the realised split

The intended allocation and the observed allocation can diverge. A large gap between expected and actual arm sizes is the signature of sample ratio mismatch — often a redirect, caching, or bot-filtering bug that quietly biases the result. Always verify the counts before trusting the readout.

How it appears in analytics and logs

An uneven split or a tiny allocation slows detection. If variant counts are wildly off from the intended split, suspect a sample-ratio-mismatch bug rather than chance.

Diagnostic use case

Choose an allocation that balances power and risk: even splits detect effects fastest for a given total, while small initial exposure limits damage from a bad variant.

What WebmasterID can help detect

WebmasterID's first-party event stream lets you verify how many visitors actually landed in each arm, so you can confirm the realised allocation matches the intended split.

Common mistakes

Privacy and accuracy notes

Allocation assigns visitors to arms, typically by a hashed bucket. It can be done without storing personal identifiers, using a first-party bucketing key.

Related pages

Sources and verification notes

Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.