- Understand how Optimizely's underlying bucketing logic works in the Fullstack/Mobile SDKs
Optimizely uses a MurmurHash function in each SDK to determine whether a user should be bucketed into an experiment, and which variation the user should be assigned to. If your experiment conditions don’t change while the experiment is running, this hashing guarantees that users cannot switch variations mid-experiment.
This article applies only to users who have not implemented Optimizely's user profiles feature.
Optimizely's bucketing algorithm intelligently deals with cases where traffic allocation or traffic distribution is changed mid-experiment.
For example, imagine you are running an experiment with two variations (A and B), with an experiment traffic allocation of 40%, and a 50/50 distribution between the two variations. Optimizely will assign each user a number between 0 and 10000 to determine whether they qualify for the experiment, and to which variation they should be assigned. If they are in buckets 0 to 2000, they will fall into variation A; if they are in buckets 2000 to 4000, they will fall into variation B. These bucket ranges are deterministic, i.e. if a user falls in bucket 1083, they will always be in bucket 1083.
In this example, if the experiment allocation is changed, Optimizely guarantees that all variation bucket ranges are preserved whenever possible to ensure that users will not be re-bucketed into other variations.
If you expect that experiment conditions may change mid-experiment (e.g., you change an audience or change the distribution of traffic between variations), then you can use user profiles to guarantee that bucketing is sticky. For more information on user profiles, visit the Optimizely developer docs.