small tech here - 2 people, site with ~1-2m active users per month. We do A/B tests for the majority of changes that could affect engagement or conversion. The infrastructure and plumbing is cloudfront assigning cookies and serving different HTML based on a cookie, and cloudwatch logging user interactions with the cookie included into timestream, where I can run queries manually (no automated resolution, decision making, rollback etc). An A/B test usually takes about a week to accumulate enough traffic for confidence, and we don't run them in parallel.
Each A/B test gets a dedicated expectation criteria (so we have no overall evaluation criteria that stays stable across tests). So in the "Experimentation Maturity Model"[1] language, we're kind of in the "Walk" phase.
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.
Thanks for the link. Very succinct. Coincidentally, just a week back, I ordered the book it mentions.
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) ?
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.
small tech here - 2 people, site with ~1-2m active users per month. We do A/B tests for the majority of changes that could affect engagement or conversion. The infrastructure and plumbing is cloudfront assigning cookies and serving different HTML based on a cookie, and cloudwatch logging user interactions with the cookie included into timestream, where I can run queries manually (no automated resolution, decision making, rollback etc). An A/B test usually takes about a week to accumulate enough traffic for confidence, and we don't run them in parallel. Each A/B test gets a dedicated expectation criteria (so we have no overall evaluation criteria that stays stable across tests). So in the "Experimentation Maturity Model"[1] language, we're kind of in the "Walk" phase.
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/
Thanks for the link. Very succinct. Coincidentally, just a week back, I ordered the book it mentions.
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.
So pure theoretical thinking now, but:
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.