Introducing Server-Side Optimization, a powerful new capability for developers

Chloë Lind-Oracle
Chloë Lind-Oracle Director, Outbound Product Management, CX MarketingPosts: 7 Employee
edited Apr 28, 2022 3:57AM in Infinity & Maxymiser


Most optimization platforms rely on a client-side approach by running JavaScript code directly in the end users' browser. The JavaScript is used to modify the end website in real time when a browser requests that website. The client-side approach has many benefits including the ability to support a WYSIWYG approach for marketers to create their optimization campaigns, and the ability to publish those campaigns to the website without requiring an internal code release.

The client-side approach, does however, have its own limitations. In the last few years we have seen an explosion of the use of single page applications frameworks, such as Angular and React, in web development. In general, websites and applications are becoming more complex and dynamic and this poses a problem to the JavaScript heavy client-side testing. As the optimization market matures, marketers and product development teams want to test backend features such as search algorithms and pricing strategies before they get released. These are only some of the reasons why we have seen a demand for running test and personalization campaigns server-side.

This article will introduce you to our Campaign Delivery API, explain the differences between the two optimization approaches, and give you examples of when you should use one or the other.

Client-side vs server-side optimization?

Client-side testing is done directly on the customer's browser, so it is best for testing user interface changes, like layouts and styling. Server-side testing is done directly on your company server and variants are rendered before they are returned to the browser.

Client side testing flow (3).png

Server side testing flow (4).png

An important difference between the two approaches is their operational model. While marketers can go live with client-side campaigns without an internal release, server-side tests are part of the site codebase so they would need to go through the same release process as other product features. Although campaigns are still created, configured and published in Maxymiser, the content of the variants and when it gets applied is part of the application codebase. This means that marketers will have to work with product development teams to prioritize, develop and release their optimization roadmaps.

When should you use server-side testing?

Client and server-side campaigns are not mutually exclusive and can be run on the same site at the same time. However, there are a few use cases where server-side is a better and sometimes, the only option:

  • Testing on non-browser devices – Server-side tests can be done on applications which run on a networked device without a browser; e.g. kiosks, gaming consoles, smart TVs, and set-top/cable boxes.
  • Testing functionality executed on the server and site redesigns – Sometimes you might want to test functionality which does not run on a browser. For example, you may want to A/B test a new search algorithm for related products or try out a new pricing engine rules. These run directly on the server, therefore cannot be tested client-side.
  • Single page applications – Some SPA frameworks, like React, make use of a virtual DOM and this makes the DOM manipulating client-side testing approach error prone. Also, such applications often use server-side rendering in order to improve performance of that initial page load. In such cases, server-side may be a better option for optimization as it executes in the source instead of returning and running active variant code on the page itself.
  • Improved performance and security concerns – Some companies have internally imposed limitations and are unable to use 3rd party JavaScript code on some of their pages. Our server-side testing solution offers a way to run campaigns without needing to include a JavaScript tag on the page.

Other benefits of server-side optimization

  • No flicker – Flicker is the short flash of the default content that the visitor may see before the DOM modification for the variant is completed. Our client-side solution is optimized to avoid flicker completely and we even have workarounds for asynchronous tag loads. With server-side testing, naturally, there is no flicker at all as the content is built before the page is loaded.
  • Minimal post-campaign activities – Since content for the campaigns is built and released as part of the application codebase, making the winning experience permanent is just a matter of a small code clean up task.
  • Testing and optimization as part of internal software delivery lifecycle – Companies have well established processes for development, quality assurance and production releases. Server-side optimization is embedded in those processes meaning that your campaigns go through the same quality assurance and release procedures as other product features. Internal releases would no longer affect optimization campaigns. There is no need to synchronize and ensure campaign content is not in conflict with the default content every time a production release is done.

Introducing Oracle Maxymiser’s Server-Side capabilities We are really excited to introduce Oracle Maxymiser’s Server-side API. It gives you programmatic access to the decision engine and action tracking functionality of our platform. Features of the API include:

  • Generations - Get experience decisions for customers and generate them into campaigns. Custom attributes for targeting and personalization are also supported.
  • Generation confirmations - Using generation confirmations gives you flexibility around decision retrieval usage and the ability to improve performance by getting experiences asynchronously.
  • Action tracking – You can track actions with their values and attributes server-side.
  • CORS support – We made sure you can use the API on the client side as well. This means that you have control over the same campaign from both the client and the server.
  • Improved performance – Server-to-server calls and the lack of active content in the responses mean improved performance for the campaigns.

Exposing this functionality in an HTTP API means you can use it from any networked platform and with the language of your codebase. You don’t need to know the internals of how bucketing or campaign statistics work. The solution uses the same stats engine as the client-side testing uses, so reporting and campaign monitoring do not change. Once a campaign or an update gets published it is instantly live; there is no need to synchronize campaign configuration on the server. The API endpoints are fully documented, together with usage examples and parameter descriptions. Server-side campaigns are created using the Oracle Maxymiser's REST API. Visit the documentation for the Campaign Delivery API and the REST API to get started.

What to learn more? Watch our latest !

Screen Shot 2017-11-20 at 10.52.45 AM.png

Post edited by OIT Integration User on