How can we help?

✪ Vanity domains for JavaScript Listener

Overview

Vanity domains are typically used to hide lengthy or off-brand URLs, which are unsightly and difficult to remember. Brands use vanity domains to ensure consistent branding anywhere the URLs appear to existing or potential contacts.

Aside from aesthetic benefits, there are other advantages to using vanity domains, such as making sure the JavaScript Listener is functioning properly. Here are two examples:

  • Third-party cookie access is being blocked by major web browsers, which means the JS Listener won't have the ability to read and send contact activities happening on your website unless vanity domains are used to create first-party cookies on your domain.
  • Site events such as browse, cart, and page_view are safer when queued and stored under your company's domain, where you have control over the servers and data. If these were stored under Cordial’s domain, they could be lost in the event of data hangups on our servers.
  First-party cookies Third-party cookies
Created and "owned" by The website or host domain you are visiting such as threads.com (same-site domain). A website or domain other than the one you are visiting, such as cordial.io (third-party domain).

First-party cookies are less likely to upset website visitors, since they're served by a website they intentionally visited. Third-party cookies have a bad reputation because they can be used to track visitors as they move across different websites, serve them all kinds of content, and even open them up to security vulnerabilities. While cookies created by cordial.io are perfectly benign, they're still considered third-party for being hosted under our domain but recording data about contacts visiting your company's domain.

Google Chrome and third-party cookies

Chrome is shifting to a secure-by-default model for cookies in an effort to improve privacy and security across the web. Chrome will achieve this after the mid-February v80 update when third-party cookies will become inaccessible by default unless the permission to do so is explicitly granted within the cookie settings.

Developers can use the SameSite cookie parameter to enable or disable third-party cookie access. The Cordial Dev team has made appropriate updates to the JS Listener (v1 & v2) and other Cordial services to ensure appropriate settings are applied to cookies our platform relies on.

It's in your best interest to use vanity subdomains even with the SameSite parameter set to allow third-party cookie access. This is because third-party cookies will continue to be under scrutiny and can be blocked by other software such as ad blockers.

  Pre Chrome v80 Post Chrome v80
SameSite is not defined at all No enforced standard. First and third-party cookies are accessible. Chrome will treat cookies without a defined SameSite parameter as being SameSite=Lax. This will limit third-party cookie access and blind the JS Listener without vanity domains.
SameSite=None
(Secure access enabled)
Did not exist. Must be explicitly defined by the Cordial Dev team within cookie settings to allow third-party cookie access (same site domain and third-party domain)
SameSite=Strict Only first-party cookies are accessible (same site domain). Only first-party cookies are accessible (same site domain).
SameSite=Lax Only first-party cookies are accessible with a few conditional exceptions. But for our purposes, this setting would blind the JS Listener without vanity domains. Only first-party cookies are accessible with a few conditional exceptions. But for our purposes, this setting would blind the JS Listener without vanity domains.

Create vanity domains

Three vanity domains (technically subdomains) need to be created for you. These can be created by our team if you have already delegated a subdomain to Cordial, or can be created by your team, which requires that you CNAME all three to cname.cordial.com.

Domain delegation

You delegate one of your subdomains to Cordial-owned name servers (NS). This means that, in a way, the ownership of the subdomain is shared with Cordial, giving us the ability to create additional subdomains off of the delegated one and point them in the right direction. We also create SSL (Secure Sockets Layer) certificates for each subdomain.

Use case

A company called Threads delegates the subdomain email.threads.com to Cordial by pointing it to these NS records: ns1.crdl.io, ns2.crdl.io, ns3.crdl.io, and ns4.crdl.io. Multiple NS records are used so there are backups in case the primary NS is inaccessible or overloaded. When this is completed, Cordial gains the ability to create the three vanity subdomains without Threads' involvement. This is the preferred way of handling vanity subdomains.

If unwilling or unable to delegate, we ask that you create and CNAME the three required subdomains.

CNAME records

This is the practice of mapping or aliasing one domain name to another—and you retain full authority over the domains. The process is the same as with delegated subdomains but the lift is heavier for your team. Cordial does not have the ability to add, remove, and update subdomains, so all requests to do so must go through your team. Just as with delegated subdomains, Cordial must create SSL certificates for CNAME subdomains before they can be used.

Use case

Threads decides to CNAME instead of delegate. Threads would need to create the three vanity subdomains on their own and CNAME each to cname.cordial.com. Mapping NS records to a CNAME can take 24-48 hours. It is important that Threads not make subsequent changes to CNAMED records during this time period as doing so could prolong the resolution time beyond 48 hours.

Naming convention

We are standardizing the naming convention for the three vanity subdomains for easier troubleshooting and to maintain consistency. Whether vanity subdomains are created by Cordial or your team, we ask that the following naming convention be used:

  • e.{subdomain}.{domain}.com
  • d.{subdomain}.{domain}.com
  • se.{subdomain}.{domain}.com

e. (email)

This subdomain will be used to track revenue attribution and message events such as clicks, opens, and bounces. (Existing clients may already have this set up.) This subdomain is not used in the JS Listener v2 or v1 installation snippets, but the base {domain} must match your company's website domain used by d. and se. in the JS installation snippet.

d. (data)

This subdomain links to the track.js file.

se. (site events)

This subdomain is for website events such as browse, page_view, cart, and so on.

You can request that we use a different naming convention. This is fine as long as we note which subdomain is used for which purpose. So instead of using e.d. and se., your team could hypothetically use clicks., track. and events..

Vanity domain examples

Here are two practical examples of how vanity subdomains should be set up.

Typical example

A fake company called Threads delegates the email.threads.com subdomain to Cordial. This happens to be their sending subdomain. Most clients delegate their sending subdomain, but not always. The important detail is that the subdomain must be derived from their base website domain where JS Listener is loaded, threads.com in this case. Cordial creates the following vanity subdomains:

  • e.email.threads.com
  • d.email.threads.com
  • se.email.threads.com

Outlier example

A fake company called Electric Shoes delegated the e.electricshoes.com subdomain to Cordial. This happens to be their sending subdomain. However, their base website domain is electricshoes.com (without supply). In order for revenue attribution to work correctly, we have to ensure that vanity subdomains are using the website base domain where JS Listener is loaded— electricshoes.com in this case—and not necessarily the sending subdomain. This means Electric Shoes has to delegate or CNAME a different subdomain that is tied to their website such as e.electricshoes.com. Let’s say Electric Shoes now delegates e.electricshoes.com. Cordial then creates the following vanity subdomains:

  • e.e.electricshoes.com
  • d.e.electricshoes.com
  • se.e.electricshoes.com

The examples above use the email.clientsite.com and e.clientsite.com subdomain naming convention. However, the subdomains can be anything such as bespoke.clientsite.com or zebra.clientsite.com.

Multiple vanity domain support

When building an email message, you can choose from any of the vanity domains in your account, enabling you to match it to the domain of the website being used when sending a message with link tracking enabled.

Messages will continue to store the appropriate cookies on the end user’s web browser, and the attribution of events and orders will be routed to the correct email message. SREs can add, edit, and remove vanity domains in Cordial accounts.

This enhancement is designed to support global clients with multiple domains for the same brand. For example, the fake brand Threads could have http://www.threads.com, http://www.threads.co.uk, http://www.threads.fr, and http://www.threads.mx.

Multiple vanity domains are not intended to be used for unique brands or properties under a larger brand. For example, Gap has sub-brands like Athleta, Banana Republic, and Old Navy, each of which use their own domains and vanity domains. In other words, you wouldn’t use Old Navy as a vanity domain under Gap.

While you can manage multiple vanity domains in a single account, you can only use one vanity domain per email message.

JS v2 installation script examples

Only d. and se. vanity subdomains are plugged into the base JS v2 install snippet, and only d. is plugged into the base JS v1 install snippet. The e. vanity subdomain is set up on the back-end.

Default JS v2 install script

Practical examples

  • <script>
    (function(C,O,R,D,I,A,L){
      C.CordialObject=I,C[I]=C[I]||function(){(C[I].q=C[I].q||[]).push(arguments)};
      C[I].l=1*new Date,C[I].q=[],A=O.createElement(R);
      L=O.getElementsByTagName(R)[0],A.async=1,A.src=D,L.parentNode.insertBefore(A,L);
    })(window, document, 'script', '//d.email.threads.com/track.v2.js', 'crdl');
    crdl('connect', 'threads', { 
        trackUrl: "//se.email.threads.com" ,
        connectUrl: "//d.email.threads.com" ,
        cookieDomain: "email.threads.com",
        cookieLife: 365
    });
    </script>
    
  • <script>
    (function(C,O,R,D,I,A,L){
      C.CordialObject=I,C[I]=C[I]||function(){(C[I].q=C[I].q||[]).push(arguments)};
      C[I].l=1*new Date,C[I].q=[],A=O.createElement(R);
      L=O.getElementsByTagName(R)[0],A.async=1,A.src=D,L.parentNode.insertBefore(A,L);
    })(window, document, 'script', '//d.e.electricshoes.com/track.v2.js', 'crdl');
    crdl('connect', 'electric-shoes', { 
        trackUrl: "//se.e.electricshoes.com" ,
        connectUrl: "//d.e.electricshoes.com" ,
        cookieDomain: "e.electricshoes.com",
        cookieLife: 365
    });
    </script>
    

Request vanity domains

Although JS v1 only requires the d. vanity subdomain, please request all three at the same time. Use this practice when requesting vanity subdomains if you're creating CNAME records and when requesting vanity subdomains from eng. if you delegated.

If you have already delegated a subdomain to Cordial:

  • Open a Jira ticket requesting the necessary vanity subdomains. Include the delegated subdomain, such as email.Threads.com, the account #/name/key, and list the vanity subdomains to be created. If one of the vanity subdomains already exists, please note this in the ticket.

If you have created vanity subdomains on your own and have created CNAME redirects to cname.cordial.com for each:

  • Open a Jira ticket requesting SSL certificates for the vanity subdomains in question.

Coordinate the switch to vanity domains

This primarily applies to existing clients who are currently using JS v1 or v2 without vanity subdomains and are now ready to start using them. Updating an existing JS installation to vanity subdomains requires an update to the JS installation snippet (you do this on your end) and an update on the back-end to MySQL records (Cordial does this on our end). CE will coordinate with you to make the switch at a mutually convenient time.

Both updates have to be completed at the same time. You should not update the JS installation snippet ahead of time.

Comments

0 comments

Please sign in to leave a comment.