Customer Feedback

We love feedback from you on our products and the problems in your daily work that you would like us to solve. Please describe the challenge you're encountering and your desired outcome. Be as detailed as possible.

For technical issues or bugs please head to Support or our Developer Community. You can assign up to 20 votes in total. Thank you for your feedback.

Status explanation: 'Future Consideration' = Continuing to collect further feedback, not planned at this time. 'Investigating' = Prioritized for deeper customer and feasibility investigations ahead of planning development.

ADD FEEDBACK

Feature Experimentation

Showing 75 of 1909

Limit number of visitors for an experiment

Add the option to set up an absolute number of customers for an experiment or a variation. For example, an experiment supposed to be run only for the first 10000 visitors (instead of using the percentage).
almost 2 years ago in Feature Experimentation / APIs 1 Will not implement

low level api method to manually update datafile in javascript/react sdk

Currently, I can dynamically update user context but not the datafile. I can only configure time intervals on how often sdk itself will refresh the datafile itself.It's very limiting and I need more control over datafile updates. I suggest to impl...
almost 2 years ago in Feature Experimentation / SDKs & Agent 4 Future consideration

Option to remove percentage roll out for simpler flag management

We are exploring using Optimizely to manage critically important feature flags. Sometimes, a flag needs to be turned off instantly, out of hours or by Ops personnel eg in the event of an outage of service. In these instances, we want increased con...
almost 2 years ago in Feature Experimentation / Feature Flagging Workflows 0 Future consideration

Introduce distinct lexicon to distinguish between flag status and rule status (don't use on/off for both)

It is currently confusing to use the same terminology for both flags and the rules that control flags. For example, I can have a rule that is 'flag:off' but the rule in the list shows as 'on'. Suggestion would be to have different lexicon for rule...
almost 2 years ago in Feature Experimentation / Feature Flagging Workflows 0 Future consideration

Type check for userId in Javascript (Browser/Node) SDKs

The customer (Yuliyan Yordanov from Tesco Stores) suggested a failsafe solution to reject empty string userId upon activating/enabling an experiment/feature: "A simple check for (typeof user_id ===’string’ && user_id.length ) would fix the...
about 2 years ago in Feature Experimentation / SDKs & Agent 1 Future consideration

Normalizing metrics

Groupon experimenters are looking for ways to normalize certain metrics. We need to have an ability to change the denominator for each metric. e.g Deal View CTR (deal view/total unique impressions) Session CVR (units/session) Deal Purchase CVR (Un...
about 2 years ago in Feature Experimentation / Other 0 Future consideration

JavaScript SDK handles large datafiles in a performant manner. It is possible to process large datafile initialisation on a web worker.

The javascript SDK client initialises the client form the datafile. When the datafile is large, processing the JSON takes a long time. P50 20ms and P75 already gives 70ms. This is significantly long when considering page load time. It would be ben...
about 2 years ago in Feature Experimentation / SDKs & Agent 1 Future consideration

Using standard "off" variation multiple times.

This feedback is on behalf of Vistaprint. - Mauricio Acebal and Lukas Vermeer. This feedback is related to the special treatment of the standard "Off" variation. Vistaprint are happy they are capable of turning off a variation without changing tra...
about 2 years ago in Feature Experimentation / Feature Flagging Workflows 0 Future consideration

More intuitive design for managing features

I would like to add a few suggestions on behalf of Busra from Mural regarding a more intuitive design for managing features in our legacy platform: Have radio buttons instead of the "Status" drop-down menu on the Features tab Should not be able to...
about 2 years ago in Feature Experimentation / Feature Flagging Workflows 1 Future consideration

Logger having error categorised into types

The Optimizely logger indicates different types of errors. Our client suggests to divide the different types of errors by type. Example use case: our client is currently using a Regex to identify the error messages received for the error "not in d...
over 2 years ago in Feature Experimentation / SDKs & Agent 1 Future consideration