Configure Mutual Exclusion
Why mutual exclusion matters
Section titled “Why mutual exclusion matters”When two experiments modify the same page or feature, a visitor could end up in both simultaneously. If the checkout experiment changes the CTA button and the pricing experiment changes the price display, their effects intertwine. You cannot isolate which experiment caused the observed behavior. Mutual exclusion solves this by partitioning traffic so each visitor enters at most one experiment in the group.
How mutual exclusion works
Section titled “How mutual exclusion works”A mutual exclusion group divides 100% of traffic into non-overlapping slices. Each experiment in the group receives its own slice. A visitor is bucketed into the slice first, then into the experiment’s variation within that slice.
Example: A group with three experiments, each allocated 30% of traffic:
- Visitors in the 0–30% slice see Experiment A
- Visitors in the 30–60% slice see Experiment B
- Visitors in the 60–90% slice see Experiment C
- Visitors in the 90–100% slice see none of the experiments
The remaining 10% acts as a holdout — useful for measuring the combined effect of all three experiments.
When to use mutual exclusion
Section titled “When to use mutual exclusion”| Scenario | Use mutual exclusion? |
|---|---|
| Two experiments on the same page element | Yes — Direct conflict |
| Two experiments on different pages | No — No interaction risk |
| A checkout experiment and a homepage experiment | Maybe — Only if you suspect cross-page influence |
| Experiments targeting different audience segments | No — Natural separation already exists |
Create a mutual exclusion group (Web Experimentation)
Section titled “Create a mutual exclusion group (Web Experimentation)”- Navigate to Experiments > Exclusion Groups in the left sidebar
- Click Create Exclusion Group
- Name the group (e.g., “Checkout page experiments Q2 2026”)
- Click Add Experiment and select experiments to include
- Allocate traffic percentages to each experiment — the total must not exceed 100%
- Click Save
Adjust traffic allocation
Section titled “Adjust traffic allocation”You can change allocations after creation without resetting the experiment:
- Open the exclusion group
- Drag the allocation sliders or type exact percentages
- Click Save — changes take effect within minutes
Important: Reducing an experiment’s allocation removes visitors from the experiment. Those visitors will not re-enter even if you increase the allocation later, because Optimizely preserves bucketing consistency.
Create a mutual exclusion group (Feature Experimentation)
Section titled “Create a mutual exclusion group (Feature Experimentation)”- Navigate to Experiments > Exclusion Groups
- Click Create Group
- Name the group
- Add experiments by selecting them from the dropdown
- Set the traffic allocation for each experiment
- Click Save
For Feature Experimentation, mutual exclusion applies to the SDK-level bucketing. The SDK reads the group configuration from the datafile and partitions the user’s murmurhash into the correct slice.
Design your traffic allocation
Section titled “Design your traffic allocation”Allocating traffic across a group requires balancing speed (more traffic per experiment) against breadth (more experiments running concurrently).
| Approach | Trade-off |
|---|---|
| Equal split (e.g., 33/33/33) | Fair but slower per experiment |
| Weighted split (e.g., 50/30/20) | Prioritizes the highest-impact experiment |
| With holdout (e.g., 40/40/20 holdout) | Measures the combined effect but reduces experiment traffic |
Tip: If your site has 100,000 weekly visitors and you allocate 25% to an experiment, that experiment receives roughly 25,000 visitors per week. Check that this volume reaches significance within your desired timeframe.
Manage the group lifecycle
Section titled “Manage the group lifecycle”Add an experiment to an existing group
Section titled “Add an experiment to an existing group”- Open the exclusion group
- Click Add Experiment
- Reduce existing allocations to free up traffic for the new experiment
- Assign traffic to the new experiment
- Save
Remove an experiment from a group
Section titled “Remove an experiment from a group”- Open the exclusion group
- Click the remove icon next to the experiment
- Optionally redistribute the freed traffic to remaining experiments
- Save
The removed experiment becomes a standalone experiment. If it is still running, it will now receive traffic independently and may overlap with remaining group experiments.
End a group
Section titled “End a group”When all experiments in the group are complete:
- Archive completed experiments individually
- Delete the exclusion group — this has no effect on archived experiment data
Troubleshooting
Section titled “Troubleshooting”| Issue | Cause | Fix |
|---|---|---|
| Experiment getting less traffic than expected | Exclusion group allocation limits total visitors | Increase the experiment’s slice in the group |
| Visitor in two experiments from the same group | Rare bucketing edge case during config propagation | Wait 5 minutes after saving and verify with preview |
| Cannot add experiment to group | Experiment is already in another exclusion group | Remove it from the other group first — an experiment can belong to only one group |
| Results show unexpected interactions | Experiments not in the same group but on overlapping pages | Add both experiments to a mutual exclusion group |
Best practices
Section titled “Best practices”- Plan groups before launching experiments. Adding a running experiment to a group resets its traffic allocation.
- Keep groups focused. Group experiments that genuinely conflict, not every experiment in the project.
- Reserve holdout traffic. A 10-20% holdout lets you measure the aggregate impact of all experiments in the group.
- Document group membership. Maintain a shared record of which experiments belong to which groups so team members do not create conflicting tests.