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