The overhead is not really significant, as the whole thing is pretty much automated now. We just have two different versions of HTML built and deploy cloudfront by turning on a parameter in the deployment template which pages to split for A/B.
I definitely feel it's worth it. Tweaking things on the homepage brought a measurable 17% increase in conversions. Testing out a redesign of a key component of a proposed redesign showed that we'd be significantly damaging engagement. Lots of results contradicted my intuition over the years (in both directions). Because it's easy to spin up a test, I tend to do it whenever there's an important decision to make.
Our ad-hoc setup prevents us from reliably running multiple tests in parallel, and we do not have any kind of systematic measurement for novelty and primacy effects, but at the level and complexity at which we operate that's fine. I treat test results as more evidence/confidence, not as final evidence. If the test looks OK we'd deploy, then still monitor if the key engagement metrics go up or not, and if not we'll roll back. This happened more than a few times over the last few years. In theory a more systematic platform helps to prevent that, but even then if you aim for 95% confidence, this means that 5 out of 100 decisions you made are probably not justifiable, so it doesn't absolve people from follow up monitoring and judgement. We did A/A tests and holdout testing for a bit but gave up on it (since it's difficult to run multiple things in parallel with our setup, then an A/A test or a holdout would delay further experimentation).
> Trying to understand at what “scale” does A/B testing make sense for organisations
My thinking about this is that when the traffic you have crosses the threshold where you can get meaningful results in a reasonable time (few weeks). Before that it's just numerology. You'll get some numbers, but they can't really drive decisions reliably.
[1] https://www.votito.com/methods/experimentation-growth-model/
I completely agree with everything you mentioned (And thanks for giving in numbers too!).
Since you’ve clearly thought this through, if I can push you to the hypothetical - at what point would you want to run multiple tests in parallel? Will it be largely a function of your dev team (more productive everyone) or active users (more frequent feature build outs / cross cutting rollouts) ?
Thanks again for the note. Very helpful.
1) running multiple tests in parallel becomes important where the product/dev frequency exceeds waiting for a single test to finish, which is roughly a week for us. the business is currently relatively stable and doesn't change a lot, and I don't have big ideas that would need measurement so frequently, but if I did, I'd probably look for ways of running things in parallel. So I don't think it's a function of the dev team as much as what you reasonably want to measure. Having said that, I can imagine a larger dev team implying multiple product people, and those might want to have their own experiments/ideas measured in parallel, so there is something there definitely about the size of the dev team as well
2) if we wanted to be very scientific about the whole thing, we'd need multiple tests in parallel, particularly for novelty/primacy holdouts and to reconfirm that certain things actually hold across time. e.g. if I decided that variant A is better than variant B but our traffic changes (which it kind of it did over the last 3-4 months with AI overviews killing clicks from Google), maybe the reduced set of people we get behaves differently than the larger set we measured against a year ago. so I'd probably want to re-run critical experiments and just confirm them.