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