68 results found
-
Product Feedback: Experiment API, whitelist/allowlist
We use in Full Stack project API to update a whitelist - https://docs.developers.optimizely.com/full-stack-experimentation/reference/update_experiment
This API is not available in Feature Experiment - https://docs.developers.optimizely.com/feature-experimentation/reference/experiments
Could you please advise if there is a possibility to manage allowlist in Feature Experiment via API?2 votes -
Add Rule and Variation IDs to Decision Object
Currently, the decision object returned by an SDK's decide method includes the flag, rule, and variation keys that a user was bucketed into but does not return the (experiment rule and variation key that the user was bucketed into.
2 votes -
JIRA Integration for Feature Flags
Unfortunately, in the new Flags UI the JIRA Integration is no longer available (as it is not yet migrated). My Idea Post is about requesting its availability.
In our Company we have a very close relationship between JIRA Tickets + Experiment Rules (1:1). That's why, this integration is/was helpful to relate Code/Work accordingly.
Many thanks in advance
Michael2 votes -
Remove unused experiments from user profile service
Currently, user profile service (UPS) maintains a map of user IDs to the experiment IDs they've previously been exposed to and the variation ID they received. The SDKs continuously append to the UPS without any cleanup, even if an experiment has been concluded and is no longer relevant.
Customers have in the past implemented diff logic to compare the live experiment IDs in the datafile vs UPS and remove experiment IDs from the UPS that are no longer in the datafile.
2 votes -
Flag Triggers/Kill Switches
Make change to flag (e.g., toggle on/off) based on event from external system (e.g., APM alert).
2 votes -
Dependent flags
Be able to trigger flags if certain actions happen, or make flags dependent on other flags. Both stateless and stateful approaches.
2 votes -
Default Experiment Metric Auto‑Apply
Feature: Default Experiment Metric Auto‑Apply
Automatically apply a predefined default metric to every new experiment created in Optimizely, ensuring that all tests are consistently configured with a core measurement from the outset.
Today, metrics must be manually added during experiment setup, which introduces variability and increases the risk of inconsistent or incomplete measurement across teams. This feature removes that dependency by embedding a standard metric directly into the experiment creation flow.
Improves experiment quality and consistency
By ensuring every experiment starts with a core metric, teams align on how success is measured. This directly addresses known challenges around inconsistent metric…
1 vote -
Support multiple User IDs
Currently, Optimizely (FX) only supports one User ID.
However, a user might use different IDs, depending eg. on log-in status or similar. The same way, experiments might require randomization and sending events on any of those IDs.
This will be a key feature for us going forward.
1 vote -
Make custom fields usable on Flag overview page
On the flag overview page it would be very helpful if content of a custom field would be
- filterable
- searchable
- sortable
This way the custom fields would be even more helpful to organise a decentralised experimentation program.1 vote -
Make custom fields editable after creation
As a CoE leader for experimentation we want to use the custom fields to organize our projects better.
The labels are very helpful to assign ownership of a flag to teams etc. without having to worry about spelling mistakes or similar.
However, as teams can change, or new teams join it would be helpful if a custom field would be editable in that regard, such that you can add a new label for a new team.1 vote -
Allow MCP server to query MAU data
I've got an IT support ticket to get my Claude connected to the remote server. In the meantime, I'm using the locally installed server to audit our MAU consumption. The MCP server is struggling to get users for each a/b test rule, which feels like a miss that might be easily fixed in a future release? I was able to create a workaround with a script that queries the Results API, but this took a while and was quite clunky.
1 vote -
Service-Level API Key Management
Currently, generating an API key requires associating it with an individual user account, which introduces an anti-pattern for teams and production workflows. This approach can create challenges around ownership, security, and maintainability, especially when users leave or roles change.
We would like to request support for service-level or organization-level API keys that are not tied to a specific personal user account. This would enable more robust and scalable integrations, better access control, and improved operational reliability
1 vote -
Allow access to FX instance without project assignment
Enable a way to invite a new user to an instance of Feature Experimentation without having to assign them to at least one existing project. Use case is for a large org with many product teams. Say an admin wants to extend Optimizely access to a new product team, but wants to do so without giving them access to any existing project - there is no way to do this today.
1 vote -
Customizable MAB interval
Make the calculation interval of MABs customizable (currently 60 mins by default). The specific need is around an MAB in which we would expect a delay between the initial decision and when we would expect the primary metric to be triggered (up to several hours). This creates a scenario in which the MAB is diverting traffic based on user behavior that has not yet occurred.
1 vote -
Attribute creation within audience builder
Within the FX audience builder, if i search for an attribute that does not exist I should be able to create and add a new attribute without having to exist audience builder, go to attributes tab, and then back to audience builder.
1 vote -
Product Area Field
User story: As an engineer/product manager, I want to add product area to an experiment so that I and other stakeholders can review how many experiments there are in our domain
Problem:
Experiments are currently difficult to group or analyse by product domain (e.g. Search, PDP, Checkout). As a result, programme reporting lacks clarity on where experimentation effort is concentrated, which areas are under‑ or over‑represented, and how different product areas are performing over time. This limits the ability to assess experimentation coverage, prioritisation, and strategic alignment.Solution:
Add a Product Area field to experiments, using a controlled list of…1 vote -
Filter by Product Owner & Product Area Field
User story: As an engineer/product manager I want to filter experiments by product owner and product area so I can quickly see all experiments I own without manual searching
Problem:
Even when ownership or context is known at an individual experiment level, this information is not surfaced in programme‑level reporting. As a result, Program Overview and Trend Reports provide activity and outcome data without sufficient context around who is responsible or which area the work relates to. This makes programme reporting less actionable for leadership, experimentation governance, and portfolio decision‑making.Solution:
Extend Program Overview and Trend Reports to include Product…
1 vote -
Product Owner Field
Use case:
As an engineer/product manager, I want to add product owner name to an experiment so that ownership is clearProblem:
Today, experiments in Optimizely do not clearly identify who owns them from a product perspective. Ownership is often inferred from context, naming conventions, or tribal knowledge, which makes it difficult to quickly understand accountability, especially in programme‑level reporting, cross‑team reviews, or leadership updates. This lack of explicit ownership creates friction when reviewing experiment outcomes, following up on long‑running tests, or assessing portfolio health.Solution:
Introduce a dedicated Product Owner field at the experiment level that can be populated…1 vote -
Add Global Default Rule
Add the ability to define a Global Default Rule at the Project or Environment level in Optimizely Feature Experimentation.
Any new flag or experiment should automatically inherit this rule at the top of its priority list. For example, if a user is in the Test Audience, the flag or experiment would be forced ON.
This would ensure QA rules are always included by default, reduce repetitive manual setup, and prevent teams from missing this rule when creating new flags or experiments
1 vote -
Date as an Attribute Type
For our experiments, we have a custom attribute that represents when a user signed up to our platform. Currently, we encode the values we receive for this as 8 digit numbers (YYYYMMDD) because Feature Experimentation audiences do not allow for attributes to be Date values. It would be a nicer experience for our users to be able to use a Date type rather than a Number type for attributes when creating audiences.
1 vote
.png){kind=link}
- Don't see your idea?