> ## Documentation Index > Fetch the complete documentation index at: https://docs.abtestly.com/llms.txt > Use this file to discover all available pages before exploring further. # Exclusion groups overview > Two experiments that touch the same element would produce untrustworthy results if a single visitor could enter both. Mutual exclusion groups partition traffic so at most one member ever fires per visitor. Here is why they exist and when to reach for one. If you have ever tried to run more than one A/B test on the same page, you have hit this problem: what happens when a visitor could enter both? Two headline tests on the same hero. Two CTA-color tests on the same button. Two pricing-page tests, one that changes the top card and one that changes the middle card. A single visitor landing in both means: * **You cannot attribute a lift.** The lift you measure on test A is contaminated by test B's variant, and vice versa. * **The variants may fight.** Test A's variant hides a button that test B's variant depends on. Now both are broken and the failures correlate. * **Your stats overstate confidence.** Two tests running on the same visitors are not two independent samples; they are one entangled sample. A **mutual exclusion group** is the fix. Add the interacting experiments to a group, and ABTestly guarantees that each visitor is assigned to **at most one member of the group**. The rest are skipped for that visitor. Exclusion groups ## The one-sentence pitch An exclusion group is a way to say: "these experiments are running in the same space; make sure no visitor sees more than one of them." ## When to reach for one Two tests that mutate the same hero, the same CTA, the same pricing card. If both applied, the DOM would be nondeterministic. Two tests on the checkout page. Even if they touch different elements, they both measure conversion at the same step and entangled results are hard to unwind. You want to test hypothesis A against control **and** hypothesis B against control at the same time, but they are alternatives. you would never ship both. You want a permanent slice of traffic that sees the original forever, so you can measure long-tail effects on retention. See [holdouts](/exclusion-groups/holdouts). ## When *not* to use one * **Tests on different pages.** A homepage test and a pricing-page test do not need a group; they cannot collide because the Location rules keep them separate. * **Tests on different audiences.** A mobile-only test and a desktop-only test cannot collide because Audience rules already separate them. * **A single test with a control.** That is just an experiment with Variant A and Original; no exclusion group needed. Reach for a group **only when** a visitor could plausibly qualify for both and the outcomes would tangle. ## What you get in return Once experiments are in a group, ABTestly: * **Deterministically assigns** each visitor to at most one member, before either experiment's own bucketing runs. * **Skips the losers silently**, visitors excluded from your test see the original page. No confusing "was I in the test or not?" states. * **Enforces the guarantee across page loads**, the assignment sticks. A visitor bucketed to member A on page one stays on member A on page two. * **Stamps a generation counter** on every exposure so results pages can tell you if group membership changed mid-experiment. ## The moving parts Three concepts show up on every group page: * **Shares**, how many of the group's 10,000 slots each member owns. See [how allocation works](/exclusion-groups/how-it-works). * **Unallocated space**, 10,000 minus the sum of member shares. Visitors landing there see none of the group's experiments; useful for holdout cells. * **Generation**, a counter that increments whenever you change membership. Bumping it re-dices every visitor into fresh slots. ## Where to go next The 10,000-slot bucketing space, the salt, and how membership is deterministic across pageviews. Reserve a slice of traffic that sees the original forever, to measure long-tail effects. Adding members, retiring vs allocated status, cloning behavior, activation trigger restrictions.