Hi,

The userID is used to ensure that a given user is consistently placed in the same bucket between requests. Even if a user isn't logged in, you still need to assign them a userID and persist that ID (e.g. in a cookie) to ensure they're always going to see the same thing.

If you want to force a specific user to be bucketed a certain way, you can set that up in the feature experimentation dashboard under your traffic split rules which are set per environment. For example, to force a specific user with the id "user123" to always see variation 2, we could set it up like this:

You don't need to preemptively upload all of your user IDs into feature experimentation in advance, just pass the ID through with your call to one of the decision methods. As far as I'm aware, the user ID is case sensitive but that's more of an assumption so don't take my word for it.

Finally, I notice you're using IsFeatureEnabled() which I believe is one of the legacy methods carried over from "full stack". The current equivalent of that method would be the "Decide()" method. 

What's the benefit of using Decide() over IsFeatureEnabled()? We need a simple true/false value to know if a feature is enabled or not so it seems as though IsFeatureEnabled() solves that problem in the simplest way.

Hi 

According to the doc, IsFeatureEnabled() is from a legacy product "Full Stack Experimentation" and this product will be sunsetting on 29 July 2024. Decide is a new method backward compatible with legacy SDK methods.

I assume if you're moving to newer version product - Feature Experimentation, you'll have to use Decide which gives you OptimizelyDecision instance, and you can check "Enabled" property to determine if feature is enabled. 

I think Vincent's covered the main points there although there is a caveat worth mentioning. The "Full Stack" product is going to be retired in July however the legacy API methods aren't being retired just yet. I would imagine they will be retired in the future though so it's still worth migrating onto the newer methods. Here's what the docs say:

"Optimizely Full Stack Experimentation software will be sunset. Optimizely will still support Legacy Full Stack Experimentation's isFeatureEnabled, GetFeatureVariable, Activate, and Track methods."

Beyond the stuff Vincent's mentioned there is another important benefit of the new APIs. The IsFeatureEnabled method implies a binary decision (which, I realise is all you're after right now) but the Decide method allows for any number of variations so it's a single method to learn whether you're simply switching a feature on / off, or whether you're looking at 5 different potential versions of that feature delivered in differing percentages to differing audiences.