How existing experiment results are migrated

  • Updated

Existing experiment results are retained during migrations from legacy Optimizely Full Stack to Optimizely Feature Experimentation, but if you use multiple environments per project, you should be aware of how results are represented post-migration.

Your primary environment will be Production unless you have manually updated it. Your primary environment will have a badge labeled Primary Environment. Refer to the Optimizely Full Stack Experimentation developer documentation on Managing Environments for more.

primary_environment_production.png

Migrated projects with multiple environments will see all existing experiment results attributed to the experiment's primary environment post-migration. The new project's primary environment results will include any QA, staging, or development environment result data collected before the migration.

After the migration, any new result data from secondary environments will be sent to the corresponding environment's results page. Only the pre-migration data will be merged with the primary environment's results.

Scenario

In the Optimizely Full Stack Legacy experience, there is one results page for all environments in which the experiment is running. In the new Optimizely Feature Experimentation implementation, each environment has its experiments with its own, separate results page. Refer to the Optimizely Feature Experimentation developer documentation on how to Analyze Results for more.

Because of this new design, when migrating projects, there needs to be some where for all of the past results to be displayed. Moving the past results to the production environment ensures that your results data is not lost in the migration process.

 

fs_vs_fx.png

After migration, wherever your experiments run, they will continue to run in that environment. For example, in the diagram, if your experiment ran in Production and Development in Full Stack, it will continue to run post-migration in the same environments (Production and Development) in Feature Experimentation. Your pre-migration Production and Development results data will be on the post-migration Production's results page. Your post-migration Development's results page will be blank until Optimizely receives new Development event data.  

Legacy Optimizely Full Stack results results page

In the legacy Optimizely Full Stack experience, all environments results are displayed on the same page.

legacy-results-page.png

Optimizely Feature Experimentation results page

You can toggle between environments in Optimizely Feature Experimentation to see different results for those environments.

reports-page.png

This change affects every project that has ever had experiment result data reported in a secondary environment. Even if an experiment is not running in a secondary environment during migration, the past data will still be migrated.

Technical reasoning

The secondary environment's result data will be merged into the primary environment results page because there is one results page and one experiment ID for all environments in legacy experiments. So, Optimizely does not have a way to verify what environment the results came from. 

In the new Feature Experimentation experience, each environment has its own results page and its own experiment ID.

To maintain the result data and experiment ID across the migration, the new project's primary environment will have the same experiment ID as the legacy Full Stack project. Secondary environments in the Optimizely Feature Experimentation project will get new experiment IDs.

After the migration, any future result data from the secondary environments will be attributed to the corresponding environment and experiment ID and appear on the respective results page.

Possible solutions

You can always export your result data before migration to refer to afterward.

There is nothing "wrong" with the migration. It is just important to understand what happens with your data after the migration. If you have any questions, contact your Customer Success Manager. 

It is up to you how you want to handle your result data. If having the past secondary environment's result data in your production result data after the migration is acceptable for your use case, you do not need to do anything.

If you do not want secondary environment results data mixed in with your primary environment result data, you can reset your secondary environment result data before migration