Web SDK中的第一方裝置ID

Adobe Experience Platform Web SDK會使用Cookie將Adobe Experience Cloud ID (ECID)指派給網站訪客，以追蹤使用者行為。 若要說明瀏覽器對Cookie有效期的限制，您可以選擇設定並管理您自己的裝置識別碼。 這些稱為第一方裝置ID (FPID)。

本文介紹如何為Platform Web SDK實作設定第一方裝置ID。

先決條件

本指南假設您熟悉身分識別資料在Platform Web SDK中的運作方式，包括ECID和identityMap的角色。 如需詳細資訊，請參閱Web SDK🔗中身分資料的概觀。

使用FPID

FPID會使用第一方Cookie來追蹤訪客。 使用使用DNS A記錄 （適用於IPv4）或AAAA記錄 （適用於IPv6）的伺服器(而非DNS CNAME或JavaScript程式碼)設定第一方Cookie時，其最有效。

設定FPID Cookie後，就能在收集事件資料時擷取其值並傳送至Adobe。 收集的FPID會作為種子來產生ECID，這繼續是Adobe Experience Cloud應用程式中的主要識別碼。

若要將網站訪客的FPID傳送至PlatformEdge Network，您必須在該訪客的identityMap中加入FPID。 如需詳細資訊，請參閱本檔案後面關於在identityMap中使用FPID的章節。

ID格式需求

平台Edge Network只接受符合UUIDv4格式的ID。 不採用UUIDv4格式的裝置ID將會遭到拒絕。

產生UUID幾乎都會產生不重複的隨機ID，而發生碰撞的機率極小。 UUIDv4不能使用IP位址或任何其他個人識別資訊(PII)進行內建。 UUID隨處可見，而且幾乎每種程式語言都能找到程式庫來產生它們。

在資料串流UI中設定第一方ID Cookie setting-cookie-datastreams

您可以在資料串流UI中指定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

使用您擁有的伺服器設定Cookie時，可以使用各種方法防止Cookie因瀏覽器原則而受到限制：

何時設定Cookie

最好在向Edge Network提出任何請求之前先設定FPID Cookie。 但是，在無法提供的情況下，仍會使用現有方法產生ECID，並在Cookie存在時當作主要識別碼。

假設ECID最終受到瀏覽器刪除原則影響，但FPID未受到影響，則FPID會在下次造訪時成為主要識別碼，並用於在後續每次造訪時設定ECID種子。

設定Cookie的有效期

在實作FPID功能時，應謹慎設定Cookie的有效期。 在決定此專案時，您應該考量貴組織營運所在的國家或地區，以及每個地區的法律和政策。

在此決定中，您可能會想要採用全公司的Cookie設定原則，或針對您營運所在地區設定中不同使用者的不同原則。

無論您為Cookie的初始過期時間選取的設定為何，都必須確保加入邏輯，以便在每次發生新的網站造訪時延長Cookie的過期時間。

Cookie標幟的影響

有各種Cookie標幟會影響Cookie在不同瀏覽器中的處理方式：

HTTPOnly http-only

無法使用使用者端指令碼存取使用HTTPOnly標幟設定的Cookie。 這表示如果您在設定FPID時設定HTTPOnly旗標，則必須使用伺服器端指令碼語言來讀取要包含在identityMap中的Cookie值。

如果您選擇讓PlatformEdge Network讀取FPID Cookie的值，設定HTTPOnly旗標可確保任何使用者端指令碼都無法存取該值，但不會對PlatformEdge Network讀取Cookie的能力產生任何負面影響。

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": true
      }
    ],
    "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}"
    }
}

ID階層

當ECID和FPID同時存在時，ECID會優先識別使用者。 這可確保當瀏覽器Cookie存放區中存在現有的ECID時，仍會是主要識別碼，且現有的訪客計數不會受影響。 對於現有使用者，在ECID過期或因瀏覽器原則或手動程式而被刪除之前，FPID不會成為主要身分。

身分會依下列順序排定優先順序：

移轉至第一方裝置ID

如果您要從先前的實作移轉至FPID，可能很難在低層級視覺化轉換內容。

為了協助說明此流程，請思考先前曾造訪過您網站的客戶的情況，以及FPID移轉對Adobe解決方案中識別該客戶的方式有何影響。

常見問題集

以下是有關第一方裝置ID常見問題的解答清單。

植入ID和單純產生ID有何不同？

內建概念的獨特之處在於，傳遞至Adobe Experience Cloud的FPID會使用確定性演演算法轉換為ECID。 每次將相同的FPID傳送至Adobe Experience PlatformEdge Network時，相同的ECID則會從FPID內建而來。

何時應該產生第一方裝置識別碼？

若要減少訪客的潛在數量膨脹，應先產生FPID，再使用Web SDK提出第一個請求。 不過，如果您無法這麼做，系統仍會為該使用者產生ECID，並將該ECID當作主要識別碼使用。 產生的FPID不會成為主要識別碼，直到ECID不再存在為止。

哪些資料收集方法支援第一方裝置ID？

目前只有Web SDK支援FPID。

FPID是否儲存在任何平台或Experience Cloud解決方案上？

一旦使用FPID來設定ECID的種子後，就會從identityMap中捨棄該FPID，並取代為已產生的ECID。 FPID不會儲存在任何Adobe Experience Platform或Experience Cloud解決方案中。