Try our conversational search powered by Generative AI!

What is user ID actually used for in Optimizely isFeatureEnabled()?

Vote:
 

I'm using the C# SDK v4 and Feature Experimentation.

I'm struggling to understand what the userID is actually used for in IsFeatureEnabled().

Can we create a rule that says if user ID = 123 the feature toggle is enabled, otherwise it's disabled?

Do we need to some how import all our user IDs into Optimizely?

Is the userID case sensitive?

#321813
May 10, 2024 6:34
Vote:
 

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. 

#321815
May 10, 2024 8:07
DavidKlempfner - May 10, 2024 12:58
Thanks for your reply.
I'll have a look at the Decide() method.

Now I'm just wondering if I need to call:
IsFeatureEnabled("SomeFeature", userId) || IsFeatureEnabled("SomeFeature", userId.ToLower())
In case someone has used lowercase when setting up the variation.
Paul Gruffydd - May 10, 2024 14:19
As long as it's consistent it shouldn't matter whether you use userId or userId.ToLower() as the user ID doesn't need to tally with anything in the feature experimentation configuration. I guess the one exception would be if you've forced a specific variant for a specific user in which case that would probably need to match but you should be able to see that by looking at the setup in the Feature Experimentation UI.
DavidKlempfner - May 14, 2024 1:57
In your screenshot it looks like 1/4 of the traffic will be sent to each of those variations.
What if I want 100% of traffic to be delivered to a variation with "off" and have another variation "on" that is only for users with Ids 7561 and 2432 for example?
I posted a question here:
https://world.optimizely.com/forum/developer-forum/Developer-to-developer/Thread-Container/2024/5/how-can-i-have-a-feature-toggle-disabled-for-everyone-except-listed-userids/
Paul Gruffydd - May 14, 2024 8:13
I've added a reply to that post. In short, change the traffic split to be 100%/0% or use a targeted delivery rule.
Vote:
 

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.

#321936
May 12, 2024 23:22
Vote:
 

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. 

#321939
May 13, 2024 6:56
Vote:
 

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.

#321945
May 13, 2024 7:47
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.