In order to support testing of more complicated experiments that require server side code changes, in tandem with experiment JS/CSS changes, please allow the changing of a project target URL without deleting all the experiment changes.

RapidX already has the ability to do this (they have a button that can bypass the change deletion behavior), meaning the use case is valid and the code has already been written. I'm not sure if it's an oversight or if there is a justifiable design reason why customers cannot do the same.

Since we control both the experiment change selectors and the server side code, we can guarantee our server side changes are deployed before moving the experiment target to production.

This will allow us to test that the server side code changes and the selectors for the experiment are working together correctly, without needing to deploy our server side code changes all the way up to production.

Having to deploy server side code changes all the way up to production just to QA the experiment creates unnecessary risk, extra branch management complexity, extra deployment time, and more overall deployments.

On the experimentation side, having the selectors be deleted when moving project target URLs creates extra work and risk of losing changes .

An alternative suggested to us by support was to run the experiment with both test and production targets from the beginning, but this creates muddy statistics because test and prod traffic will be feeding in to the same metrics.