This message was deleted.

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 🙂