68 results found
-
Improved clarity around scheduled experiments
As an experimentation user, I want the UI around scheduled experiments to more clear about the experiment status.
Currently, the experiment status is either "Not Started" or "Paused". It would be great if the experiment status instead was simply "Scheduled", or alternatively "Paused (Scheduled)" / "Not Started (Scheduled)".
Additionally, when changing a paused scheduled experiment, there is a warning "Publish your experiment if you want your draft changes to go live on the scheduled date.". However, when clicking Publish, the preferred option "Publish Only" is not highlighted and instead "Publish and Start" is highlighted. This might cause someone to accidentally…
1 vote -
Ability to track MAU consumption per project when using Custom Snippets
Currently in admin centre the reporting available for MAU's per project does not provide data if the customers projects were set up using custom snippets. As custom snippets are a popular way to set this up, it would be great to be able to able to report on this.
1 vote -
variation editor option to publish directly
As an experiment builder that generally uses the code editors and who uses the cookie and querystring model for qa and works with intricate code that is load dependent and requires more than a few updates to get working properly within the actual site code
I would like to have the ability to publish the variation update on the variation screen (perhaps a 'publish' button)
So I don't have to save the code changes, then go to main experiment screen and publish and then navigate back to the variation and wait for the page (which will fail because it is…
1 vote -
variation screen editor page load option
As a builder of web experiments that always uses the code editors or targets locations inaccessible to the editor
I would like to have a setting that stops/blocks the page load every single time you pull up the variation code. It would be nice to be a persistent setting that could either stick to the variation or to my login.
So I don't have to click through error messages that are not relevant every time I go to edit.
1 vote -
Deployed experiments (winner rollout) should be active in Preview mode for other experiments
Deployed experiments (winner rollout) should be active in Preview mode for other experiments.
Currently, when an experiment is concluded, and the winning variation is deployed, this deployed variation is active for all visitors on the website. However, when Previewing another/new experiment, that deployed experiment is not active.
Since the deployed variation should be considered the "is-state" of the website, and it is publicly visible to regular visitors, it should also be visible in the Preview mode.
1 vote -
program reporting data
As an experimentation program manager in an experimentation COE with no access permissions to build a system to assess API data but with access to data tools that I can use to build out queries and dashboards.
I want to be able to access meta information on experiments (the same data set accessible via the API) in my s3 (bigQuery, etc.) feed.
So I can build queries and dashboards to assess and report on the health of the program, create alerts, etc.
1 vote -
event / metric tagging
As an experimentation program manager in an experimentation COE
I want to be able to 'tag' events/metrics with properties like 'funnel', 'engagement', 'conversion'. This information should be available via export in some manner - s3 type of export preferably.
So I can analyze the metrics use in experiments to better understand what our teams have been / are focusing on and understand the health of the program better.
1 vote -
Experiments average run-time
The customer would like to have the following information available in the Admin Center: average experiment run-time
2 votes -
Cut off ingestion of decision events for experiments that have already been concluded/archived.
Optimizely still captures data (decision events) for experiments that have already been archived or concluded. This data gets added to the BigQuery tables, which is undesirable. We'd prefer a cut-off, so that decisions for archived/concluded experiments do not get recorded in BigQuery.
2 votesConcluding experiments should prevent decision events, investigating.
-
Show which audience a visitor matched when an Experiment has multiple audiences.
Show which audience a visitor matched when an Experiment has multiple audiences.
Both the Audience builder and the Experiments builder support OR clauses. However, there is no way to dissect the data to know which specific Audience triggered the experiment for the visitor. Our organization will run experiments where we may use a Javascript based audience and a Real-time segments audience to trigger a single experiment. The Experiment report will show the visitor to variations counts but there is no way to tell which audience the visitor matched.
The suggestion is to have a breakdown of the visitor counts, by…1 vote -
Conditional Activation: undo conditional activation from visual editor
Suggestion: a way to remove the conditional activation trigger from within the visual editor without going into the page activation (auto-generated) callback and adjusting/removing it there?
Currently this option does not exist in the Visual Editor, but would be useful if you want to undo conditional activation (easily).
1 vote -
Conditional Activation: Select Multiple Conditions
Suggestion:
Ability to add multiple conditions.
At the moment we can only select 1 condition, but selecting multiple (2 or more) conditions would be a great add.
Use Case - Ecommerce example:
if a new user clicks over the jackets category and has an exit intent, we show them a pop up with a promotion
1 vote -
Conditional Activation: Scroll To % option
Topic: Conditional Activation
Use case: run a global experiment with a pop up, but not all pages have the same elements so we need to be able to scroll to % on the page.
Solution: Scroll To option, add the possibility to scroll to % (not just element).
1 vote -
Include ability to target html elements based on their css specificity.
Currentlh when using the Visual editor and an element is selected such as an H1, the css class or ID attributes are not accounted for in the editor.
Sometime is is necessary to be more specific, such as
H1 vs H1.classname
The idea is to include an option to use specificity and have the editor use the ID or classname based on a setting.
Such as...
Use HTML element only (H2)
Use HTML ID (#id-name)
Use HTML element + CSS Class name (H2.classname)1 vote -
Restore to previous version
Since Optimizely keeps a 'log' of changes -- why can't we have a "Restore to this version" in the history log.
It's nice to see what happened in the log, but the ability to restore to a previous version would be invaluable when editing and changes have been saved and going back a few versions is critical to avoid having to redo the entire variation setup.
See attached UX suggestion.
1 vote -
Variant-level audience configuration
Hello!
I often have visitors classified into different audiences accessing the same page. It would be nice to be able to experiment with different communications based on the visitor's audience. Today, to have this type of granularity, I need to set up an experiment for each type of audience.
1 vote -
Bot Blocker
We get a lot of bots that try to submit forms. Can Optimizely come up with some feature that can be used to block Bots from getting counted into an experiment?
(Not blocking site access -as our IT department can't even do that all that well)
1 vote -
Enhancing A/B Testing with ES11 Modern JavaScript Features
I am proposing that we upgrade to ES11 to stay aligned with the latest JavaScript standards and leverage modern language features such as optional chaining, nullish coalescing, and Promise.allSettled. These enhancements significantly simplify handling complex asynchronous logic, reduce verbose and repetitive code, and improve overall readability and maintainability of our experiment scripts.
While we understand that upgrading is not strictly required to run experiments, adopting ES11 is vital for our growth and development as devs. It enables us to build more robust and reliable A/B tests, accelerate development and iteration cycles, and minimize technical debt. Keeping pace with evolving web…
7 votes -
Dashboard Experiment Overview
I constantly get requests from product manager or other team members asking, "What is running on the site in Optimizely". Not everyone has access to look at the reporting dashboard/program overview.
The idea is for a view that can be shared and configured by an Optimizely Admin - and then can be shared. No login is needed for this view.
The view can contain a number of items (similar to the current program overview) and could be filtered by the admin to only show experiments that are relevant to the business goals or the view's audience.
1 vote -
Experiment Organization Folders
It would be great to be able to create folders in the experiments list to group items together. (Not the sort feature). Often, I have multiple experiments (separate mobile and desktop project that are the same content) - it would be useful to be able to organize these into groups - like in a file folder system. (See mockup)
6 votesWe are planning to redo some parts of the dashboard and the setup of certain things. As a lot of creation things will be moving into the new VE, we will be taking this into account and I will be reaching out when we get to the dashboard part.
- Don't see your idea?