Overview

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 (or in-app) 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. It is applied with help of the Oracle Maxymiser tag and is out-of-the-scope for this documentation.

Server-side testing is run on your company server. Variants are rendered before they are returned to the browser. Eventual experience is chosen on behalf of the Campaign Delivery API.

 

 

 

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 to use the Campaign Delivery API

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 Campaign Delivery API

We are really excited to introduce Oracle Maxymiser's Campaign Delivery 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.