Skip to main content

Vanity URLs

When product recommendations appear on the page, they will link to If this is not desired, we can use vanity URLs, which let the links point to a subdomain of the customer, so as to avoid any confusion on the shopper’s part about where the link takes him/her.

Why Use Them

  • Sites whose users 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.

How It Works

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 and a CNAME record on your servers, matching the name you gave to the RichRelevance team.

The CNAME record tells DNS that any calls to should go to wherever DNS tells you is: in essence it is just an alias or “also known as.” It does NOT replace the server name, merely how DNS is used.

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 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.

What’s Not Supported

  • Secure (SSL) calls cannot use vanity URLs.

    Why? If shoppers connect to HTTPS and use they will get a security alert that the certificate does not match ( is not

    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 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 Calls for recommendations will always go to