25 results found
-
Support ODP Audience Configuration per Environment in Feature Experimentation
Recently, I have been working on a project where we integrate ODP Audiences with Feature Experimentation and I noticed one limitation that makes testing and environment setup harder than expected.
In ODP, we have separate environments, for example int/preprod/prod, each of them has its own URL and public/private keys.
In Feature Experimentation, we usually work with one project that contains multiple environments (added in settings), Feature flags are then configured and evaluated separately per environment inside the same project.
The problem is that the ODP Audiences integration is configured only once for the whole Feature Experimentation project. That means I…
10 votes -
Project setting to make "Match all audiences" the default for flag rules
When you add a second audience to a flag rule, the Match dropdown defaults to "any". There's no way to change that default for a project.
In most of our experiments, extra audiences are meant to narrow the targeting - for example, a platform audience plus a minimum app version audience. With "any", the rule buckets everyone who matches either audience, so the experiment can reach users it was never meant for. It's easy to miss in review because the rule looks right at a glance.
What would help, in order of preference:
1. A project or environment setting for…7 votes -
A method to list all available experiments
We are currently planning implementation of Optimizely as replacement of our current experimentation solution. In order for developers - and also business - to verify behavior we currently show a list of all active experiments and allow users to force a variation. In the current SDK there's no way to list all experiments. I prefer not to parse the datafile myself, so I would like to see a method that lists all experiments, including all variations, so we can migrate with the same functionality as we currently have.
Since the SDK already parses and interprets the datafile I feel this…
3 votes -
navigation
In feature experimentation it would be good to be able to add custom fields to each experiment. For instance location or team - this way teams can easily filter to their experiments to reduce noise
3 votes -
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.
2 votes -
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…
2 votes -
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…2 votes -
New Booleans in the Decision Object
It would be easier to have some Boolean values in the decision object, which would simplify recognizing the exact status of a visitor (e.g., whether they are in the "off" variation or the "everyone else" category, or in the concluded/deployed "on" variation). "Enabled" and "variationKey" are not enough to distinguish the above cases.
Currently, they need to check string values and match specific values like "rollout-default" or "deployedtdl" which is not ideal. Booleans would be easier.
2 votes -
logic
Current limitation:
When setting up logic for a template, users can only apply the AND condition. This restricts flexibility because it prevents combining AND and OR conditions within the same template.Why this matters:
Most systems allow both AND and OR options so that users can build more complex logic in a single template. Without this capability, users are forced to create multiple templates for different workflow scenarios instead of managing everything under one template using combined AND/OR logic.2 votes -
Request for Svelte SDK Support
We are currently using Optimizely for feature experimentation and have found the React SDK extremely helpful. However, our team is also building an application using Svelte, and we would love to see official support for a Svelte SDK.
Why this matters:
• Svelte is gaining significant traction for its performance and simplicity.
• Having a dedicated SDK would allow us to integrate Optimizely experiments and feature flags seamlessly into Svelte applications without relying on workarounds or custom implementations.Requested Feature:
• Provide an official Optimizely SDK for Svelte, similar to the existing React SDK, with support for initialization, fallback mechanisms,…2 votes -
Dealing with group AI Policies blocking out Opal
Customers with corporate AI policies restricting usage to approved vendors are blocking Opal adoption entirely or partially. While each scenario has its unique challenges, CS teams currently lack a structured playbook to navigate this. including security and compliance talking points, and escalation paths to help customers gain internal IT/legal approval to whitelist Opal.
1 vote -
Allow MCP server to be able to create metrics based on event tags and rename them.
Currently, I'm not able to use MCP server to create metrics on A/B tests. It can only create the metrics without event tag filtering or customisation, and it also cannot do custom naming for the metrics. If I need to create the same metric as total conversion and unique conversions, I'm not able to do that.
1 vote -
Multi-flag experiment capability in Feature Experimentation (cross-flag MVT / interleaved testing)
Customer: Inspire Brands
Request: Multi-flag experiment capability in Feature Experimentation (cross-flag MVT / interleaved testing)
Problem:
Inspire Brands uses Feature Experimentation to manage their testing program across their QSR digital ordering funnel. They deploy individual feature flags for distinct features on the same page — for example, their menu page has separate flags controlling a search feature, a product carousel, and filters. Over time, they accumulate multiple independent flags on a single page or funnel area and need to understand which combination of those flags produces the optimal user experience.
Today, the only way to test combinations of features across…1 vote -
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 -
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
.png){kind=link}
- Don't see your idea?