🚧

BETA

Bucketing IDs are a beta feature intended to support customers who want to assign variations with a different identifier than they use to count visitors. For example, a company might want to assign variations by account ID while counting visitors by user ID. We're investigating the implications of bucketing IDs on results analysis, and we would love to have your feedback! If you want to participate in this beta release, please [contact support](🔗).

By default, Optimizely assigns users to variations (in other words, [Optimizely _buckets_ users](🔗)) based on submitted user IDs. You can change this behavior by including a bucketing ID.

With a bucketing ID, you decouple user bucketing from user identification. Users who have the same bucketing ID are put into the same bucket and are exposed to the same variation. The bucketing ID serves as the seed of the hash value used to assign the user to a variation. Users with the same bucketing ID share the same hash value, which is why they are exposed to the same variation. For more information, see [How bucketing works in Full Stack](🔗).

Bucketing IDs are implemented as a reserved [attribute](🔗) that you can use when activating an experiment or evaluating a feature flag. The example shows how to include a bucketing ID—send the `$opt_bucketing_id` attribute in the `attributes` parameter of the [Activate](🔗), [Is Feature Enabled](🔗), [Get Feature Variable](🔗), and [Track](🔗) methods.

Using a bucketing ID does not affect the user ID. Event data submissions will continue to include user IDs. With the exception of assigning users to specific variations, features that rely on user IDs behave the same regardless of the presence of a separate bucketing ID. If you do not pass a bucketing ID to the `attributes` parameter, users are bucketed by user IDs, which is the default method.

📘

Notes

• The bucketing ID is not persisted.

• Bucketing IDs are only supported for [feature tests](🔗) and [A/B tests](🔗), not [rollouts](🔗).