Demystifiying CNAMEs

11 Dec 2022 » MSA

If you have been involved in Adobe Experience Cloud implementations, at some point you probably have stumbled upon CNAMEs. If you have wondered what are these creatures and why they can be useful for your marketing goals, this post is for you.

DNS

Before I explain what a CNAME is, I need to explain the DNS functionality. DNS stands for Domain Name System.

Computers connected to the Internet can only work with IP addresses, something like 52.167.10.121. However, humans have a hard time remembering these cryptic numbers, as they carry no meaning. On the other hand, we are great with names and can easily remember them. So, for us, experienceleague.adobe.com makes a lot more sense and it is easier to remember.

When we give this server name to our browser, it does not know what to do with it, it first needs to convert it to an IP address. To do that, browsers will use a DNS server. Once the browser has the IP address corresponding to the domain, it will connect to the server using this IP address. In summary, a DNS is a technical solution to convert human-readable names to IP addresses.

$ host experienceleague.adobe.com
experienceleague.adobe.com has address 52.167.10.121

DNS servers can do more than just this direct conversion. They have been extended to support indirections. In other words, you can have a domain name that points to another domain name; this can also be referred to as an alias:

$ host metrics.adobe.com
metrics.adobe.com is an alias for ehg-adobe1p.hitbox.com.
ehg-adobe1p.hitbox.com has address 205.216.15.71

The interesting thing about CNAMEs is that, although the final domain name belongs to someone else, on the surface, you can make them look like you own them.

Cookies

Wait a minute: cookies again? I am afraid yes. I have written a few posts on cookies, so I will not get into the details again.

Let me start with the problems we are trying to solve:

  • Some browsers and browser extensions block or limit the usage of 3rd party cookies. These cookies are key for our digital marketing purposes.
  • You cannot read from or write to 3rd party cookies.

One interesting solution is the usage of CNAMEs. The idea is to convert some server names, under domains different from the website’s domain, into server names that look to be under the same domain as the website’s domain. With these changes, some 3rd party cookies become 1st party cookies, which solves the two issues above.

Website Other domain Cookie from otherdomain.com
www.mydomain.com mkt.otherdomain.com Stored under otherdomain.com
www.mydomain.com mkt.mydomain.com
CNAME to mkt.otherdomain.com 		Stored under mydomain.com

Some of you will remember how this was common with the s_vi cookie in Adobe Analytics. By default, s_code.js or AppMeasurement.js make calls to a domain that ends with 2o7.net or omtrdc.net. Therefore, the s_vi cookie is set under one of these domains. However, you can create a CNAME entry to point to the original Adobe Analytics domains, like metrics.adobe.com. The result is that the s_vi cooky is now under your domain (adobe.com in the example), effectively becoming a 1st party cookie.

Uses in the Adobe Experience Cloud

You will see various Adobe Experience Cloud tools using this technique:

  • Adobe Analytics. I have already explained the case of the s_vi cookie above, which has been in use since the days of Omniture SiteCatalyst: About first-party cookies.
  • Adobe Target. I have never seen it in use, but you can use CNAMEs to point to the Adobe Target delivery API: CNAME and Target.
  • Adobe Experience Cloud ID. The ID service can create a copy of the AMCV cookie, named s_ecid. The difference between these cookies is that the AMCV cookie is set client-side, in JavaScript, while the s_ecid is set server-side. This is a workaround for some early versions of ITP (more on it below), which gave more importance to server-side cookies vs client-side. In the documentation, you will see that this cookie is set for “CNAME customers only”.

Caveats

As we all know, Apple has embarked on a crusade against anything that smells like tracking and online advertising with the excuse of protecting the consumer’s privacy. They even have a fancy name for it: Intelligent Tracking Prevention or ITP. Unfortunately for us, they have the upper hand and all we can do is find cracks in their solution. CNAMEs were a workaround some time ago, to keep marketing cookies for longer. However, the current version of ITP also detects CNAMEs and treats cookies coming from CNAMEs as “dirty” and limits their lifespan. Still, using CNAMEs can help against other restrictions. You can see more here: https://experienceleague.adobe.com/docs/id-service/using/reference/analytics-reference/cname.html?lang=en.

The demdex cookie also requires special treatment. By design, this cookie must be a 3rd party cookie. For example, ID syncs only work if this condition is met. In other words, do not attempt to create a CNAME for this cookie.

 

Photo by Daniel Thomas on Unsplash

Related Posts