We’ve heard your feedback loud and clear: you want more control over what is included in this file. We fell short of your expectations and our own in this area. I’m sorry. Today, we’re launching three new settings to give you more control.
But why is experiment configuration data even exposed at all? Because Optimizely is built using a client-side architecture in order to make it fast, reliable, and easy to implement.
Client-side vs. Server-side
The original inspiration for creating Optimizely four years ago was to make it easy for anyone to do A/B testing. Our goals were to make it easy to create experiments, verify they are set up correctly, and run them without requiring much engineering or IT resources. It was also critically important to make Optimizely run so fast that your visitors won’t even notice it.
In order to achieve these goals we decided to implement Optimizely using a client-side architecture. Implementing Optimizely is as easy as copying a single line of code to your website. The snippet of code is served from the fastest and most reliable Content Delivery Networks in the world. A client-side architecture means we deliver experiment configuration data and code directly to your website visitors and execute it in their browser. The alternative is a server-side architecture where the work happens on a third-party server. Running an experiment through a third-party proxy is typically slower and requires IT support, but certainly is an option.
In order to give you more control we’ve launched three new settings, grouped under “Project Code Settings”. You can find them by clicking “Project Settings” on the Dashboard.
1. Masking Descriptive Names This option obfuscates, or masks, the descriptive names for experiments, variations, audiences, sections, and segments by replacing them with numerical IDs. Anyone viewing the source code will only see the numerical IDs.
Note: if you are passing your experiment data to third parties such as an analytics integration, you may want to consider waiting until any current experiments are finished running before turning this on so that your experiment data is not split across two different names in the third-party system.
2. Force Variation Shortcut This option prevents anyone from using a URL parameter to display a specific variation. We’ve turned it on by default to protect your account from third parties linking to your variation without your knowledge, but this will also prevent you from debugging or cross-browser testing using the URL parameter. You can still use Preview mode to share specific variations with collaborators. In general, we recommend you keep this option turned on, disabling the force variation parameter.
3. Draft and Paused Experiments This option will exclude your draft and paused experiments from being visible in the source code. Unless you need your draft and paused experiments available to use with Force Variation Shortcut, we recommend you turn this option on.
See our Knowledge Base article for more details on how to use these settings.
Our commitment from day 1 has been to listen to your feedback and to deliver a product that delights and inspires you. The key to this commitment has been your feedback. Thank you for playing your part. We are committed to playing ours.