Live data from Hacker News

Why multi-armed bandit algorithm is not "better" than A/B testing

visualwebsiteoptimizer.com

51–60 of 80 posts

Re: Why multi-armed bandit algorithm is not "better" than A/B testing

#51

Earlier quoted context omitted.

This comment just sold me on MAB. You can just keep on throwing variations on a design at the system without having to make tenuous decisions. I hope all the A/B tools implement this soon.

Don't wait: http://mynaweb.com/ [Yes, this is a shameless plug for my startup.]

I should note here that if you use Myna, you will be using a much better multi-armed bandit approach than the epsilon-greedy which lost in this blog post.

See my longer top-level comment for some of the trade-offs.

Re: Why multi-armed bandit algorithm is not "better" than A/B testing

#52
post #39

This blog post misses to me what is the most important difference: If you are not keeping consistent assignment ratios of users into experiment buckets, then you are implicitly making the assumption that no other factors other than your A/B test can affect conversion. A very common example would be you might have a form that converts higher on the weekends than the weekdays just because of some external factor. You f…

That was exactly my point at http://news.ycombinator.com/item?id=4040022 and it is a valid one.

However I have been thinking about it since, and it is possible to design a multi-armed bandit approach with logarithmic regret (though higher by a constant factor than a traditional approach), that can handle the varying performance ratio. It also would allow you to add variations at any time.

There remain operational differences, but this problem is fixable.

Re: Why multi-armed bandit algorithm is not "better" than A/B testing

#53
post #49
post #46

Earlier quoted context omitted.

[deleted]

The problem with this math is that the difference in the scores on Friday are already pretty significant ( http://www.thumbtack.com/labs/abba/#A=60%2C500&B=40%2C50... ) Here is the absurd case. The conversion rate is 10% on Friday and 50% on Saturday: Friday (~10% conversion): A: 10 / 100 B: 11 / 100 Saturday (~50% conversion): A: 5 / 10 B: 45 / 90 ----------------------- A: (10 + 5) / (100 + 10) = 13.6% B: (11 + 45)…

Thanks for your reply. That was my deleted post up there, I worked out a table like yours and realized your point shortly after posting.

Re: Why multi-armed bandit algorithm is not "better" than A/B testing

#54
post #43

Earlier quoted context omitted.

It seems like most people who use these content optimization tools don't really understand the statistics involved. What are your thought on this? How do you educate your users on the merit of your approach vs a/b testing when the topic is so complex? Also, despite this being a slightly pro a/b testing post, I have to say it's actually made me more interested in trying out Myna's approach MAB algorithm.

Same way every product from GWO and T&T on down: show a pretty graph that ignores the underlying assumption that it's even possible to use statistics to conjure certainty from uncertainty, and trust that users will never know or care about the difference. /former AB test software dev who fought my users to try to stop them from misinterpretation results, and failed.

If it gives you comfort, if there is a significant underlying difference and the calculations are done right, with high probability they will get the right answer even though they are misunderstanding the statistics.

Acceptance of this fact has avoided a lot of potential ulcers for me.

Re: Why multi-armed bandit algorithm is not "better" than A/B testing

#55
I cannot help but think that under a sufficiently precise set of assumptions (prior knowledge about the various one-armed-bandits, cost of losses, gain of winnings, expectations of being still in business in the future, etc), there is a provably optimal strategy.

Isn't there?

Re: Why multi-armed bandit algorithm is not "better" than A/B testing

#56

Earlier quoted context omitted.

This comment just sold me on MAB. You can just keep on throwing variations on a design at the system without having to make tenuous decisions. I hope all the A/B tools implement this soon.

Don't wait: http://mynaweb.com/ [Yes, this is a shameless plug for my startup.]

You camouflaged your sign up button with a nature color. Took me the longest to find it.

Re: Why multi-armed bandit algorithm is not "better" than A/B testing

#57
post #50

(For previous discussion on this topic, see http://news.ycombinator.com/item?id=4040022. ) Let's stop a bad meme before it gets going. Multi-armed bandit is a general problem. There are many strategies for tackling it. An epsilon-greedy strategy is one strategy. It is not the only strategy, and it is not even a particularly good one. There are many others. In fact A/B testing is itself a solution to the multi-armed b…

> I believe that I can produce a multi-armed bandit algorithm that has logarithmic regret and will work in the face of ever varying conversion rates, as long as there is a consistent relative difference between the versions.

That sounds interesting. As you undoubtedly know, there is a lot of literature on multi armed bandit problems and also on the non-stochastic multi armed bandit problem. The latter has the advantage of not assuming anything about the way in which the sequence of rewards is generated.

There is a a line of work in the non stochastic setting which sounds related to what you are describing. It's called the problem of tracking the best expert: http://www.cse.ucsc.edu/~mark/papers/track-long.ps The idea in this problem is to do well as compared not to the best fixed action but rather the best piecewise constant sequence of actions. There are many variations of this problem, but the basic idea is that you can have low regret as compared to a changing sequence of actions so long as that sequence doesn't change too "quickly" for some definition of quickly.

Re: Why multi-armed bandit algorithm is not "better" than A/B testing

#58
I found it very interesting that MAB-90 was outperforming RAND on both convergence speed and average conversion rate in the first experiment. This seems a very interesting result, albeit not the one you might be looking for in the article. I find it rather disturbing that this dataset was removed in later experiments. It actually seems to provide a very valuable insight namely: Multi-Armed Bandit strategies might be better than A/B testing but the exploration factor should be far higher because of the need for rapid convergence to significance.

Re: Why multi-armed bandit algorithm is not "better" than A/B testing

#59
post #50

(For previous discussion on this topic, see http://news.ycombinator.com/item?id=4040022. ) Let's stop a bad meme before it gets going. Multi-armed bandit is a general problem. There are many strategies for tackling it. An epsilon-greedy strategy is one strategy. It is not the only strategy, and it is not even a particularly good one. There are many others. In fact A/B testing is itself a solution to the multi-armed b…

> I believe that I can produce a multi-armed bandit algorithm that has logarithmic regret and will work in the face of ever varying conversion rates, as long as there is a consistent relative difference between the versions. That sounds interesting. As you undoubtedly know, there is a lot of literature on multi armed bandit problems and also on the non-stochastic multi armed bandit problem. The latter has the advanta…

Thanks for the link. I'll read it asap. For anyone following along at home, I believe Yisong Yue's work on the duelling bandits is also relevant here: http://www.yisongyue.com/publications/jcss2012_dueling_bandi... and http://www.yisongyue.com/publications/icml2011_beat_the_mean... (I haven't had a chance to read these in detail, yet.)

Re: Why multi-armed bandit algorithm is not "better" than A/B testing

#60
post #49
post #46

Earlier quoted context omitted.

[deleted]

The problem with this math is that the difference in the scores on Friday are already pretty significant ( http://www.thumbtack.com/labs/abba/#A=60%2C500&B=40%2C50... ) Here is the absurd case. The conversion rate is 10% on Friday and 50% on Saturday: Friday (~10% conversion): A: 10 / 100 B: 11 / 100 Saturday (~50% conversion): A: 5 / 10 B: 45 / 90 ----------------------- A: (10 + 5) / (100 + 10) = 13.6% B: (11 + 45)…

The human factor in split testing is rarely to almost never discussed. I've been building and running landing pages for around 7 years now, I can't count how many millions of people have flowed through them.

Here are some things I've found:

1) Absolute conversion rate. After a certain point, whatever you add will just detract from the performance of something else. That detraction could either be from the landing page itself (if your lucky) or some longer term variable (hope those "conversions" don't cost you too much money.) I have had both occur.

2) "Statistically significant" can just be noise when variables are fairly close to each other. After getting rid of the obvious losers, I've watched the "winner" of elements like button color change back and forth daily for weeks, with no clear winner, even with 30,000+ conversions a day flowing through. This is the kind of thing visualwebsiteoptimizer would write a case study on 1 hours worth of traffic and declare a winner.

3) You brand can be shit on when dealing with returning users. They are used to seeing one thing and now they see something else. Imagine if the colors, theme, and button locations changed every day (or to be fair, once a week) when you visited hn. Often "better converting" designs actually convert worse when introduced on existing customers.

4) Failure to account for external variables, especially when dealing with small sample sizes. Testing is often done most vigorously with paid traffic sources as the monetary incentive is direct. The traffic source itself is often a bigger determining factor behind the conversion rate than the design. Small budget/sample size, and you could end up with some pretty poor test results that the math will tell you are correct.

I am not saying don't test. I am saying a/b testing, split testing, multivariate testing, etc is abused

Post reply on HN