Why use server-side?
A simple if/else type-code in your back-end environment, coupled with our SDK method call, lets you create two variations to distribute to your visitors. Frequently, we would use two different template versions (.JSP, Jinja, Smarty, etc.) in each of the if/else branches, but it is also possible to test hypotheses that are more complex than a simple template change. This therefore broadens the realm of possibilities compared with client-side testing.
Server-side vs client-side: the benefits and advantages
The request for a server-side solution first came from some of our German customers, whose performance requirements outweighed their agility requirements. Generally speaking, this kind of request comes from the technical teams who are responsible for testing, because they are looking to carry out their tests directly in a server environment. As a reminder, working server-side has the following advantages:
- Devoted to the needs of developers and product teams
Server-side testing broadens the realm of possibilities compared with client-side testing. You can push your optimization strategy further and thoroughly test your product’s technical and technological architecture: the impact of a new technology on your website’s performance, how new search algorithms or product recommendations impact your turnover, etc.
The reporting interface remains the same as when you use Kameleoon for client-side testing. Its functional depth will enable you to accurately measure the results of your optimization strategy.
- Omni-channel optimization of customer journeys
In server-side mode, you can even deploy your experiences in environments that are not based on classic web architecture, such as native mobile applications, on smartphones and tablets. You can instantly deploy your optimizations across all the channels used by your customers.
- The guarantee of optimal performance
An optimal technical architecture compatible with your technological stack
We have built our applications to enable A/B test variations to be assigned internally to the SDK rather than dedicated to a remote Kameleoon server call. The call made to our servers by the SDK is therefore only a tracking call which can be asynchronous rather than synchronous and blocking. The coupling between the host IT system and the Kameleoon servers is therefore removed and the performance and the stability of the host system remain completely independent of Kameleoon.
Furthermore, this architecture offers a significant security guarantee, unlike the SDK architectures using a synchronous blocking call. The code below shows an example of our Java SDK.
"The addition of features allowing the implementation of server-side A/B testing fulfils our vision of a unified testing platform. We are particularly pleased with the architecture we chose: it has no impact on the time it takes to generate server-side pages, yet guarantees optimal stability and is simple to configure and use." -Jean-Noël Rivasseau, Founder and CTO of Kameleoon
Targeting vs segmentationServer-side tests are carried out “naturally” by the simple fact of coding the test implementation at the right place in your source code. So targeting is frequently less important than in client-side tests. However, in addition to the segmentation features already available in our test reporting, certain targeting criteria will be implemented in a future version of our SDKs planned for the second half of 2018.
3 examples of server-side testsServer-side and client-side testing are two complementary tools used in a conversion optimization strategy. Although some tests can be run using either method, some depend exclusively on server-side testing. For example, our customers run server-side tests when:
- implementing new features impacting the architecture of their product, such as the roll-out of new search or product-sorting algorithms. The latter are intrinsically linked to the organisation of their product catalogue and thus their back-end.
- developing their pricing strategy, in particular for delivery costs. The test must be run server-side to accurately calculate the impact of an offer not only on the conversion rate but also on the LTV (lifetime value) of customers.
- rolling out new tools (payment, product recommendation, etc.) including the product or merchandising teams. These tools take into consideration information located in the back-end (remaining stock, delivery addresses, etc.).