When product recommendations appear on the page, they will link to recs.richrelevance.com. If this is not desired, we can use vanity URLs, which let the links point to a subdomain on the customer's site, to avoid any confusion on the shopper’s part about where the link takes him/her.
This topic is intended to help Retailers who are implementing RichRelevence on their websites understand how to use Vanity URLs, if desired. A thorough knowledge of the merchandiser's web site and business model is helpful.
What are the benefits of this feature?
Using a vanity URL can circumvent any confusion on the shopper's part when they click on a recommendation.
What are the drawbacks of this feature?
Retailers will need to set up the subdomain in order for recommendations to be set up.
How It Works
The CNAME record tells DNS that any calls to recs.clientsitename.com should go to wherever DNS tells you recs.richrelevance.com is: in essence it is just an alias or "also known as." It does NOT replace the server name, merely how DNS is used.
Talk to your RichRelevance team about vanity URLs and let them know the exact subdomain you plan to use.
Set up a subdomain on your site: recs.yoursitename.com
Set up a CNAME record on your servers so that your subdomain (recs.yoursitename.com) is a CNAME for recs.richrelevance.com.
Ask your RichRelevance team to set up a vanity server for your site, matching the value you set in the CNAME record.
The click-through URLs that we return in recommendations will be a different domain (the customer’s domain that they configure to be a CNAME for recs.richrelevance.com). Since we construct the click-through links, we can always send the customer to an unencrypted, plain HTTP page, thus avoiding the SSL problem. Since recommendations send customers to product pages, there shouldn’t be an expectation of the page being secure.
- Sites that don’t allow third-party cookies may want to use vanity URLs so that the RR cookies can be written as first-party cookies.
- Sites that use a mixture of server-side and client-side integration will be able to see cookies used for both sides.
- Some clients are interested in vanity URLs for aesthetic reasons. They want the links inside recs to point to their own domain.
What’s Not Supported
Secure (SSL) calls cannot use vanity URLs.
Why? If shoppers connect to HTTPS and use recs.clientsitename.com they will get a security alert that the certificate does not match (recs.richrelevance.com is not recs.clientsitename.com):
The shopper would have to confirm to continue, and their shopping experience has been completely derailed. There is no work around for this, as we can not serve their certificate. This is a limitation of HTTPS, not RichRelevance.
Which sites use HTTPS? Many merchants serve all pages via HTTPS after shoppers log in or purchase anything. HTTPS is pretty common: on sites with a secure entrance like hdsupply, CDW-G, or even Target, once you login as a known customer, most if not all of the remaining session is HTTPS.
- Vanity URLs are not supported for media.richrelevance.com. This would prevent p13n.js from being able to be loaded on the purchase complete page (and likely the cart page as well), and we would be unable to track that data (purchase, products added to cart, etc). We need purchase complete and cart page data to be able to make decent recs.
- Vanity URLs cannot be tested in the integration environment.
- The feature does not use the client’s site name everywhere instead of recs.richrelevance.com. Calls for recommendations will always go to recs.richrelevance.com.