2. Develop and deploy all the variations of your experiment on your server.
At other times, they do so for improved speed. While testing doesn’t slow down a website or cause serious performance issues, it adds a second or two to a website’s perceived loading experience. Server-side can make this speedier.
If you were a B2B SaaS business instead, you’d be able to run a client-side experiment to determine if a certain UVP works better on your homepage. Or if a long-form copy could beat a short-form one.
When it comes to running experiments, optimizers can choose between client-side and server-side testing.

Client-side Testing Vs. Server-side Testing

What’s the difference between client-side testing and server-side testing?

You’d then seek development help to roll out the winning version if the control happened to lose.
In this case study, a SaaS company used Convert Experiences as their client-side A/B testing tool to increase growth in leads by 61% on their homepage:
You might also need to clean up your servers, post the final rollout/rollback.

3. Set up the experiment (set the audience targeting conditions, experiment duration, sample size and split, confidence level, etc.)

Client-side Testing Might Seem Simple, but It’s Potent.

Because testing such deep product-level changes takes a lot more than simple browser-based JS manipulation, it can’t happen inside the browser and needs to be tackled at the server level.
In server-side testing, on the other hand, once a user requests a page, your server determines the version to deliver and delivers just that. Your experimentation tool works on the server and not inside your user’s browser.
And choosing the right one needs careful consideration. There are many aspects to weigh when making this choice. Look at the setup’s impact on speed and SEO, the effort and time requirements for the experiment life cycle, the experiment’s goal and more. They often do so to avoid “flicker” or the “Flash of Original Content” phenomenon. Flicker happens when the experimentation tool changes the original content served by the server after the end-users have already seen it. Imagine your users seeing a certain headline and then seeing it change in a flash to another one. (Yes, flicker can seriously compromise a user’s experience!) 1. Create your experiment in Convert Experiences

But Server-side Testing Indeed Lets You Test More.

While server-side testing has its unique use cases, some companies use it for running even the cosmetic tests —  tests that would run perfectly glitch-free even on the client-side.
2. Use the WYSIWYG editor and build the variations.
The server will then read your cookie and
serve a version (and all the subsequent sessions) accordingly.
Likewise, if you were a B2C SaaS business, you’d be able to run a client-side experiment to learn if a certain pricing plan could work better than the others. 1. Log in to a tool like Convert.
But if you wanted to test a new search algorithm that could bring up more relevant search results (and which would, in the long-term, result in more sales), you’d need to run a server-side A/B testing experiment.
As you can see, the life cycle of a server-side experiment is long and complex unlike that of a client-side one. That’s why going with server-side testing needs some deliberation.
In such server-side experiments, your code needs to tell the server which variation to show to a current user. You could use cookies to facilitate this. For example, to implement an A/B server-side test with Convert, you’ll have to set up a cookie with the following data:
Here’s another A/B testing experiment using Convert Experiences as the client-side testing tool for the same SaaS company on its pricing page that led to a 57% increase in leads:
And done. Here, you’ll have to:
Server-side testing, however, isn’t so straightforward.
5. Roll out the winning version and roll back the losers.  3. Map your server-deployed experiences in Convert Experiences using custom code (by using your experiment’s id, the ids of the variations as set in your experimentation tool and more).
Most conversion optimization success stories you see online are client-side tests that successfully optimized an experience at the surface-level and won big.
Also, for such experiments, opting for server side experimentation when you have a few great client-side A/B testing tools that let you run them flicker-free without impacting your SEO or speed doesn’t promise the best use of your testing bandwidth.

Implementing Server-side Experiments

In client-side testing, you only need limited design and development resources to build your experiments and execute them. You won’t even need these if you’re only making text changes or changing the color of a button. All you’d need to do is:
Because your server determines what version to send to a user, the targeting happens at the server (and not inside the browser as with client-side testing). Your testing precision will depend on how well you can code your targeting conditions on your server. With client-side testing though you can laser target your audience for all your experiences.
Also, server-side testing can get more complex in a multi-server setup and also when a CDN needs to be integrated.
However, if you wanted to test a better recommendation engine, you’d have to go for server-side testing.
But whether it’s this or something as big as testing a redesign or a revamped page, client-side testing impacts a business’s bottom line.
However, that would be discounting client-side testing.
Occasionally, a company might run a server-side experiment in place of a client-side one because of privacy or security concerns. As the audience targeting happens at the server and the experimentation code resides on the server in server-side testing, companies get better control on its privacy and security aspects.
While you can run almost every client-side test on the server-side and a few light-weight backend experiments via client-side testing (using split URL or redirect experiments), doing so won’t be as feasible or robust as you’d like… because, for any hypothesis, only one of the two works the best.
But if you wanted to test a faster backend and see if it could improve retention or engagement, you’d need to run a server-side experiment. If you wanted to test a new onboarding sequence, again, you’d need to go for a server-side experiment. Because besides supporting your new onboarding workflow, server-side testing would also let you orchestrate a multi-channel experiment spanning across emails, SMSes and others that take place over different devices.
Server-side experiments should be preferred only when they make a strong case for the given hypothesis. And they do so quite a few times because many experiments that impact a business’s bottom line metrics can happen only on the server side.
Let’s put this into perspective with a few scenarios.
As you can understand from the different use cases of server-side testing, it’s geared more toward building better products rather than winning immediate conversions. Unlike client-side experiments that focus on immediate sales or conversions, server-side experiments focus on optimizing the product or solution so that the lifetime customer value increases.

So tell us… have you run any server-side tests? If so, what was the most difficult part of the process? Oh, and if you want to run a server-side A/B test, check out Convert (it’s free for 15 days!) Running even a single server-side experiment is challenging because developing and rolling it out is a more resource-intensive and time-consuming process.
In client-side testing, once a user requests a page, your server delivers it. BUT, in this case, your experimentation tool implements some Javascript inside your user’s browser to alter the content delivered by the server so that the end user gets the appropriate variation based on your targeting rules. (The browser is the “client.”)
When you need to test deeper than the frontend, you need to go with server-side testing.

Because client-side testing only happens with browser-level JS execution, you can only test surface-level things such as layouts, colors, and messaging with it. Some optimizers dub such tests as “cosmetic” tests.
If you were an eCommerce business, you’d be able to use a client-side A/B testing experiment to learn if a redesigned search bar could increase your in-store searches (and result in more sales).
Let’s go over these factors and see how client-side testing differs from server-side testing and the pros and cons of each.
Besides, if you use server-side testing to test changes that can be easily validated client-side, hitting a good testing velocity and a robust experimentation program will be difficult.

In General, You Wouldn’t Run a Server-side Experiment If a Client-side One Would Do…

But implementing a server-side experiment isn’t feasible always, especially when a client-side would do just as well.
It’s easy to dismiss client-side A/B testing as the “easy testing” that anyone can do. Agreed: it’s easy to implement. And sometimes, it can be as small as testing a different CTA button color or copy.
4. Run the experiment.
Grab the JS code and add it to your website.
You could say that if client-side testing is for marketers, then server-side testing is primarily for product and engineering teams. And A/B testing tools like Convert Experiences offer both client-side and server-side testing to accommodate both marketing and engineering teams.

Similar Posts