We did also hit one other super annoying problem with the new experiments system. Overall we do really like it, it's much easier. But it's far less capable/expressive with complex conditions In many cases we use features more as sources of config with various rules, not just for rollouts etc. A lot of our features look like this - where we have long-standing/maintained behavior that continues after the actual analysis has long-since finished, but we need to preserve the behavior for the exact specific users In a lot of these cases, we also need to have the same experiment apply to multiple features (this seems to work okay) The key problem is that we sometimes need to have combined rules - i.e. additional conditions beyond those in the experiment targeting. e.g. if the experiment is on this variant, and the user is on the web version of the app, use this value. Whereas if they're on another version, use another value Ideally it'd be possible to add additional conditions on experiment rules, like the legacy ones allow

@blue-sundown-32899 has marked the issue as closed. Reopen Issue button

Adding additional conditions on top of the experiment definitely makes sense for some advanced use cases like yours, but it would make it easier to mess things up accidentally for others with a simpler set up. So if we add this functionality, need to figure out the right UX to balance that.

This is a better example to understand it

Hi James, just to help me understand this bit:

The key problem is that we sometimes need to have combined rules - i.e. additional conditions beyond those in the experiment targeting. e.g. if the experiment is on this variant, and the user is on the web version of the app, use this value. Whereas if they're on another version, use another value

You want to manage this in feature flags, but am I right in understanding that one could handle this in the app itself? e.g. if (user in experiment variant B) { if (web) x; if (ios) y}?

ah yes that would be possible, but most of our A/B setup is done without any engineering involvement - we use Growthbook and our CMS to empower any staff member to set up their own experiments as needed without code changes

Got it, thanks. Just wanted to understand the use case better.

Hi James, just checking in on this. Is there anything else we can help with on this topic, or should I close the ticket?

Well this use-case is not covered currently so it's still an outstanding ask?

We haven't been able to get to implementing that advanced setting as fast as I would have liked. What I can do is re-enable legacy experiment rules for your account in the meantime. I can push that change up in an hour or so

Don't especially mind when, just replying to the question of whether the thread should be closed

Thanks, James