Live data from Hacker News

A/B testing mistakes I learned the hard way

newsletter.posthog.com

11–20 of 30 posts

Re: A/B testing mistakes I learned the hard way

#11
post #5

I feel like I've too often seen in products new (anti)features that are way too easy to accidentally click, and whenever I do accidentally click I just imagine it's increasing some statistics counter that's ultimately showing the product managers super high engagement, clearly meaning the users must love it to be using it all the time

Then in the code there’s a bug that over/under reports those clicks (because ui is not procedural code that lends itself to straightforward metrics) and i think this could explain Spotify’s product decisions.

Re: A/B testing mistakes I learned the hard way

#12
post #5

I feel like I've too often seen in products new (anti)features that are way too easy to accidentally click, and whenever I do accidentally click I just imagine it's increasing some statistics counter that's ultimately showing the product managers super high engagement, clearly meaning the users must love it to be using it all the time

Several years ago Google implemented this A/B feature in which you had to choose one image or another. Do you remember that one? Ofcourse I always chose the wrong one ;) It didn't last long.

Re: A/B testing mistakes I learned the hard way

#13
post #5

I feel like I've too often seen in products new (anti)features that are way too easy to accidentally click, and whenever I do accidentally click I just imagine it's increasing some statistics counter that's ultimately showing the product managers super high engagement, clearly meaning the users must love it to be using it all the time

To your point, my company is doing some A/B tests and I insisted that we not just measure conversion ("it works") and additionally measure some metrics that would indicate that it works _well_. For example, if you have a carousel of products, and someone buys something from the carousel, then it "works," but it would work _better_ if the item they bought was the first thing on the carousel rather than the last. That indicates that we showed relevant products first, which is better than showing the relevant product last!

Sure, conversion would go up if it was in the first slot versus the last, but it takes effort (however little) to scroll through a carousel, so ensuring that we can measure the quality of the result and not just the quantity is really important.

This is one way I've tried to avoid the problem you describe. It's not enough that people can engage with the feature, but they need to engage with it meaningfully and in such a way that would encourage repeat behavior.

Another example of what you describe is that on our site if you search for "neon blue guitar", don't interact with the search results whatsoever, go back to the home page, click on a product on a carousel, and purchase _that_ product, it counts as a "successful search event," even though the search technically failed because they didn't interact with it in any meaningful way. To your point: PM is happy; user is not.

TL;DR it's really important to think through tests and how you measure success!

Re: A/B testing mistakes I learned the hard way

#14

The article says 'Changing the color of the "Proceed to checkout" button will increase purchases.' is a bad hypothesis because it is underspecified. But what else is there to measure other than checkout button click count(and follow up purchases) to measure the effect of button color change? Or perhaps this is not a robust example to illustrates undespeficaition?

The number of people who start checkout and the number of people who check out are different, and I think that was what they meant

Re: A/B testing mistakes I learned the hard way

#15
post #5

I feel like I've too often seen in products new (anti)features that are way too easy to accidentally click, and whenever I do accidentally click I just imagine it's increasing some statistics counter that's ultimately showing the product managers super high engagement, clearly meaning the users must love it to be using it all the time

[flagged]

Re: A/B testing mistakes I learned the hard way

#16
post #5

I feel like I've too often seen in products new (anti)features that are way too easy to accidentally click, and whenever I do accidentally click I just imagine it's increasing some statistics counter that's ultimately showing the product managers super high engagement, clearly meaning the users must love it to be using it all the time

To your point, my company is doing some A/B tests and I insisted that we not just measure conversion ("it works") and additionally measure some metrics that would indicate that it works _well_. For example, if you have a carousel of products, and someone buys something from the carousel, then it "works," but it would work _better_ if the item they bought was the first thing on the carousel rather than the last. That…

> but it would work _better_ if the item they bought was the first thing on the carousel rather than the last

Depends, does that increase overall sales? Or is it ‘better’ to make the customer ‘walk past’ the other items to get to the thing they want (the way supermarkets make you walk up the back of the shop to get to the milk), and maybe buy something else too?

Re: A/B testing mistakes I learned the hard way

#17

That's not Simpson's paradox! > In fact, while the new flow worked great on mobile, conversion was lower on desktop – an insight we missed when we combined these metrics. > This phenomenon is known as Simpson's paradox – i.e. when experiments show one outcome when analyzed at an aggregated level, but a different one when analyzed by subgroups. There's nothing strange about finding out that some groups benefit and oth…

> I would add a 7th A/B testing mistake to that list and it's not learning about basic probability, statical tests, power, etc. Flying by the seat of your pants when statistics are involved always ends badly.

This is where most tests fail, in my experience.

Everyone wants to run A/B tests because that’s what the big co’s are doing and they want to look like the sort of person BigCo might hire, but they’re making silly mistakes because stats is hard and not taught well at school.

Re: A/B testing mistakes I learned the hard way

#18

Earlier quoted context omitted.

This is the most "damned if you do, damned if you don't" part of testing. I've found so many coding errors that weren't obvious until you looked at the day 2 or day 3 test results. "Hm, that's weird. Why is $thing happening in this test? It shouldn't even touch that component." If you peek, you really have to commit to running the test for the full duration no matter what.

No you don't. If your protocol involves peeking (and early stopping), you need different thresholds to declare statistical significance. But you can do that. You just need to know whether you're peeking or not, which everybody does.

[deleted]

Re: A/B testing mistakes I learned the hard way

#19
post #5

I feel like I've too often seen in products new (anti)features that are way too easy to accidentally click, and whenever I do accidentally click I just imagine it's increasing some statistics counter that's ultimately showing the product managers super high engagement, clearly meaning the users must love it to be using it all the time

One thing I always accidentally click is the animation-expanding Google results when I return back to the search results after visiting one of the result pages, while trying to quickly visit the next result’s page.

Re: A/B testing mistakes I learned the hard way

#20
post #3

#2 is a slippery slope if you don't do it properly. You might look end up looking at lots of different slices of your data, and you might come to the conclusion, "Oh, it looks like France is statistically significant negative on our new signup flow changes". It's important to make sure you have a hypothesis for the given slice before you start the experiment and not just hunt for outliers after the fact, or otherwise…

I agree, as per example and point number one, if your goals was to increase conversions, you were successful. You can then go to the next step, slice the data up, and iterate on another change. If you fall into the box of over-analyzing you will probably find all sorts of irrelevant patterns.
Post reply on HN