CNAME vs. First-Party ID: Which is more beneficial with AEP WebSDK?

[DhanA2]

If I’m using AEP WebSDK, which I believe covers the use of a first-party ID, what are the benefits of using CNAME in addition?

Is there an advantage to CNAME over just using a first-party ID?

How does CNAME help in comparison, and should this prompt a move to AEP WebSDK across all our websites?

ccing: top contributors for quick response @Jennifer_Dungan  

Thanks for the wonderful support!

[Jennifer_Dungan]

To be honest, we haven't moved to WebSDK yet.... The biggest advantages there is if you are planning on using CJA... and I think it can use server cookies (and not just client cookies)

I believe you are correct that when you set up WebSDK it only uses first party cookies, but I believe that is because it must be set up with a CNAME... I believe this is actually mandatory...

It's not so much a choice between CNAME or WebSDK... I think it's more using a CNAME record for "traditional" tracking, vs WebSDK (which has to be set up with a CNAME).

CNAME is really just a DNS record that ensures the tracking endpoint uses your domain so that it can set first party cookies.... Basically Adobe is given an authority to use a subdomain of your domain and to set cookies against that domain.

[bjoern__koth · Accepted solution]

Hi @DhanA2 

you actually don't need the CNAME to work with the WebSDK. Traditionally, the CNAME has been recommended to write cookies in a first-party context, since the Adobe calls return server-side cookies in the response, and having these sent through your own subdomain lead/led to longer allowed cookie lifetimes.

These days, browsers are more and more limiting cookie lifetimes, and especially Safari identifies the requests through CNAMEs as third-party context, since they know that the receiving end behind that subdomain is actually an Adobe server. Hence, your cookie lifetime is cut down drastically.

So, even with a CNAME-cloaked server-side cookie, Adobe can only identify the users for as long as browsers permit. Note that the ITP (intelligent tracking prevention) is a Safari-only feature right now, but I would expect more and more browsers coming up with similar features in the future.

This is where FPID comes into play.
Since you have to set up your own service/servlet that returns a server-side cookie from your very own domain, no browser can actually  limit the lifetime of your own cookies.
worth mentioning that server-side cookie lifetimes are also longer than using JavaScript and document.cookie

So, my recommendation is: use both. A dedicated CNAME does not hurt and theoretically also hides the requests from some ad blockers (not sure if any ad blocker still does not detect these nowadays though)

also worth mentioning that the FPID cookie should already be present in your first AEP call, means it should be executed synchronously. If not, Adobe will primarily use its own cookies until they expire and only then switch over to your own FPID cookie.

hope that helps 

[AsishPa1]

My understanding is First party cookies (FPID set by company's own server) can only be read by a CNAMED domain. So, for Adobe Web SDK FPID solution to work we should CNAME the adobe data collection domain. Does that Make sense?

Here is the extract from the Adobe documentation on implementing FPID Use first-party device IDs in Web SDK | Adobe Data Collection

Using first-party device IDs (FPIDs)

First-party device IDs (FPIDs) track visitors by using first-party cookies. First-party cookies are most effective when they are set using a server that uses a DNS A record (for IPv4) or AAAA record (for IPv6), as opposed to a DNS CNAME or JavaScript code.

IMPORTANT

A or AAAA records are only supported for setting and tracking cookies. The primary method for data collection is through a DNS CNAME. FPIDs are set using an A or AAAA record and sent to Adobe using a CNAME.

The Adobe-Managed Certificate Program is also supported for first-party data collection.

Once an FPID cookie is set, its value can be fetched and sent to Adobe as event data is collected. Collected FPIDs are used to generate ECIDs, which are the primary identifiers in Adobe Experience Cloud applications.

You can use FPIDs in two ways:

• Method 1: Configure a CNAME for your Web SDK calls and include the name of your FPID cookie in your datastream configuration.
• Method 2: Include the FPID in the identity map. See the section further down in this document on using FPIDs in identityMap for more information.

[bjoern__koth]

Hi @AsishPa1 

correct, if you do not have a CNAME set up for your tracking server, you will need to explicitly provide the FPID in the identityMap since the cookie headers won't include the first-party cookie.

In other words, make sure to - and this is not 100% obvious in Adobe's code examples - not set the httpOnly header in your script response.

This will give you more flexibility to 

1. actually read out the value of the cookie 

2. not make unnecessary requests to the servers if you already have an FPID cookie present.

Keeping the httpOnly header in the response will essentially hide the server-side cookie from your browser's JavaScript