> ## 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. # Managing membership > Add, remove, and re-share members. Retired vs allocated status. What generation bumps do to running experiments. Activation trigger restrictions. Cloning behavior. Everything you need to run a group day to day. 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](/targeting/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](/build/clone), 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](/team/permissions-catalog). ## Activity log Every group action lands in the [activity log](/team/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. ## Related When to use a group and when not to. The 10,000-slot math and the salt. The killer use case for groups, permanent baseline for measuring cumulative effect.