在Web SDK中使用第一方裝置ID

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

先決條件 prerequisites

開始之前，請確定您已熟悉身分識別資料在Web SDK中的運作方式，包括ECID和identityMap。 如需詳細資訊，請參閱網頁SDK中身分資料的概觀。

第一方裝置ID格式需求 formatting-requirements

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

使用您自己的伺服器設定FPID Cookie set-cookie-server

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

此外，您應該一律在您的網域的A記錄下設定FPID 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

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

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

Secure

以Secure屬性設定的Cookie只會以加密的要求透過HTTPS通訊協定傳送至伺服器。 使用此標幟有助於確保中間人攻擊者無法輕鬆存取Cookie的值。 可能的話，最好設定Secure旗標。

SameSite

SameSite屬性可讓伺服器判斷Cookie是否隨跨網站要求傳送。 屬性可針對跨網站偽造攻擊提供某些保護。 存在三個可能的值： Strict、Lax和None。 請洽詢您的內部團隊，判斷適合您組織的設定。

如果未指定SameSite屬性，某些瀏覽器的預設設定現在是SameSite=Lax。

ID階層 id-hierarchy

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

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

移轉至第一方裝置ID migrating-to-fpid

如果您要從先前的實施移轉至第一方裝置ID，可能很難在低層級視覺化轉換內容。

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

使用第一方裝置ID (FPID) using-fpid

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

設定FPID Cookie後，便可在收集事件資料時擷取其值並傳送至Adobe。 收集的FPIDs用於產生ECIDs，這是Adobe Experience Cloud應用程式中的主要識別碼。

您可以透過兩種方式使用FPIDs：

方法1：設定網頁SDK呼叫的CNAME，並在資料流中設定第一方ID Cookie setting-cookie-datastreams

若要從您自己的網域設定FPID Cookie，您必須為網頁SDK呼叫設定您自己的CNAME （正式名稱），然後在資料流設定中啟用First Party ID Cookie功能。

步驟 1.設定Web SDK部署網域​的CNAME

DNS中的CNAME記錄可讓您建立從某個網域名稱到另一個網域名稱的別名。 這可讓第三方服務看起來像是您自己的網域的一部分，因此其Cookie看起來像是第一方Cookie。

範例

假設您要在網站example.com上實作Web SDK。 網頁SDK會將資料傳送至Edge Network至edge.adobedc.net網域。

使用CNAME啟用第一方資料收集時，將會在對資料收集端點提出請求時傳送您網域的所有Cookie。

若要使用此功能，您必須將FPID Cookie設定在您網域的頂層，而非特定子網域。 如果您在子網域上設定它，Cookie值將不會傳送至Edge Network，且FPID解決方案將無法如預期運作。

步驟 2.為您的資料流​​First Party ID Cookie​ 啟用 ​功能

設定CNAME之後，您必須為資料流啟用​ First Party ID Cookie ​選項。 此設定可告知Edge Network在查詢第一方裝置ID時參考指定的Cookie，而不是在身分對應中查詢此值。

請參閱資料流設定檔案以瞭解如何設定資料流。

請參閱第一方Cookie的相關檔案，深入瞭解其如何使用Adobe Experience Cloud。

啟用此設定時，您必須提供預期儲存FPID的Cookie名稱。

方法2：在identityMap中使用FPID identityMap

除了將FPID儲存在您自己的Cookie中之外，您也可以透過身分對應將FPID傳送至Edge Network。

以下是如何在FPID中設定identityMap的範例：

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-42d3-9456-426614174000",
        "authenticatedState": "ambiguous",
        "primary": true
      }
    ]
  }
}

與其他身分型別一樣，您可以在FPID中包含identityMap與其他身分。 以下是已驗證FPID所包含的CRM ID範例：

{
  "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的錯誤回應，因為它遺失primary的FPID指標。 在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}"
    }
}

常見問題集 faq

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

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

內建概念是唯一的，因為傳遞至Adobe Experience Cloud的FPID會使用確定性演演算法轉換為ECID。 每次將相同的FPID傳送至Edge Network時，相同的ECID都是從FPID內建的。

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

若要降低訪客可能的膨脹率，應先產生FPID，再使用網頁SDK提出您的第一個要求。 不過，如果您無法執行此動作，仍會為該使用者產生ECID，並將作為主要識別碼使用。 產生的FPID不會成為主要識別碼，直到ECID不再存在為止。

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

目前只有Web SDK支援第一方裝置ID。

第一方裝置ID是否儲存在任何Platform或Experience Cloud解決方案上？

一旦使用FPID來植入ECID，就會從identityMap中捨棄該專案，並取代為已產生的ECID。 FPID未儲存在任何Adobe Experience Platform或Experience Cloud解決方案中。