Exclusion Layers
Prevent users from being in multiple experiments at once.
Why Exclusion Matters
When a user is in two experiments at the same time, it becomes very difficult to know which experiment caused a change in their behavior. If a user is simultaneously seeing a new checkout flow and a new pricing structure, and they convert at a higher rate, which change deserves the credit? The answer is: you cannot tell. The experiments have contaminated each other's results.
This problem — called an interaction effect — is one of the most common reasons experiment results become unreliable. Exclusion layers solve it by ensuring that any given user can only participate in one experiment within a defined group.
What Layers Are
An exclusion layer is a named group of experiments. The rule is simple: a user can only be in one experiment per layer. When a user is assigned to an experiment in a layer, they are automatically excluded from all other experiments in that same layer.
If a user encounters a second experiment in the same layer, they are not assigned to it — instead, they see the flag's default variation. Their original assignment is preserved and stable.
How to Use Layers
Using exclusion layers involves two steps:
- Create a layer with a descriptive name that reflects the group of experiments it will contain (for example, "Checkout Flow" or "Pricing Experiments").
- Assign experiments to the layer when creating or editing an experiment. Any experiment assigned to the layer will respect the mutual exclusion rule.
Once assigned, the exclusion check happens automatically at assignment time. You do not need to manage individual user assignments or manually track who is in which experiment.
When to Use Layers — and When Not To
Not every experiment needs an exclusion layer. Layers are most valuable when you have concurrent experiments that could realistically influence each other's results. Here are some guidelines:
| Situation | Recommendation |
|---|---|
| Two experiments that change the same part of the product (e.g., two checkout flow tests). | Use a layer. These experiments directly interact and will confound each other's results. |
| Experiments in completely different areas (e.g., a homepage test and a settings page test). | No layer needed. These are unlikely to interact. |
| You are running your first experiment and have no concurrent tests. | No layer needed. Exclusion only matters when there is something to exclude from. |
| You are scaling up and running many experiments in parallel. | Use layers strategically. Group experiments by product area to keep results clean while maximizing the number of tests you can run. |
Example Layering Strategy
A common approach is to organize layers by the area of your product they affect. This lets you run many experiments simultaneously while ensuring that experiments that could interact are kept separate:
| Layer | Example Experiments | Why They Need Exclusion |
|---|---|---|
| UI / Layout | Header redesign, navigation changes, new dashboard layout | Multiple visual changes interact unpredictably and confound user experience metrics. |
| Pricing | Discount strategies, pricing tier changes, free trial length | Pricing experiments directly affect revenue metrics and must be measured in isolation. |
| Performance | CDN configuration, image compression, caching strategies | Multiple performance changes make it impossible to attribute speed improvements to a single change. |
| Onboarding | Welcome flow, tutorial steps, first-run experience | Onboarding changes compound, making activation and retention metrics unreliable. |
Experiments in different layers can overlap freely. A user can be in one UI experiment, one pricing experiment, and one performance experiment at the same time — because those experiments affect different parts of the product, they are unlikely to interfere with each other.