Hi all, We are using growthbook to run experiments using feature flags and have 3 different environments setup (3 separate SDK connections, all Javascript ones). We now wish to enable sticky bucketing feature for which we have implemented the steps 1,2 and 3 given in this doc - https://docs.growthbook.io/app/sticky-bucketing#setting-up-sticky-bucketing but we wish to test if everything is working fine or not on one our test environments for which the sdk version has been updated and configuration updated. If we enable the step 4 toggle - Enable Sticky Bucketing for your organization, will it affect the other environments as well?

Essentially yes, all environments and experiments will be eligible. A final gatekeeping measure would be to not provide a

StickyBucketService

to the SDK in production until done testing. Without the service at the SDK level, it will just do normal non-sticky bucketing

Great! Thanks 🙌

In a dev environment with a dev-specific experiment, you could try changing the running experiment in some way using the "Make Changes" button (targeting rules, variation weights, or something else). Assuming you've chosen an a change strategy powered by Sticky Bucketing (SB icon), then a non-sticky-bucketed user would likely be affected, whereas a sticky-bucketed user would not be.

Sounds great, Thanks! 🙂

If you are using a feature with a linked experiment rule, then you can put a force rule above the experiment rule which forces a specific value for a specific clientId (force rule with attribute targeting). However, this happens outside of (before) the experiment evaluation and thus the user who hit that forced rule would not have a sticky bucket assigned nor persisted.

If this is happening before the experiment evaluation, am I right to assume that the tracking callback will not be fired for that user?

that's correct. A force rule that triggers before your experiment rule will negate the subsequent rules; the experiment will not trigger and the tracking callback will not fire. You're essentially skipping the experiment and forcing a bucket instead.

So, there is no way to force a particular variant of the experiment for a specific user?

Not the way you're describing, at least not in the GB UI. This is by design: experiments are randomized in order for the stats to work out -- overriding the bucketing logic and calling tracking will bias your results. That said... • You can force the value of a variant above the experiment rule (as above). • You also have the ability to simulate a variation at the SDK level via

gb.forceVariation(key, variant)

, but this will skip sticky bucketing and won't trigger the tracking callback (although you can manually call track with the results if you want). • Or if you're trying to test sticky bucketing, you can use the methods I mentioned earlier (I'd probably manually seed the user's sticky bucket doc and observe that experiment enrollment adheres to this manual assignment).

Thanks for the detailed clarification, it's really helpful 🙂