In Optimizely’s feature management, a feature is an Optimizely concept that represents a major part of your product that you want to test and roll out. Features are the things you develop that you will use Optimizely to release and iterate on with experimentation.
Developing a feature is not as straightforward as an A/B test. With a feature, you might start with a bare-bones prototype, run experiments to collect data, update your prototype based on what you learn, and repeat the process to refine your feature. When you are satisfied with your feature, you can use feature management to carefully roll it out to a subset of visitors, such as high-value enterprise customers.
Optimizely’s feature management addresses many problems and gaps in the product development process. Here’s how all the feature management components work together:
- Create features and turn them on or off with feature flags (also known as feature toggles), at any time and without deploying new code.
- Configure your feature with feature variables so you can iterate on the feature in any environment.
- Run feature tests to learn whether your feature works better than an existing feature and iterate on failed features.
- When you're ready to launch the feature in a test or production environment, roll it out to increasing percentages of traffic over time with feature rollouts.
- Target a feature to perform QA or whitelist beta visitors.
- Restrict feature access to users who share a specific characteristic, by defining and setting the experimentation audience and its attributes.
Here’s how you might use different feature management components in a specific use case. In this scenario, you want to roll out a new feature to a specific group of users for two reasons:
- Consistency: Ensure everyone in the group sees the same thing in the UI.
- Uniform access: Ensure the entire group is granted access at the same time to fulfill commitments (customers have been promised beta access).
You plan to run this feature in a test environment for verification before running it in production with these conditions:
- Users will be forced into the "Feature On" variation to ensure consistency and uniform access.
- The test will use whitelisting instead of forced bucketing. Whitelisting works well for a limited beta scenario because the users don’t have to take any action to be added (unlike forced bucketing, which requires users to follow a link to be added). Whitelisting only works with feature tests (not rollouts) and is limited to 10 users.
- The test will initially run for a small percentage of users. Later, you’ll modify the test and enable it for 100% of traffic in production environment.
For this use case, keep the following notes in mind:
- Whitelisting overrides all audience targeting and traffic allocation settings defined for the experiment and any variation.
- Make sure that the feature test is running in the appropriate internal or external environment for the whitelisted users.
- When you’re ready to roll the feature out to 100% of users, we recommend stopping the feature test and creating a rollout because rollouts don’t result in impressions.
Suppose you beta-tested a feature using audiences to ensure certain users were included in your beta test. Now that the beta test is over, you’re ready to roll out the feature. You want to ensure the original beta testers are included in the feature rollout even though rollouts are randomized.
If you need to implement a feature rollout for this use case, please contact Optimizely support for more help with your particular implementation.