Everything about A/B testing server-side with Kameleoon Full Stack
After several months in beta version, Kameleoon Full Stack is now available to all our customers. At the start of the year, we told you that the server-side A/B testing version of Kameleoon would soon be available. And now it is: our SDKs are available for the Java, .NET (C#), Node.js and PHP environments as well as for mobile platforms (iOS and Android).
Why use server-side?
Working server-side means testing your conversion optimization hypotheses through your back-end architecture rather than via your visitor’s browser (client-side A/B testing via a JavaScript tag). Whereas our JavaScript framework retrospectively changes HTML pages once these have been generated by the server via standard DOM-handling APIs (client-side testing), our server SDKs let you make these changes directly at the point where the HTML pages are generated (server-side testing).
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
When running your tests server-side, you can, if you wish, completely remove the Kameleoon JavaScript tag from your website: this will reduce the total page weight served to your visitors.
Nonetheless, it may be worth keeping a light version of the tag, to incorporate the results of your server A/B tests into your web analytics solution for example. With regard to the traditional flickering inherent to JavaScript testing solutions, Kameleoon eliminated this two years ago, but the script does need to be installed at the top of the page, outside of any tag manager. If this is not possible for reasons specific to your technical infrastructure or integration policy, then Server-Side is a good alternative since flickering simply does not occur.
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 segmentation
Server-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 tests
Server-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.).
