Pre-requisites for First-Party Device ID (FPID) WebSDK | Community
Skip to main content
abhinavpuri
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
June 17, 2024
Question

Pre-requisites for First-Party Device ID (FPID) WebSDK

  • June 17, 2024
  • 1 reply
  • 1136 views

Hello Everyone - 

 

I'm working on POC for FPID implementation and had few questions with respect to documentation - 


I understand the FPID will not work with third-party party cookies (Used for cross-site visitor identification) but my query is is it possible to implement FPID without CNAME (first-party-cookies) implementation?

Technically, Want to check if FPID works with first-party (AMCV / kndctr_) WebSDK cookies set via edge.adobedc.net or they need to be set via host CNAME only?

 

We understand the CNAME is recommended approach also enables overcome browser restrictions with respect to FP cookies but for this POC we need to cross-check FPID working process. 

 

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.

1 reply

bjoern__koth
Community Advisor and Adobe Champion
Community Advisor and Adobe Champion
June 17, 2024

Hi @abhinavpuri 

two things to not mix up. I would implement a hybrid of the classic CNAME + the new FPID servlet and server-side cookies.

 

1. CNAME

CNAME is used to create a first-party cookie context in your WebSDK calls (or previously for analytics calls), to create server-side cookies.
In other words, the Adobe servers would return a server-side cookie with your user identifier that was is intended to last longer than a client-side (document.cookie="foo=bar") cookie.
You simply create a CNAME on your domain and forward the request to the Adobe servers / IPs (with Adobe support).

This is also called "request cloaking" and can potentially also help to hide some requests from ad blockers.

So much the theory.

 

Nowadays, browsers, especially Safari are smart enough to detect that the endpoint where your requests is forwarded to, is not yours but Adobe's (shame on you).

Hence, your cookie is still a first-party cookie, but they will limit the lifetime from (I think) up to 2 years to just 7 days.

 

2 FPID

The idea of the FPID is that your webserver creates an UUIDv4-style identifier for your user that will then be used from Adobe instead of their own identifier.

So basically, your webserver will host a servlet, that creates that UUID and returns it as a server-side cookie.

 

From there on, you can configure your data stream to look for that very cookie identifier that your webserver has returned.

 

 

Alternatively, you can also pass this value into the XDM identityMap. If you have a server-side cookie, I would just go with the upper approach and configure it directly in the datastream.

 

Side Notes

  •  your servlet should run before Launch is loaded, hence a synchronously call is recommended.
    Should this servlet response only be there for later calls to the Edge network, Adobe will primarily use the ECID from their kndctr_ cookies until they have expired and then fall back to the FPID cookie.

 

See also sample diagram and code for Adobe Experience Manager

https://experienceleague.adobe.com/en/docs/experience-manager-learn/sites/integrations/experience-platform/fpid

 

 

Hope that helps

Cheers from Switzerland!