The Lifecycle of a Server Side TestTo run experiments with server-side testing, just like any other A/B testing, you begin with a hypothesis. “We think this new search algorithm will be more effective,” or “we think this simplified user interface will improve conversion rates,” or whatever it is. Once the hypothesis is determined, all variations have to be built. This is a key difference between server-side and client-side tests. Using the type of WYSIWYG editor provided by many client-side testing tools, marketing and product teams are able to perform tests without having to actually implement the alternate variations. On the other hand, all the different variations in a server-side test must be actually implemented by the developers. After the test is complete, significance is calculated, and the winning variation is determined, it’s time to roll out the winner. There is another key difference between server- and client-side testing here: in a client-side test, once the winner is determined, it has to be built and implemented, whereas in a server-side test, all variations have already been implemented (and are probably just behind feature flags), so it’s a simple matter of rolling out the winner to all users. So in short, server-side testing is slower when the alternate versions don’t win (because the developers built them for nothing), but faster when they do (because they’re already built and just need to be rolled out).
Server Side Testing Use CasesBy now, you’ve probably realized that the question is not “server side or client side testing, which is better?” – it’s “server side or client side testing, which is better for you?” You should probably use server side testing if:
- You want to be able to test across multiple platforms, from web applications to mobile apps
- You want to be able to test across the full stack
- You want to test without it impacting your users on the front-end, either from longer page load time or “flickering”
- You have the developer resources to do a deployment for each experiment