Integration: Client Side vs Server Side Integration
Overview
There are currently two different ways to integrate Algonomy products into your site; Client Side or Server Side. Both options have benefits and drawbacks.
Audience
This topic is intended to help Retailers who are implementing Algonomy on their websites understand the two implementation options, Server Side or Client Side. A thorough knowledge of the merchandiser's web site and business model is helpful.
Benefits
Understanding the way each of the two implementation methods works is important, no matter which product or products from the Algonomy lineup you are implementing.
Prerequisites
Retailers will want to work closely with their Algonomy team to get the most out of their implementation. While many features are self-service, taking advantage of the RR team and the training provided will help avoid hiccups in implementation.
How It Works
Algonomy ingests data from the retailer in various Feeds that it uses to recommend products, show content, or return in search/browse results for end users in placements on the retailer's website, using a complex mix of strategies, rules and an engine that continuously works to display the most relevant recommendations in real time.
When a shopper visits a site that uses a Algonomy product, the site sends information about the shopper and the site to the Personalization Cloud and receives personalized content in return. This call to the Personalization Cloud and the response can be made from the shopper’s browser (which we call a client-side request) or from the merchant’s server (a server-side request).
The RR data center and the RR back end communicate on a regular basis, bringing logs of user activity to the back end and updates to the runtime to the data centers. Each data center has an exact copy of the current runtime, so it doesn’t matter which data center is called from the browser.
More data comes to the RR back end from feeds (catalog updates, offline purchase data, etc.). The Personalization Cloud dashboard also configures the back end. Changes from these sources propagate to the data centers through regular updates. (For example, a catalog update that came in through the feed will affect the recommendations in the runtime.)
Client Side vs. Server Side
Client Side
In a Client Side implementation, the shopper visits the client’s web site and the merchant’s server delivers a page that includes JavaScript code or an API that calls the Algonomy server at one of our data centers. This call includes information about the user, which the Relevance Cloud uses to choose the best personalized information to show. The Algonomy server sends this information back (including recommendations, promotions, and sorted catalog data) to the shopper’s browser, either as HTML or JSON.
In a client-side setup, pages call the Algonomy server from the shopper’s browser, either through our JavaScript integration or a client-side API call:
Server Side
On the other hand, in a server-side setup, pages call the Algonomy server from the retailer's server:
The choice will depend on the things that the retailer prioritizes, including speed of the implementation, the use of cookies and speed of page loads. Retailers should work with their Algonomy team to help them make this decision.
Cookies
On client-side implementations, the Algonomy server creates cookies through the shopper’s browser to record the shopper’s views, purchases, recent search terms, and other information about the shopper’s behavior. With every call to the RR server, this information is read from the cookie and used to personalize the shopper’s experience.
To ensure that first party cookies are created you will want to create a new CNAME DNS record (e.g. recs.yoursitename.com) and point it to recs.richrelevance.com. This will ensure that any cookie created will be created as a first partly cookie.
Because cookies are features of the shopper’s browser, cookies aren’t inherently part of server-side implementations. The RR server can’t create cookies if it’s not in direct contact with a browser.
Cookie Proxy
In server-side setups, merchants can effectively give the RR server access to the browser’s cookies by acting as a cookie proxy (or cookie pass-through). When the RR server requests a cookie, the merchant’s server requests the cookie through the shopper’s browser. When the shopper’s browser requests a page from the merchant site, the merchant’s server reads the RR cookies and then passes this information to the RR server.
Vanity URLs
Cookies are domain-specific in a browser, so if the merchant website is called SuperStore.com, the cookies it creates will be available only to SuperStore.com. When recs.richrelevance.com creates cookies, those cookies are only available to richrelevance.com. By default, client-side calls to the RR server will not be able to see cookies created by the merchant server, and vice versa.
When these cookies are not shared between the two types of integrations, logging and reporting will be incorrect, and everything that the Relevance Cloud learns from user behavior can suffer as a result.
To share the cookies, you need to set up a subdomain on your site (like recs.SuperStore.com), a CNAME reference, and the Algonomy Vanity URLs feature. The Algonomy cookies will be created under your site’s domain, and they can be accessed from your server-side as well as your client-side implementations. See Vanity URLs.