As experimentation programs mature, they build increasingly more sophisticated tests. In fact, according to a recent Kameleoon report, nearly half of digital leaders say their investment in feature experimentation is high... with good reason!
But building more sophisticated tests requires more agile testing expertise, dev support, or new technologies.
At some point in your optimization journey, you will (hopefully) make the leap from pure client-side to server-side experimentation. When you do it and how you do it depends on your organization and priorities.
This guide and checklist are meant to help experimentation programs learn when, if, and how they should adopt server-side testing, in addition to running A/B tests client-side.
Most programs start with a graphic or front-end code-based approach. Mature ones leverage both. Advanced programs and/or teams just beginning with server-side testing may rely on hybrid experimentation. While dedicated programs may evolve to also practice server-side testing, keep in mind that the real goal is to know which method is right for the intended test and have the means to execute all tests well, ideally by any team.
The main benefit of client-side experimentation or web experimentation is that it is "easy" on the front-end for anyone to build, launch, and run A/B tests.
Experimentation on the backend, however, is a different story.
While it is more powerful, server-side A/B testing requires backend developer resources. As most companies know, getting dev support can be a huge challenge.
This friction has made server-side experimentation a more challenging practice than standard web, or client-side, optimization for most teams. It's certainly worth the effort, but an unprepared team may struggle to implement and scale their program.
It’s important to note that client and server-side A/B testing are NOT exclusive; they are complementary. Brands should be able to decide which approach is best for their optimization goals and strategies.
This guide is meant to help programs understand the pros and cons of each approach and how to adopt server-side testing.
Server-side testing is not just for engineering-led experimentation programs. Programs choose or evolve to practice server-side testing because it overcomes key client-side limitations. By enlisting developers (see the checklist below), server-side testing can help DevOps and IT teams get behind testing, as they are able to see the testing process in action.
1. Server-side A/B testing enables feature experimentation . For those companies that rely on products to also spur growth (product-led growth, or PLG), server-side testing enables organizations to test and optimize product and feature variations.
2. Server-side A/B testing allows teams to build experiments that have a high degree of complexity and/or that test:
3. Server-side A/B testing also helps experimenters better manage:
In a client-side test, your A/B testing script modifies web pages directly in the visitor's browser (whether Chrome, Firefox, Safari, Opera, etc.). Client-side web testing is also called web experimentation because the browser must be involved, i.e., it is only for websites. What is usually called client-side testing is a test built with a graphic editor or with JS/CSS code.
To do client-side A/B testing:
Benefits of client-side A/B testing:
Client-side testing has its disadvantages:
In server-side A/B testing, test variations are rendered directly on the server, not on the visitor's browser, like in client-side testing. Changes are directly generated before the HTML pages load.
To create server-side A/B tests:
Benefits of server-side testing
The downside of server-side testing
James McCormick, VP of Marketing at Creativex, shares with Kameleoon what practices and qualities leading companies that practice full-stack experimentation possess.
It’s not organic. There’s a plan to get it right.
Leading companies that practice server-side testing are mature and purposeful. They know how valuable experimentation is and they want to scale it. They understand the importance of data but also grasp how critical it is to have empathy for the human engaging in the digital experiences the company is creating.
I like to use the acronym "DART" when describing these types of leading companies.
They know how to capture and extract value from data. In addition to understanding data, they can activate it by building experiments, enriching their customer profile, sending personalized messages, etc. Leading companies can do this in real-time, so the experience feels fresh and relevant. Lastly, they know how important trust is, so they’re transparent about how data is used. They’re proactive with consent management and protecting customer data.
Management is engaged, but practitioners know how to sell their value
Becoming data-driven and scaling experimentation always requires a top-down approach but that doesn’t mean senior executives are data experts. Executives know that a customer is more than a click, a visit, or an uplift. When experimentation leaders from leading companies engage executives, they present performance data but also include in-session excerpts from real customers that demonstrate how an experience is failing or winning. They present the real person, and that resonates with management, who in turn keeps investing in optimization.
It’s the scale of server-side testing that appeals
Digital-first companies know that if they’re going to create an optimized customer experience, they’re going to have to analyze and test everywhere they can, not just on their website. Full-stack testing gives them the ability to achieve testing at scale. Powered by human-centric analytics that reveals the entire customer journey across multiple touchpoints, they’re able to build, release and test features on every channel, while carefully controlling performance and security.
Many experimentation programs are beginning to run "hybrid experiments" which combine the benefits of client-side with server-side testing.
A hybrid experiment is a server-side test that benefits from key client-side capabilities. While developers are required to build the test, they are not needed to code tracking, pull in external segments for targeting purposes, or to configure integrations to third-party testing tools.
Hybrid experimentation saves developers’ time. A backend developer only has to engineer the logic and function of an experiment that is part of your test plan.
This is another reason that server-side testing is good for brands; the 2025 Experimentation-led Growth report found that reducing developer bottlenecks is one of the most effective ways to scale experimentation.
For example, the back-end developer would code when and how a pricing page would change based on visitor characteristics, whereas a front-end developer or product manager would design the look and language of the pricing options.
With hybrid experimentation, non-technical teams can still make front-end changes (such as designing CTAs, colors, or wording) using client-side technology, all within the same experiment. You’ll be able to run concurrent tests if you wish.
Developers don’t need to set up tracking or build complex integrations with the tools you use every day. While developers build the experiment code server-side, experimentation leaders, marketers and/or product managers can set up KPIs for each test using client-side technology or use pre-built integrations to target users based on data available in their preferred tools (Contentsquare, Mixpanel, Segment, Amplitude, etc.).
Anyone can iterate, analyze, and activate data derived from the test. With hybrid experimentation, once developers configure the test, anyone can iterate on and analyze it without needing developer involvement. Marketers and/or product managers can activate data derived from the server-side test.
Not all A/B testing platforms can provide hybrid experimentation. Only when the underlying architecture to create client and server-side tests are the same, like Kameleoon’s, can an A/B testing solution provide hybrid experimentation.
Unfortunately, most software testing tools have one testing platform to create client-side tests and another for server-side. This means programs must consider two different user interfaces, data models, and more. It’s not recommended.
Remember, server-side testing doesn’t replace client-side testing. They’re complementary, and good test managers will know which methodology makes sense for a given experiment. Smart programs know when they should build a client or server-side test.
To help you determine when you should build a server-side test, consider these use cases:
Server-side testing is not limited to optimizing hidden digital experiences i.e., algorithms. You can run complex tests on the front-end with server-side testing. For instance, if you’re changing many UX elements on a page and/or how visitors navigate your site, your test is likely to be quite "heavy." Heavy client-side tests may have performance and quality assurance (QA) issues that may cause a bad user experience.
Server-side testing not only broadens what you can test, but they’re more scalable, which is helpful when you’re making complex client-side tests.
Customers may use different devices and channels to visit your site or mobile app. Server-side testing enables you to roll out the same experiments across every channel without having to design them individually for each platform.
With server-side testing, you’ll be able to more easily measure how customers responded to a test on your website, but also how they reacted to a similar experience when delivered through other channels, such as mobile apps and email.
Since server-side tests render variants directly from the back-end server, it also allows you to test more complex, dynamic content beyond the scope of the user interface of a "static" website. This could include pricing and shipping costs on an e-commerce site generated on the server via a database rather than on the front-end.
You may wish that your search engine produces results that prioritize products that you know your customer has purchased, "liked" or viewed in the past. Spotify does something like this when it prioritizes your "Liked music" in the search results.
Creating complex "rules" that determine what digital experiences, services, and products your visitors receive often requires server-side testing because of the number of conditions, including external ones, that affect the test.
These sorts of test scenarios and personalized experiences are the hallmark of mature and advanced optimization teams, which means you likely see them at fast-growth and/or leading companies.
Like tests that aim to optimize how pricing or algorithms work, teams may use server-side testing to test how product and content recommendations affect customer behavior. While this is also possible via client-side testing, the recommendations are often based on visitor browser data. Server-side testing of recommendations may rely on multiple data sources.
Did you know? A/B testing software like Kameleoon makes it easy for non-technical teams to pull in "custom data" for targeting purposes.
As digital products are coded in the back-end, product managers rely on server-side testing to optimize their products and features. In some cases, they’ll build a server-side test to optimize a particular product or they may create a feature flag and build a feature experiment.
Client-side testing isn’t as ideal for product-led growth as server-side testing.
Back-end and full-stack developers rely on server-side testing to validate a product, app, or site’s load speed, stability, and data accuracy. Client-side testing cannot do this.
With server-side testing, the flicker effect is eliminated, and digital experiences load as quickly as the server call is set up.
Server-side testing also makes it easier to release a winning variation faster, as it is already coded into your back-end language.
As a rule of thumb, client-side tests are faster and cheaper to test but slow when it comes to implementing a "winner." Server-side tests, however, can be slower and more expensive to execute but quick to put winners into practice.
If you want something quick and directional to help you understand which direction to build your business, a client-side test may be right. If you have confidence in an idea and are willing to spend development effort to test it, then going server-side may be the right choice.
Follow this checklist to gain the buy-in and resources you’ll need to ensure your test strategy can generate ROI from server-side testing quickly and reliably.
Gain access to 28 tips on how to move to server-side testing. Access the full checklist.
Software development kits (SDKs) are critical for server-side testing because they provide developers with all the components they need to quickly take your experiments to all channels and platforms.
Executing this step is critical to setting up a positive and informed conversation with development leadership, which is next. Just like you do your research before proposing a test, you need to do your research about how your development process works.
Developers value rolling out and back features and products with confidence and ease. They like stability and efficiency. They may not value experimentation, so it’s important to speak to their needs and jobs to be done vs. your own.
You will need back-end developer support and a server-side solution to practice server-side testing. Allocating these resources often requires getting approval from senior management.
Now that you have the initial buy-in of senior leadership and developer resources, you’ll need a server-side testing solution.
Don't pick test software that will force your team to cobble together different products and scramble to scale its experimentation capabilities to fit your test plans. Pick a software solution that offers both client and server-side testing. Pick one that has dev-friendly features, in addition to the SDKs for your back-end.
Bonus: Look for a vendor that can offer hybrid experimentation, which makes server-side testing easier.
The only difference between client and server-side testing is the process of building a test. In the beginning, continue to use the same testing methodologies to ideate, prioritize, assign goals, and analyze your server-side tests as your client-side ones. Apply most of your scarce time to supporting the developers building your test.
Server-side testing is not better or worse than client-side testing.
Server-side testing is another means to learn about your customers and optimize and personalize your digital products. It broadens what you can test and comes with performance benefits. It also requires heavy developer involvement. If your optimization program feels server-side testing can help you learn more about your customers, then consider starting out with hybrid experimentation. It makes server-side testing easier.
The 2025 Experimentation-led Growth Report found that companies describing themselves as leaders in their industry were far more likely to say they did server-side testing. These are the groups that have scaled up their experimentation programs and embraced experimentation-led growth. Server-side testing is an important step towards this shift, but must be approached carefully. Remember to crawl before you walk, and walk before you run!
James McCormick, VP of Marketing at Creativex, shares with Kameleoon what practices and qualities leading companies that practice full-stack experimentation possess.
It’s not organic. There’s a plan to get it right.
Leading companies that practice server-side testing are mature and purposeful. They know how valuable experimentation is and they want to scale it. They understand the importance of data but also grasp how critical it is to have empathy for the human engaging in the digital experiences the company is creating.
I like to use the acronym "DART" when describing these types of leading companies.
They know how to capture and extract value from data. In addition to understanding data, they can activate it by building experiments, enriching their customer profile, sending personalized messages, etc. Leading companies can do this in real-time, so the experience feels fresh and relevant. Lastly, they know how important trust is, so they’re transparent about how data is used. They’re proactive with consent management and protecting customer data.
Management is engaged, but practitioners know how to sell their value
Becoming data-driven and scaling experimentation always requires a top-down approach but that doesn’t mean senior executives are data experts. Executives know that a customer is more than a click, a visit, or an uplift. When experimentation leaders from leading companies engage executives, they present performance data but also include in-session excerpts from real customers that demonstrate how an experience is failing or winning. They present the real person, and that resonates with management, who in turn keeps investing in optimization.
It’s the scale of server-side testing that appeals
Digital-first companies know that if they’re going to create an optimized customer experience, they’re going to have to analyze and test everywhere they can, not just on their website. Full-stack testing gives them the ability to achieve testing at scale. Powered by human-centric analytics that reveals the entire customer journey across multiple touchpoints, they’re able to build, release and test features on every channel, while carefully controlling performance and security.