Web SDK中的第一方裝置ID
Adobe Experience Platform Web SDK會使用Cookie將Adobe Experience Cloud ID (ECID)指派給網站訪客，以追蹤使用者行為。 若要說明瀏覽器對Cookie有效期的限制，您可以選擇設定並管理您自己的裝置識別碼。 這些稱為第一方裝置識別碼(FPIDs)。
您可以使用第一方裝置識別碼，或使用第三方Cookie，但無法同時使用這兩項功能。
本檔案說明如何為Web SDK實作設定第一方裝置ID。
先決條件
本指南假設您熟悉身分識別資料在Platform Web SDK中的運作方式，包括ECID和identityMap的角色。 如需詳細資訊，請參閱Web SDK🔗中身分資料的概觀。
使用第一方裝置ID (FPID) using-fpid
第一方裝置ID (FPIDs)會使用第一方Cookie來追蹤訪客。 使用使用DNS A記錄 （適用於IPv4）或AAAA記錄 （適用於IPv6）的伺服器（而非DNS CNAME或JavaScript程式碼）設定第一方Cookie時，其最有效。
設定FPID Cookie後，便可在收集事件資料時擷取其值並傳送至Adobe。 收集的FPIDs會作為產生ECIDs的種子使用，繼續成為Adobe Experience Cloud應用程式中的主要識別碼。
若要將網站訪客的FPID傳送至Edge Network，您必須在該訪客的identityMap中加入FPID。 如需詳細資訊，請參閱本檔案中有關在identityMap中使用FPID的下一節。
第一方裝置ID格式需求 formatting-requirements
Edge Network只接受符合UUIDv4格式的IDs。 不採用UUIDv4格式的裝置ID將會遭到拒絕。
產生UUID幾乎都會產生唯一的隨機ID，發生衝突的可能性極小。 UUIDv4無法使用IP位址或任何其他個人識別資訊(PII)作為內建專案。 UUIDs隨處可見，幾乎可以找到每種程式語言產生它們的程式庫。
在資料串流UI中設定第一方ID Cookie setting-cookie-datastreams
您可以在資料串流使用者介面中指定Cookie名稱，該介面可容納FPID，而不必讀取Cookie值並在身分對應中包含FPID。
如需如何設定資料串流的詳細資訊，請參閱資料串流檔案。
設定資料流時，請啟用 第一方ID Cookie 選項。 此設定可告知Edge Network在查詢第一方裝置識別碼時參考指定的Cookie，而不是在身分對應中查詢此值。
請參閱第一方Cookie的相關檔案，深入瞭解其如何使用Adobe Experience Cloud。
啟用此設定時，您必須提供預期儲存ID的Cookie名稱。
使用第一方ID時，無法執行第三方ID同步。 協力廠商ID同步依賴於Visitor ID服務以及該服務產生的UUID。 使用第一方ID功能時，會產生ECID而不使用Visitor ID服務，因此無法同步第三方ID。
使用第一方ID時，由於Audience Manager合作夥伴ID同步主要以UUIDs或DIDs為基礎，因此不支援在合作夥伴平台中針對啟用的Audience Manager功能。 衍生自第一方ID的ECID未連結至UUID，使其無法定址。
使用您自己的伺服器設定Cookie set-cookie-server
使用您擁有的伺服器設定Cookie時，您可以使用各種方法防止Cookie因瀏覽器原則而受到限制：
- 使用伺服器端指令碼語言產生Cookie
- 設定Cookie以回應對子網域或網站上的其他端點發出的API請求
- 使用CMS產生Cookie
- 使用CDN產生Cookie
document.cookie方法設定的Cookie，幾乎永遠無法受到限制Cookie持續時間的瀏覽器原則的保護。何時設定Cookie when-to-set-cookie
最好在向Edge Network提出任何請求之前先設定FPID Cookie。 但是，在不可能的情況下，仍會使用現有方法產生ECID，並只要Cookie存在，就當作主要識別碼。
假設ECID最終受到瀏覽器刪除原則影響，但FPID未受到影響，則FPID將成為下次造訪的主要識別碼，並用於在每次後續造訪時設定ECID的種子。
設定Cookie的有效期 set-expiration
當您實作FPID功能時，應謹慎設定Cookie的到期日。 在決定此專案時，您應該考量貴組織營運所在的國家或地區，以及每個地區的法律和政策。
在此決定中，您可能會想要採用全公司的Cookie設定原則，或針對您營運所在地區設定中不同使用者的不同原則。
無論您為Cookie的初始過期時間選取的設定為何，都必須確保加入邏輯，以便在每次發生新的網站造訪時延長Cookie的過期時間。
Cookie標幟的影響 cookie-flag-impact
有各種Cookie標幟會影響Cookie在不同瀏覽器中的處理方式：
HTTPOnly http-only
無法使用使用者端指令碼存取使用HTTPOnly標幟設定的Cookie。 這表示如果您在設定FPID時設定HTTPOnly旗標，則必須使用伺服器端指令碼語言來讀取要包含在identityMap中的Cookie值。
如果您選擇讓Edge Network讀取FPID Cookie的值，設定HTTPOnly旗標可確保任何使用者端指令碼都無法存取該值，但不會對Edge Network讀取Cookie的能力產生任何負面影響。
HTTPOnly旗標並不會對可能限制Cookie存留期的Cookie原則造成影響。 不過，當您設定和讀取FPID的值時，還是應該考慮這個問題。Secure secure
以Secure屬性設定的Cookie只會以加密的要求透過HTTPS通訊協定傳送至伺服器。 使用此標幟有助於確保中間人攻擊者無法輕鬆存取Cookie的值。 可能的話，最好設定Secure旗標。
SameSite same-site
SameSite屬性可讓伺服器判斷Cookie是否隨跨網站要求傳送。 屬性可針對跨網站偽造攻擊提供某些保護。 存在三個可能的值： Strict、Lax和None。 請洽詢您的內部團隊，判斷適合您組織的設定。
如果未指定SameSite屬性，某些瀏覽器的預設設定現在是SameSite=Lax。
在identityMap中使用FPID identityMap
以下是如何在identityMap中設定FPID的範例：
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-42d3-9456-426614174000",
"authenticatedState": "ambiguous",
"primary": true
}
]
}
}
與其他身分型別一樣，您可以在identityMap中包含FPID與其他身分。 以下是已驗證CRM ID所包含的FPID範例：
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-42d3-9456-426614174000",
"authenticatedState": "ambiguous",
"primary": false
}
],
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated",
"primary": true
}
]
}
}
如果FPID包含在啟用第一方資料收集時Edge Network正在讀取的Cookie中，您應該僅擷取已驗證的CRM ID：
{
"identityMap": {
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated",
"primary": true
}
]
}
}
下列identityMap會導致Edge Network的錯誤回應，因為它遺失FPID的primary指標。 在identityMap中出現的最後一個ID必須標籤為primary。
{
"identityMap": {
"FPID": [
{
"id": "123e4567-e89b-12d3-a456-426614174000",
"authenticatedState": "ambiguous"
}
],
"EMAIL": [
{
"id": "email@mail.com",
"authenticatedState": "authenticated"
}
]
}
}
在此情況下，Edge Network傳回的錯誤回應將類似於以下內容：
{
"type": "https://ns.adobe.com/aep/errors/EXEG-0306-400",
"status": 400,
"title": "No primary identity set in request (event)",
"detail": "No primary identity found in the input event. Update the request accordingly to your schema and try again.",
"report": {
"requestId": "{REQUEST_ID}",
"configId": "{CONFIG_ID}",
"orgId": "{ORG_ID}"
}
}
在您自己的網域上設定FPID setting-fpid-domain
除了在身分對應中設定FPID之外，如果您已設定第一方資料收集CNAME，您也可以在您自己的網域上設定FPID Cookie。
使用CNAME啟用第一方資料收集時，將會在對資料收集端點提出請求時傳送您網域的所有Cookie。
與Adobe的資料收集用途無關的所有Cookie都會被捨棄。 對於FPID，您可以在資料流設定中指定FPID Cookie的名稱。 執行此操作時，Edge Network將讀取FPID Cookie的內容，而不是在身分對應中尋找FPID。
若要使用此功能，您必須將FPID設定在您網域的頂層，而非特定子網域。 如果您在子網域上設定它，Cookie值將不會傳送給Edge Network，且FPID解決方案將無法如預期運作。
ID階層 id-hierarchy
當ECID和FPID同時存在時，ECID會優先識別使用者。 這可確保當瀏覽器Cookie存放區中存在現有的ECID時，仍會是主要識別碼，且現有的訪客計數不會受到影響。 對於現有的使用者，FPID在ECID過期或因瀏覽器原則或手動程式而被刪除之前，不會成為主要身分。
身分會依下列順序排定優先順序：
- ECID包含在
identityMap中 - ECID儲存在Cookie中
- FPID包含在
identityMap中 - FPID儲存在Cookie中
移轉至第一方裝置ID migrating-to-fpid
如果您要從先前的實施移轉至第一方裝置ID，可能很難在低層級視覺化轉換內容。
為了協助說明此程式，請思考先前曾造訪過您網站的客戶的案例，以及FPID移轉對Adobe解決方案中識別該客戶的方式有何影響。
ECID Cookie一律優先於FPID。常見問題集 faq
以下是有關第一方裝置ID常見問題的解答清單。
植入ID和單純產生ID有何不同？
內建概念是唯一的，因為傳遞至Adobe Experience Cloud的FPID會使用確定性演演算法轉換為ECID。 每次將相同的FPID傳送至Edge Network時，相同的ECID都是從FPID內建的。
何時應該產生第一方裝置識別碼？
若要降低訪客的潛在數量膨脹，應先產生FPID，再使用Web SDK提出您的第一個請求。 不過，如果您無法執行此動作，仍會為該使用者產生ECID，並將作為主要識別碼使用。 產生的FPID不會成為主要識別碼，直到ECID不再存在為止。
哪些資料收集方法支援第一方裝置ID？
目前只有Web SDK支援第一方裝置ID。
第一方裝置ID是否儲存在任何平台或Experience Cloud解決方案上？
一旦使用FPID來植入ECID，就會從identityMap中捨棄該專案，並取代為已產生的ECID。 FPID未儲存在任何Adobe Experience Platform或Experience Cloud解決方案中。