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 happen to be exposed to their existing and potential contacts.
Aside from aesthetic benefits, there are other advantages to using vanity domains such as making sure the JS listener is functioning properly. Two examples that our clients may want to know about:
- Third-party cookie access is being blocked by major web browsers, which means the JS listener will be blind without the ability to read and send contact activities happening on the client’s website unless vanity domains are used to create first-party cookies on the client’s domain.
- Site events such as browse, cart, and page_view are safer when queued and stored under the client’s domain, where the client has control over their servers and data. If these were stored under Cordial’s domain, they could be lost in the event of data hangups on Cordial’s servers.
First-party cookies | Third-party cookies | |
---|---|---|
Created and "owned" by | The website or host domain you are visiting such as 360training.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 offend website visitors especially since being served by the very 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 if that happens to be the intent. While cookies created by cordial.io are perfectly benign, they are still considered third-party for being hosted under our domain but recording data about contacts visiting the client’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.
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. |
Creating Vanity Domains
Three vanity domains (technically subdomains) need to be created for each client. These can be created by our team if the client has already delegated a subdomain to Cordial, or can be created by the client, which requires that the client CNAME all three to cname.cordial.com
.
Domain delegation
Client delegates one of their 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.
Example:
360training delegates the subdomain email.360training.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 client’s involvement. This is the preferred way of handling vanity subdomains.
CNAME records
This is the practice of mapping or aliasing one domain name to another, and the client retains full authority over the domains. The process is the same as with delegated subdomains but the lift is heavier for the client. Cordial does not have the ability to add, remove and update subdomains so all requests to do so must go through the client. Just as with delegated subdomains, Cordial must create SSL certificates for CNAME subdomains before they can be used.
Example:
360training decides to CNAME instead of delegate. The client 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 the client 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 the client, 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 setup. This subdomain is not used in the JS listener v2 or v1 installation snippets but the base {domain}
must match the client’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.
e.
, d.
and se.
, the client 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:
The client 360training delegates the email.360training.com
subdomain to Cordial. This happens to be their sending subdomain. Most clients will 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, 360training.com
in this case. Cordial creates the following vanity subdomains:
e.email.360training.com
d.email.360training.com
se.email.360training.com
Outlier example:
The client Discount Dance delegated the e.discountdancesupply.com
subdomain to Cordial. This happens to be their sending subdomain. However, their base website domain is discountdance.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, discountdance.com
in this case, and not necessarily the sending subdomain. This means Discount Dance has to delegate or CNAME a different subdomain that is tied to their website such as e.discountdance.com
. let’s say Discount Dance now delegates e.discountdance.com
. Cordial creates the following vanity subdomains:
e.e.discountdance.com
d.e.discountdance.com
se.e.discountdance.com
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
.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.360training.com/track.v2.js', 'crdl'); crdl('connect', '360-training', { trackUrl: "//se.email.360training.com" , connectUrl: "//d.email.360training.com" , cookieDomain: "360training.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.discountdance.com/track.v2.js', 'crdl'); crdl('connect', 'discountdance', { trackUrl: "//se.e.discountdance.com" , connectUrl: "//d.e.discountdance.com" , cookieDomain: "discountdance.com", cookieLife: 365 }); </script>
How to 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 from clients who are creating CNAME records and when requesting vanity subdomains from eng. for clients who delegated. This will save us the effort of creating piecemeal requests when clients are ready to move to JS v2.
When the client has already delegated a subdomain to Cordial:
- Open a Jira ticket with Jay Schellenberg (or another designee) requesting the necessary vanity subdomains. Include the delegated subdomain such as
email.360training.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. - Ticket example: https://cordial.atlassian.net/browse/CP-4831
When the client has created vanity subdomains on their own and has created CNAME redirects to cname.cordial.com
for each:
- Open a Jira ticket with Jay Schellenberg (or another designee) requesting SSL certificates for the vanity subdomains in question.
Coordinating 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 (client does this on their end) and an update on the back-end to MySQL records (Cordial does this on our end). CE will coordinate with the client and Brian Lange (or another designee) to make the switch at a mutually convenient time.
Comments
0 comments
Please sign in to leave a comment.