Server-side A/B testing has no technical cons, making it the safest, most reliable, and fastest way to conduct experiments when done correctly. In fact, the server-side approach should be the only form of experimentation. 🚀
There are several myths about server-side A/B testing that you may find on the internet:
- Server-side A/B testing requires a higher level of technical expertise and resources.
- Server-side A/B testing is often slower and more time-consuming.
- Server-side A/B testing is not always necessary for every situation.
All of them not true.*
*if you can address these these 3 challenges:
(1) Missing Growth-Mindeset
💭 Over the years, marketing departments have gained experience with CRO and have become the main drivers of experimentation and growth. Meanwhile, IT departments have taken a different path, and there is a high chance that they do not have individuals with a growth mindset who are willing to put in the work to conduct experiments. Even if companies believe they are data- and/or experiment-driven, I think most of them are not. For sure some Teams or departments are, but I don’t think this is true for “the company” or especially for IT-departments.
It's important to note that there are no quick fixes for people or culture. As marketers and growth advocates, it's our job to share our insights and the potential benefits of CRO, and show how it can have a positive impact on the business.
(2) Tech-Infrastructure
Tech and infrastructure are naturally developer-driven, and decisions are made primarily for maintainability and scalability. This sounds good, but if you look at successful companies like Netlify and Facebook (when it was really successful at growing before it became Meta :D), their tech teams were very early (and still are) driven by growth-minded individuals or even engineers who are part of the Growth Engineering Team. Netflix, for example, found a way to scale with A/B testing by rebuilding their entire infrastructure. They also managed to solve, in my opinion, the major problem with server-side A/B testing: making regular rollouts and deployments independent from the A/B testing code. If you want to get a bit nerdy, I highly recommend the Netflix Tech Blog: https://netflixtechblog.medium.com/
Can the infrastructure be fixed?
No, it's not possible to just rewrite your entire backend and adjust your infrastructure in a matter of weeks or months (unless you're small enough to do so or really really commited and willing you put a lot of resources in it). Over the years, as it has grown, there are so many unclear dependencies that it becomes nearly impossible to prepare it for A/B testing. This leads me to the conclusion that I see no chance that server-side A/B testing will be part of most companies' methods for increasing experimentation. Yes, it would be great to do it, but if you can't afford to work on your infrastructure, you'll probably be stuck in the client-side space.
(3) Growth-Strategy
Is experimentation a key component of your growth strategy? Does leadership truly support this approach? If the answer is no, it may be best to avoid implementing Server-Side-Testing. Changing the infrastructure and culture at that scale requires strong management support.
So, should you bother with server-side A/B testing? ❔
It depends on your goals and resources. If you want to scale your experimentation efforts to the level of companies like Netflix, Meta, or Booking.com, then server-side A/B testing is the way to go.
However, client-side testing is still great, and if you're using one of the awesome tools out there, I would still stick with it. While it would be ideal to use server-side A/B testing, you can still achieve great success with client-side testing.
