Control and variant in experiments
In an experiment the control is the existing version that acts as the baseline, and the variant is the version carrying the one change you are testing. Comparing the two only yields a clean answer when assignment is random and the variant differs from the control in exactly one way. Multiple variants are possible but each must be isolated.
What this means
The control is the current experience, left unchanged, serving as the reference point. The variant is the same experience with one deliberate change. Because both run at the same time on randomly assigned traffic, anything affecting them both — a holiday, a traffic spike, a press mention — affects the control too and cancels out of the comparison.
Keeping the comparison clean
Isolate one change per variant so a difference has a single cause. If you run several variants (A/B/n), each adds a comparison and raises the chance of a false positive, so account for that. Never compare a variant to a control from a different time period — the whole point of a concurrent control is to neutralise time-based shifts.
A broken or contaminated control (for example, users leaking between arms) invalidates the experiment, so guard assignment integrity.
- Control = unchanged baseline running concurrently
- Variant = one isolated change
- More variants means more false-positive risk to manage
How it appears in analytics and logs
A control absorbs everything that changes over time (seasonality, traffic mix) so the variant comparison reflects the change alone. Without a concurrent control, an apparent effect may just be a time trend.
Diagnostic use case
Keep an unchanged control running alongside each variant so the comparison measures your change, not background shifts in traffic or season.
What WebmasterID can help detect
WebmasterID measures the conversion events each arm produces first-party, so you can compare control and variant without cross-site tracking.
Common mistakes
- Comparing a variant to a control from another time period.
- Putting more than one change into a single variant.
- Letting users leak between control and variant.
Privacy and accuracy notes
Control and variant assignment is a random bucket plus aggregate counts, not identity. WebmasterID reads the outcome events first-party.
Related pages
- A/B testing fundamentals
An A/B test randomly assigns visitors to a control (A) or a variant (B), shows each group one version, and compares a pre-chosen metric. Random assignment is what lets you attribute a difference to the change rather than to who happened to see it. The discipline is in deciding the metric and sample size before you start, not after you peek at the numbers.
- Multivariate testing
Multivariate testing (MVT) changes several elements simultaneously and tests their combinations, so it can reveal interactions between elements that separate A/B tests miss. The cost is traffic: the number of combinations grows quickly, so each gets a thin slice of visitors. MVT is worth it only when you have ample traffic and genuinely suspect interactions.
- Guardrail metrics in experiments
Guardrail metrics are the secondary measures you monitor during an experiment to make sure a change that improves the primary metric does not quietly damage something important — load time, retention, refunds, support load. They turn 'did the target go up' into the fuller question 'did the target go up without breaking anything'.
- Event Explorer
Compare outcome events between arms.
Sources and verification notes
- Google — Experiment objectives and variantsOptimize is sunset; the control/variant concept documentation remains a primary reference.
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.