Server-side testing and personalization explained

This blog is part two of a multi-part analysis on the different technical approaches to A/B testing and personalization. In part one, we explored the most important technical considerations when implementing client-side testing and personalization. In this post, we will now explore the possibilities of server-side rendering via API.

How server-side testing and personalization works

While traditional client-side implementations call personalization services from the browser via Javascript, server-side integration enables organizations to call the personalization service before the page is rendered, from within their proprietary technology stack.

So, what is server-side rendering?

Server-side testing and personalization is typically provided by the vendor in the form of a REST API, which is called from the rendering web application (server) before the page is served. Requests and responses to REST APIs use the JSON format for data, a widely adopted and efficient way of representing data.

In pure server-side integration, your server securely interacts with an API Gateway, passing the details of the page request and asking for relevant personalization experiences.

The response is typically a JSON payload. It is then the caller’s responsibility to parse the response and act on it. You will also need to report back any engagement with the chosen experiences or significant user events. Engagement and events are reported in a similar manner (POST to and API endpoint) to personalization.

Because server-side personalization occurs within your web application stack on the back end, successful implementation requires thoughtful design and development by your tech team.

Server-side rendering use case examples:

• Major structural changes to the page
• Full-page redirects
• Secure access to back end systems (pricing models, real-time inventory)
• Pre-render personalization of Single Page Apps

The move to server-side APIs

As the web evolves, more organizations are making the switch from client-side A/B testing and personalization to server-side APIs, for reasons including:

1) Page load performance (eliminating flicker): In client-side rendering, personalization is applied after the page renders, so care must be taken to avoid visible “flicker” when DOM elements are re-rendered.

2) Data security (not exposing sensitive data in the browser): You may want to test or personalize based on proprietary customer information without exposing it in the browser.

3) Integration with proprietary technology stacks: Performing personalization server-side opens the door for direct integration with internal systems such as inventory and CMS.

4) Mitigating browser restrictions such as ITP and ad blockers: Server rendering allows relevant user data for A/B testing or personalization to be persisted in the form of first-party, server-side cookies – that is, cookies written via HTTP headers from the web server, as opposed to cookies or local storage written by Javascript code.

5) Centralized IT control of site structure and modifications: Many organizations prefer to keep control of page structure and content in the hands of their IT department.

6) Implementations beyond the web (in-store kiosks, mobile apps, etc): The simplicity of the API model means that testing and personalization can be performed on any platform that has access to the Internet.

Providing Context

Making personalization and targeting decisions requires context about the user, such as where they are, what browser they are using, and what type of device they are on.

In client-side personalization, a lot of this useful contextual data for personalization can be derived from the default HTTP headers which accompany every request to the server. In server-side implementations, however, this header data is usually not available when the rendering application calls the personalization server and must be provided in the body of the personalization request.

As long as enough data is passed through the request to the personalization API, the same context can be provided as in client-side implementations.

Server- and client-side hybrids offer options and flexibility

The simplicity of the API concept means that you don’t necessarily have to make an either/or choice between server and client rendering for personalization. Some modern personalization platforms provide the ability to implement a hybrid solution, in which pre-rendered server-side testing and personalization changes can coexist with traditional client-side testing.

An organization may choose, for example, to have their IT department handle tests that affect the structure of a page on the server-side, while still allowing marketers to make simple changes such as image swaps and time-sensitive banner notifications.

This hybrid approach is also convenient for reporting engagement to the personalization engine, as client-side reporting via Javascript is asynchronous and does not affect page performance, avoiding extra pass-through calls to your organization’s web server.

Considerations for moving to server-side

Server-side integration benefits come at a cost as a higher degree of technical investment on the part of your organization. Thus, it is important to have sufficient technical resources committed to any server-side project.

The design of the serving application should take testing and personalization into consideration so that any content which might be personalized can be modified as the result of an API call without further code changes. Taking personalization into consideration throughout the design process will result in a scalable architecture and much less work down the road.

Equally important to successful server-side implementation is the choice of a personalization platform. Make sure to choose a vendor that offers a robust solution, extensive documentation, and will work with you throughout the implementation process.

In the end, server-side integration for testing and personalization requires more work upfront and can take longer than client-side solutions, but more and more organizations are finding the benefits worth the effort.

ICYMI, Dynamic Yield is offering a free 14-day exPerience APIs trial. Simply sign-up for access to a sandbox environment and start playing. 

Next up: client-side vs server-side

Based on our experience working with clients over the past 8 years, these are the most important technical aspects to consider for server-side testing and personalization. In the next part of this blog series, we will compare client-side vs server-side rendering against one another.