Why do teammates get different variations?
Last updated:
Because a rollout buckets by user key by default, and each user hashes independently. Two colleagues in the same workspace are two separate users, so a 50% rollout splits them roughly half the time. Set the rollout to bucket by an account or organization attribute instead, and everyone sharing that value moves together.
Because 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. Everything here is working as configured, which is precisely the trouble, because the configuration describes individuals and the feature is used by teams.
This shows up as support tickets that read like a bug: one person describes a screen their colleague cannot find, on the same plan, in the same workspace, on the same day.
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.
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.
When per-user is right
Keep the default for anything a person experiences alone. Interface preferences, individual onboarding, personal notification changes. The account grouping matters when colleagues collaborate inside the feature or talk to each other about it.
Bucketing options are covered in Rollout strategies, with attribute targeting in Targeting and segments.
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.