9 results found
-
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 -
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 -
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
2 votes -
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 -
default value variables can be changed as editor impacting production
As an editor, I am not allowed to change Production values, including variation variables.
However, I can still update the "Default" value of a variable and that will affect all environments including Production if the default is in use.
1 vote -
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.1 vote
- Don't see your idea?