you could use tags to help organize

https://docs.growthbook.io/app/visual#stopping-an-experiment

If your variation won, you can optionally enable a

Temporary Rollout

when stopping. This will continue running your experiment with the same targeting conditions, but send 100% of traffic to the winning variation and disable the

trackingCallback

from being called.

The reason it's called a "Temporary" Rollout is because you don't want to rely on our SDK to implement the winning variation forever. It's best practice to have your engineering team re-implement the changes directly in your site's code. This is for a number of reasons:

1. Changes implemented in code are rendered quicker, so your site will load faster

2. Changes in code will be picked up for SEO

3. Changes applied through the visual editor require the SDK to download data from GrowthBook. Although lightweight, these stopped experiments can add up over time and further slow down your site.

4. Reduce the chance of conflicts. If two visual editor experiments try to change the same element at the same time, it will not always work as expected. Moving the winning variation to code will avoid this issue.

On success of a lot of experiments (i imagine) will want to enable temporary rollout, whilst they wait for development resource to make permanent. Once they've made it permanent (could take a while) they need to remember to disable 'enable temporary rollout' Hope that helps @fresh-football-47124 Appreciate that I can tag it as 'temporary rolled out' when i do that filter to see those, and remove that tag, when its. been made permanent my use case feels like it'd be common to your customers so they might run into pitfalls

I can imagine a number of experiments being problematic if: • made permanent by dev • and 'temporary rollout' was still on causing duplicate additions/removals etc