Skip to main content
RichRelevance

Cookies and Tracking User Activity

Cookies

On client-side implementations, the RichRelevance 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.

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 RichRelevance Vanity URLs feature. The RichRelevance 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.