Why do teammates get different variations?
Last updated:
A rollout buckets by user key by default, and each user hashes independently. Two colleagues in the same workspace count as two separate users, so a 50% rollout splits them roughly half the time. Point the rollout at an account or organization attribute instead, and everyone sharing that value moves together.
The rollout is bucketing people, and your users experience your product as a team.
By default a percentage rollout hashes the individual user key. Two colleagues in one workspace are two independent users, so a 50% rollout puts them on opposite sides of it about half the time. Nothing is misconfigured, and that is exactly the trouble: your configuration describes individuals while the feature gets used by teams.
It arrives as a support ticket that reads like a bug. One person describes a screen their colleague cannot find, same plan, same workspace, same afternoon.
Bucket by the account instead
A rollout can bucket by any attribute in the evaluation context, so it does not have to be the user key. Send the account identifier and point the rollout at it. Getting that attribute into the context in the first place is covered in Targeting and segments.
client.boolVariation('new-workspace-nav', { userId: 'u_8134', account_id: 'acct_204', // the rollout buckets on this plan: 'pro',}, false);Everyone sharing acct_204 now hashes to the same bucket and moves in and out of the rollout together. Your percentage now means 20% of accounts rather than 20% of people, which for most B2B features is what you meant.
Keep sending the user key as well. You still want it for user-level targeting rules, and for anything else that should stay per-person.
What to watch
Account-level rollouts are lumpier than user-level ones. Accounts vary enormously in size, so 20% of accounts might be 5% or 45% of seats depending on which ones fall in. Watch both numbers during a rollout, and expect the user-weighted figure to move in steps as large accounts cross the boundary.
Changing bucketBy on a live rollout reassigns everybody at once, because it replaces one of the two hash inputs. Set it before you start, or accept a full reshuffle at the moment you change it. Rollout strategies covers the bucketing options in full.
When per-user is right
Keep the default for anything a person experiences alone, like interface preferences or individual onboarding. Account grouping earns its place when colleagues collaborate inside the feature, or talk to each other about it.
Related questions
Does changing a targeting rule re-bucket users?
Editing rules, weights or conditions leaves every bucket where it was. Only two changes reassign users, and both are easy to make by accident.
Why doesn't my rollout hit the percentage I set?
A 20% rollout rarely serves exactly 20% of traffic. Bucketing is deterministic per user, so small populations skew and anonymous traffic behaves differently.
Why do two users get different variations?
That is what a percentage rollout does. Bucketing hashes the user ID with the flag key, so the split is per user and per flag, and never lines up across flags.
Still stuck?
The docs cover every SDK, and the free Solo plan is enough to reproduce most of these locally.