--- title: Run a multi-armed bandit optimization in Feature Experimentation slug: feature-experimentation/docs/run-a-multi-armed-bandit-optimization-in-feature-experimentation docTags: createdAt: 2026-08-05T20:40:03.000Z --- - Optimizely Feature Experimentation You might want to run a test focusing on maximizing conversions from your variations instead of finding the variation most likely to perform consistently better than your baseline. A [multi-armed bandit (MAB) optimization](https://www.optimizely.com/optimization-glossary/multi-armed-bandit/) is a different type of experiment, compared to an [A/B test](docId:8pnfCv-sR37goLcxTtCPv), because it uses reinforcement learning to allocate traffic to variations that perform well while allocating less traffic to underperforming variations. :::hint{type="warning"} MAB optimizations do not generate statistical significance. Instead, the algorithm pushes traffic to variations with the most conversions; the reason for a variation's performance is unimportant. ::: MAB is for optimization, not experimentation. Its tests are best suited for maximizing conversions during short, temporary experiences such as headline testing or a holiday weekend sale. You should never use MAB tests for exploratory hypotheses or variation selection. MAB's primary goal is to answer: *Which variation gets us the largest reward?* where the "largest reward" is the highest revenue or most conversions. For information on MABs, see how to [Maximize lift with multi-armed bandit optimizations](docId\:hdWCjAZF6CQqkXkuK6PiT). ## Best use cases The following cases may be a better fit for a multi-armed bandit optimization than a traditional A/B experiment: - **Promotions and offers** – Users who sell consumer goods on their site often focus on driving higher conversion rates. One way to do this is to offer special promotions that run for a limited time. Your changes will not be permanent, and an MAB optimization will send more traffic to the over-performing variations and less traffic to the underperforming variations for the duration of the promotion. - **Headline testing** – Headlines are short-lived content that loses relevance after a fixed time. If a headline experiment takes as long to reach statistical significance as the lifespan of a headline, then insights gained from the experiment are irrelevant. Therefore, an MAB optimization lets you maximize your impact without balancing experiment runtime and the natural lifespan of a headline. - **Webinars** – You can boost registration for webinars or other events by experimenting with several different versions of calls to action to sign up for your webinar. For algorithmic details of MABs at Optimizely, see the [end-user documentation](docId\:ysZDA2iO4AdW2dkPbUahm). ## Configuration overview To configure a MAB, complete the following: 1. (Prerequisite) [Create a flag](docId\:eH-UMm_rOn_GdGDGLV6__) in your Feature Experimentation project. 2. (Prerequisite) [Handle user IDs](docId\:j0PPoMJWYbz04K76EKLUI). :::hint{type="info"} You should configure a [user profile service](docId:0mbVhcaiWJm6M96ZohwI-) to ensure consistent user bucketing if you are using a server-side SDK. ::: 3. Create and configure a MAB rule. 4. If you have not done so yet, implement the Optimizely Feature Experimentation SDK's **Decide** method in your application's codebase through a [flag](docId\:eH-UMm_rOn_GdGDGLV6__). 5. Test your MAB rule in a development environment. See [Test and troubleshoot](docId\:JU1Sh9PVLBMIW2_VDbTjx). 6. Discard any test user events and enable your MAB optimization rule in a production environment. ## Create an MAB optimization in your Feature Experimentation project To create an optimization in the Optimizely app, complete the following: 1. Go to **Flags**, select your flag, and select your environment. 2. Click **Add Rule** and select **Multi-Armed Bandit**.  ![Select Multi-Armed Bandit rule](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/SGjlKjP6RXWbLMUzdsGyc-20260720-145756.png) 3. Configure your MAB rule. 1. (Optional) Search for and add audiences. To create an audience, see [Target audiences](docId\:UDBvr5a8WHNkyOqzPhOr9). Audiences evaluate in the order in which you drag and drop them. You can match each user on any or all of the audience conditions. 2. Set the **Traffic allocation** slider to set the percentage of your total traffic to bucket into the experiment. 3. Add metrics based on tracked user events. See [Create events](docId\:v2goO-UxyIA4AtTSR-h-9) to create and track events. For information about selecting metrics, see [Choose metrics](docId\:e2qGf29S6pO8SW90_IVuH). For instructions on setting up metrics, see [Create a metric in Optimizely using the metric builder](docId\:cphstZe3xKhsY7WsnnLZK). 4. Choose the variations you want to optimize. Unlike A/B experiments, you do not need to compare to a baseline experiment because statistical significance is not calculated with MAB optimizations. See [Why MABs do not use a baseline](docId\:M2vrrcT2J7X7T-GiROjVk). 5. (Optional) Add the MAB to an [Exclusion Group](docId\:Zt9wpfC62agkfLNCQbTHK). 4. Click **Save**. :::hint{type="info"} If you plan to change the traffic allocation after starting the experiment, then implement a user profile service. See [Ensure consistent user bucketing](docId:0mbVhcaiWJm6M96ZohwI-). Also, create a user profile service if you plan on using **Stats Accelerator**. ::: 5. Click **Run** on the MAB rule. If it is not already running, click **Run** on the ruleset (flag). ## Implement the MAB If you have already [implemented the flag](docId\:eH-UMm_rOn_GdGDGLV6__) in your application's codebase, no further configuration is required for the flag delivery. If you have not, implement the **Decide** method call in your code to enable or disable the flag for a user. See the [Run a multi-armed bandit optimization ](docId:9Tu731hmFrs5KHzlIsT7N)in the developer documentation for code samples. See the following SDK reference documentation for more detailed examples. - [Android example usage](docId\:nQkw1CJn6rhkkZcHUhWlu) - [Go example usage](docId\:BtqVa7hPVV3lakICHOePE) - [C# example usage](docId\:TcOrbpenEwK6XfJSXEWhQ) - [Flutter example usage](docId\:aZh7xqKhZ9b8I15ukdQnS) - [Java example usage](docId\:oczD_Ka_bhgCygo60xG31) - [JavaScript example usage](docId\:Hd7ZwchAg70iG5S_5kgpM) – SDK versions 6.0.0 and later. - [JavaScript (Browser) example usage](docId\:c8V_lO-12gUfsBNUuczJI) – SDK versions 5.3.5 and earlier. - [JavaScript (Node) example usage](https://docs.developers.optimizely.com/feature-experimentation/example-usage-javascript-node-prior-to-v6) – SDK versions 5.3.5 and earlier. - [PHP example usage](docId\:QDWBJTJc3c2qnd5EhAPQ9) - [Python example usage](docId:0Afx9oaNuXQo-439j2JzL) - [React example usage](https://docs.developers.optimizely.com/feature-experimentation/docs/example-usage-react) - [Ruby example usage](docId\:Oh9NVDFfn7X-s1WTLfPUY) - [Swift example usage](docId:3ZVLXuKme4kiqdO2Yt_H1) Optimizely Feature Experimentation uses the **Decide** method call to decide whether a user qualifies for the rule and which variation they receive. The Optimizely Feature Experimentation SDKs let you reuse the exact flag implementation for different flag rules. Remember, a user evaluates against all the rules in a ruleset in order before being bucketed into a rule's variation. See [Create feature flags](docId\:Z0Yy8O0N7GakXKfCPYtSi). ## MAB results Because MAB optimizations do not generate statistical significance, their results page differs from an A/B test. Instead of calculating statistical significance, MABs push traffic to variations with the most conversions; the reason for a variation's performance is unimportant.  ::Image[]{src="https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/RLbglfY6enVAHRiTg2_b--20260720-145756.png" size="60" alt="Mult-Armed Bandit Results page" isUploading="false" darkWidth="1412" darkHeight="950" width="1412" height="950" showCaption="false"} For information, see the user documentation on [the Optimizely Experimentation Results page](docId\:mrUblIuNVOZc1dvjWdsbw).