PM Mapped
Home / Module 5 / The Multi-Armed Bandit
20
MODULE 5 · EXPERIMENTATION · TOOL 20

The Multi-Armed Bandit

An alternative to the fixed-horizon A/B test — not a replacement. It dynamically shifts traffic toward better-performing variants as it learns, trading some statistical cleanliness for less regret.

▸ Try the interactive tool
SolvesWasting traffic testing losers long after a winner emerged.
Category · Experimentation Complexity · Advanced Time to apply · Situational Pairs with · Statistical Foundations
A WHAT IT IS

The framework

The multi-armed bandit is an alternative to the fixed-horizon A/B test, not a replacement for it. Where an A/B test holds a fixed split between variants for a set duration and analyses at the end, a multi-armed bandit dynamically allocates more traffic to better-performing variants as it learns — reducing the cost of showing users the losing option.

The trade-off defines when to use each. An A/B test maximises statistical learning — a clean, interpretable result about how variants compare — at the cost of sending half the traffic to the loser for the whole duration. A bandit minimises regret — the opportunity cost of showing the worse option — by shifting traffic toward winners early, at the cost of a cleaner final comparison. Bandits suit short-lived decisions where exploitation matters more than understanding (a headline, a promo); A/B tests suit decisions where you need to truly understand the effect.

BANDIT vs A/B TEST

A/B test — fixed split, analysed at the end. Maximises learning; costs traffic to the loser.
Bandit — shifts traffic to winners as it learns. Minimises regret; costs a clean final comparison.

TRY IT

Try it yourself

B WHY IT MATTERS

What it prevents

Treating the bandit as a strictly-better A/B test misses the trade-off — it optimises for a different goal (less regret) at the cost of the clean learning an A/B test gives.

The shortcutWhat it costsWhat it gives you instead
Bandit as universal upgradeUsed everywhere, it sacrifices the clean learning A/B tests give.Matching method to goal uses each where it fits.
A/B's traffic costHalf the traffic sees the loser for the full duration.A bandit reduces that regret when exploitation matters.
Bandit's messy comparisonDynamic allocation muddies the final statistical read.An A/B test gives the clean comparison when understanding matters.
Wrong tool for the decisionShort-lived choices run as long A/B tests waste opportunity.Bandits fit short-lived, exploitation-first decisions.
C HOW TO RUN IT

Step by step

1

Decide what you're optimising for

Do you need to understand the effect (learning) or just capture the best option fast (minimise regret)? This single question chooses between A/B and bandit.

2

Use an A/B test when learning matters

For decisions where you need a clean, interpretable understanding of how variants compare — and will reuse that knowledge — the fixed-split A/B test is right despite its traffic cost.

3

Use a bandit when regret matters most

For short-lived decisions where showing the loser is costly and you don't need deep understanding (a campaign headline, a temporary promo), the bandit's dynamic allocation pays off.

4

Understand the trade-off you're accepting

A bandit buys less regret at the cost of a messier final comparison; an A/B test buys clean learning at the cost of traffic to the loser. Choose the cost you can afford to pay.

5

Mind the statistical caveats

Bandits have their own pitfalls (non-stationarity, getting stuck on an early lucky arm). They're not a free lunch — apply them where the trade-off genuinely favours them.

D IN PRACTICE

A short illustration

IN PRACTICEmatching method to goal

A team reached for a multi-armed bandit by default, treating it as a smarter A/B test. For a decision where they genuinely needed to understand how two designs compared — to apply that learning across the product — the bandit's dynamic traffic allocation muddied the final comparison, leaving them with less clean insight than a simple A/B test would have given.

The fix was to match the method to the goal. For that learning-focused decision, a fixed-split A/B test was right. But for a separate, short-lived choice — picking the best of several promotional banners that would run for a week — the bandit was perfect: it shifted traffic to the winner early, minimising the regret of showing losers, and they didn't need a clean statistical comparison afterward.

The lesson: the bandit isn't a better A/B test — it's a different tool for a different goal. A/B tests maximise learning; bandits minimise regret. Choosing well means knowing which you actually need for the decision in front of you.
E THE ARTIFACT

The method-choice guide

The deliverable is a deliberate choice between A/B test and bandit, driven by whether you need learning or low regret.

Use an A/B test when…Use a bandit when…
You need to understand the effectYou just need the best option fast
The learning will be reusedThe decision is short-lived
A clean comparison mattersShowing the loser is costly
e.g. core design decisionse.g. campaign headlines, promos
F THE SO-WHAT

Why it matters

THE KEY INSIGHT

The multi-armed bandit isn't an upgrade to the A/B test — it's a different instrument optimising for a different thing. A/B tests buy clean learning; bandits buy reduced regret. Knowing which you need is the whole skill.

The learning-versus-regret trade-off is the conceptual heart of it. An A/B test deliberately 'wastes' traffic on the losing variant for the full duration because that's the price of a clean, interpretable comparison you can understand and reuse. A bandit refuses to pay that price — it shifts traffic toward winners as it learns, minimising the opportunity cost of showing the worse option, but in doing so it muddies the final statistical comparison. Neither is better in the abstract; the right choice depends entirely on the decision. Long-lived, reusable learning (how do these two core designs really compare?) wants an A/B test. Short-lived exploitation (which of these banners performs best this week?) wants a bandit. The mistake is defaulting to one — usually treating the fancier bandit as universally superior — rather than matching the method to the goal.

G MISTAKES & LIMITS

Common mistakes

Treating the bandit as a better A/B test

It optimises for regret, not learning. Match method to goal.

Running short-lived decisions as long A/B tests

Wastes opportunity. Use a bandit when exploitation matters.

Expecting clean comparisons from a bandit

Dynamic allocation muddies the final read. Use A/B for clean learning.

Ignoring bandit pitfalls

Non-stationarity and lucky-arm lock-in are real. Bandits aren't a free lunch.

When not to use it

H CONNECTS TO

Where this sits in the toolkit

Alternative to → A/B Testing

Bandits and A/B tests (Module 3, Tool 12) are two tools for different goals.

Built on → Statistical Foundations

Bandits have their own statistics, related to the fundamentals (Tool 17).

Chosen via → the goal

Like all method choices, driven by what you're optimising for (Tool 18).

Applies to → short-lived optimisation

Suits campaign and promo decisions tied to Module 2's GTM work.

TRY IT YOURSELF

Choose the method for two decisions

Decision A: which of two checkout designs truly works better, to apply the lesson product-wide. Decision B: which of five promo banners performs best over one week. For each, pick A/B test or bandit and say why.

Tie your choice to the trade-off: learning vs. regret.

If you chose an A/B test for the reusable-learning decision and a bandit for the short-lived promo, you've grasped that the bandit isn't better — it's a different tool for a different goal.