Skip to main content
Once a group exists, day-to-day management is small but the consequences add up. This page is the reference for what each action does to the visitors who are already bucketed.

Adding a member

Site → Exclusion groups → open the group → Add member. Pick an experiment from the eligible list. Set its share. Adding a member:
  • Bumps the generation counter. Every visitor is re-diced into fresh slots.
  • Takes slots away from unallocated space first, if there is any. If your group has 2,000 unallocated slots and you add a 1,500-slot member, unallocated becomes 500 and every existing member keeps their shares.
  • If unallocated cannot cover the new share, existing member shares shrink proportionally. The dashboard warns you before saving.
Members can be draft, scheduled, or live. A member added when draft simply becomes eligible for the group’s slots the moment it goes live.

Which experiments are eligible?

Under the “Add member” picker, only experiments on the same site that are not currently in another group show up. An experiment can be a member of at most one group at a time. An experiment with an activation trigger other than On load (click / when visible / manual) is disabled in the picker. Exclusion groups decide membership at page load; a click or manual activation would break the “at most one” guarantee. See activation triggers for the modes.

Retiring a member

Retire on the member row (not Delete). Retiring:
  • Sets the member’s status to retired.
  • Releases its slots to unallocated space.
  • Does not archive the experiment. The experiment keeps collecting from any visitor already in-flight.
Retired members stay visible in the group so you can see the history. You can re-activate a retired member later (their share picks up from wherever the free slots are now).

Removing a member

Remove deletes the member from the group entirely. The experiment is not archived; it just leaves the group. Its bucketing now runs independently of the group. If you re-add it later, it starts fresh with whatever share you give it.

Changing a member’s share

Click the share number to edit. Changing a share:
  • Bumps the generation.
  • Re-dices every visitor. Some visitors who were on member A may now be on member B or in unallocated space.
  • If the new total exceeds 10,000, the dashboard refuses to save until you reduce another member’s share.

Reordering members

Members are listed in a visible order. That order determines which slot ranges each member owns, the first member gets slots 0 through (share-1), the next gets slots share through (share+next.share-1), and so on. Reordering (drag to reorder) bumps the generation and re-dices every visitor. Not something you do casually; the results page will show a “membership changed” note.

Generation bumps, what to expect

The generation counter is stamped on every exposure event (gn). When it changes, the results page shows a note. Your primary goal metrics may show a step-change at the generation bump, some visitors switched to a different arm. Best practice for a running experiment: don’t change group membership unless you have to. Add new members before the current tests start collecting, or wait for current tests to finish before adding new ones. If you must add mid-flight, the effect on statistical validity depends on how much of your traffic was re-diced. A generation bump that moves 5 % of visitors is more forgivable than one that moves 40 %.

Cloning does not carry group membership

When you clone an experiment, the clone is not added to the group even if the original was. This is deliberate. group membership is an intentional decision, and silent expansion would surprise you. If you want the clone in the group too, add it manually after cloning.

Archiving a member

Archiving an experiment that is a group member automatically retires its group membership first. The archived experiment still shows in the group’s history but no longer takes slots. Unarchiving does not automatically re-add to the group. membership was retired at archive time and stays that way.

Deleting a group

Delete group at the top of the group page. Every member is released back to independent bucketing (as if they had never been in the group). The experiments themselves are not affected. Cannot be undone, the group’s history (generations, membership changes, salt) is gone. If you might want to re-create a similar group later, retire the members instead and archive the group.

Permissions

Managing groups requires the Exclusion groups permission key. See permissions catalog.

Activity log

Every group action lands in the activity log: create, delete, add member, remove member, retire, share change, generation bump. Filter by group id to see the group’s full history.

Common failure modes

Two experiments on the same button, and only one is in the group. The one in the group is protected; the one outside is not. Add both. Adding a mid-flight test to a group with existing members. The existing members’ visitors get re-diced. If they were about to declare a winner, the sample split changes and the verdict may shift. Either wait or accept the disruption. Group of one member. Doesn’t do anything useful, a group of one is just an experiment. Add a second member or delete the group. Group of ten members with 5 % shares each. Every member is getting 5 % of traffic. Some tests will never reach significance in a reasonable time. Consider fewer members with bigger shares, or a faster cadence of rotating members through smaller groups.

Overview

When to use a group and when not to.

How allocation works

The 10,000-slot math and the salt.

Long-term holdouts

The killer use case for groups, permanent baseline for measuring cumulative effect.