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 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 your 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 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 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 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.
It's in the clients’ 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 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.
Use case
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
, andns4.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.
You may encounter a client who is unwilling or unable to delegate. When this is the case, we ask the client to create and CNAME the three required 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.
Use case
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 set up. 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.
The client 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.
, 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
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, clients can choose from any of the vanity domains in their account, enabling them 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, a brand like Nike could have http://www.nike.com, http://www.nike.co.uk, http://www.nike.fr, and http://www.nike.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.360training.com/track.v2.js', 'crdl'); crdl('connect', '360-training', { trackUrl: "//se.email.360training.com" , connectUrl: "//d.email.360training.com" , cookieDomain: "email.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: "e.discountdance.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 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 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 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 (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 you to make the switch at a mutually convenient time.
Both updates have to be completed at the same. Clients should not update the JS installation snippet ahead of time. Doing so without an update to MySQL records on Cordial’s side would result in revenue attribution and event data loss.
Comments
0 comments
Please sign in to leave a comment.