Taking the Lead in Delivering Next-Gen Personalization

Client-side, server-side, or hybrid—learn all about these Adobe Target optimization and personalization approaches. Find how going hybrid can help you experiment and go beyond your typical marketing use cases to deliver relevant, cross-channel experiences across channels—every time.

Personalization is the driving force behind successful customer experiences. And Adobe Target is the force behind that personalization.

For customers who want to implement Adobe Target for optimization of their web content, the most common dilemma is whether to adopt a client-side or server-side implementation approach. There certainly is no best answer here. Both approaches have advantages and considerations.

This article will help you understand the difference between both approaches and decide if hybrid implementation is the right choice for you.

Client-side Personalization

Client side is easy to implement, especially for traditional websites. We simply drop a JavaScript library in the head of HTML document with default settings and that may be just enough for a quick out-of-the-box implementation. This automatically enables Adobe for Analytics (A4T), if you leverage it on your website. Furthermore, the Visual Experience Composer (VEC) will let your optimization team members easily set up a Target activity without the need to involve a developer.

Sounds like the way to go? But wait, there is more to it.

Figure 1: A request to Target is sent from the browser. Target server communicates with other Experience Cloud solutions and sends an optimized response back to the visitor’s browser to be applied.

Your web architecture might be more advanced than a simple web page where you want to optimize text, images, or other visual elements. The technological advances have taken us to the era of single page applications (SPAs), progressive web applications (PWAs), and others, to improve user experiences and performance. This dictates new rules for applying any third-party integrations on both front end and back end. This article guides you on the best practices for implementing Adobe Target in a Single Page Application.

Server-side personalization

Outside of SPAs, some personalization use cases may work best with the server-side approach. Consider your web architecture pulls content from your content management system ( CMS) on the server level, you may need Adobe Target call to qualify visitor for an experience to decide what content needs to be pulled from your CMS.

Figure 2: Visitor requests the page from your web server. Web server sends an API request to Target. Target server communicates with other Experience Cloud solutions and sends an optimized response back to the web server. Web server processes Target response and sends an optimized HTML back to visitor’s browser.

Server-side implementation may address the above use cases well. In addition, it comes with advantages such as faster performance. This is because server-to-server communication requires no dependency on user’s Internet speed or flicker-less content update because server already prepares an alternate experience before the page compiles. At the same time, server-side implementation involves a more technical approach. It requires a one-time setup for an SDK and possible maintenance to address various use cases.

Another consideration for using Target server-side approach is the **SDK **availability. Today, Adobe has a NodeJS SDK fully available for use and Java SDK has been launched this year. If you are an API fan, you should still know that direct API calls can keep you up and running if Adobe Target is the only Experience Cloud solution that you use. But SDK does a lot more than we can imagine—it comes with an integrated Experience Cloud ID (ECID) Service for seamless integration with client-side Adobe Analytics (AppMeasurement.js) and Adobe Target (AT.js). SDK manages cookies and other internal logic for Adobe cross-solution functionality that we do not have to worry about.

One more consideration is the new visitor targeting with server-side implementation. Since ECID Service initializes an ID (a.k.a. Marketing Cloud ID, Visitor ID or, simply, ECID) on the client side, the very first Target call on your web server will not contain ECID, which is the main cross-solution identifier. As a result, new visitors will be unknown to Analytics and Adobe Audience Manager if you want to utilize segments from these solutions in your Target activities.

Once you are clear about new visitors and about how to install and run SDK on the web server and handle development work for all use cases, you are clearly ready to optimize the content with performant flicker-less server-side integration. And if you have come this far, you are ready to dive into the advantages of hybrid implementation.

Hybrid personalization

Hybrid testing mode involves working together of both server-side and client-side approaches. This does not necessarily refer to Target requests only. It can be your web server making the first Target call and Analytics, on the client-side, picking up some useful information for A4T reports. But using Target on both server and client side where possible, may, in fact, open doors to possibilities of handling varied use cases that your organization may require.

So, what are the key concepts when implementing a hybrid implementation? Once you are settled with your choice of SDK, follow the instructions provided in the SDK documentation correctly:

1. Pass ECID and Target cookies into Target request and response
2. Pass a generated Server State payload to client side
3. Apply personalized content from Target to the page
4. Initialize a client-side ECID Service with generated Server State payload
5. Ensure Target library at.js global setting for _overrideMboxEdgeServer_is set to true. This allows at.js to use the same visitor information as on server side to ensure it is a single visitor.

The steps above describe a successful hybrid implementation. Analytics calls will pick up the required information (Supplemental Data ID a.k.a. SDID) about the visitor to sync with A4T reports, so your Target activities can be further analyzed in Analytics. However, for this step, we also need to validate that all three libraries are loaded in the following order: ECID Service, Target, and Analytics.

See this code example showing ECID, Target, and Analytics integration.

Lastly, there is one pleasant surprise for hybrid implementation fans, if you have already become one while reading this article. This month, the new SDKs will support the delivery of VEC activities through the server side. This is a ground-breaking feature that makes a hybrid approach unique and strong. Mainly because, up until today, only client-side integration allowed optimization teams to use a VEC – one of the favorite features on the market. Server-side integration meant no VEC. But starting now, all VEC activities can be retrieved via a single server-side call, passed onto the client side via a Server State payload.

What we gain here is huge. No more initial Target call on the first page load. This means the change to alternate personalized experience occurs immediately as the page loads. This also means, there is no content pre-hiding needed and no flicker. The new feature will make many of us on the business and technology side happy as it improves the page performance and user experience.

Figure 3: Visitor requests the page from your web server, web server sends an API request to Target, Target server communicates with other Experience Cloud solutions and sends an optimized response back to the web server, including VEC activities. Web server processes Target response and sends an optimized HTML back to visitor’s browser, Target JavaScript library picks up and applies VEC activities to page without making additional client-side call.

Is hybrid the right approach for you now that you are fully equipped with all the necessary knowledge? Happy testing to you everywhere – whether it is server side, client side, or both.