在資料收集中使用第一方裝置識別碼

Experience Platform Edge Network使用Experience Cloud ID (ECID)來識別網站訪客。 若要改善所擁有屬性的身分識別耐久性，您可以設定和管理您自己的裝置識別碼，稱為第一方裝置ID (FPID)。 Edge Network使用FPID為Adobe解決方案使用的ECID提供種子。

本頁假設您熟悉ECID和identityMap。 如需詳細資訊，請參閱資料彙集中的身分。

何時使用FPID when-to-use

瀏覽器限制可能會縮短Adobe用來識別回訪訪客的Cookie有效期。 如果您需要在組織擁有和控制的網站上擁有更持久的身分識別，FPID可讓您管理自己的裝置識別碼，並使用它作為ECID的種子。

使用Web SDK （包括Web SDK標籤擴充功能）的Web實作支援FPID。 如果您的主要目標是在組織擁有的網域上更強大的身分持續性，或您想要擁有的網頁屬性上更佳的報告和個人化連續性，適合使用外掛程式。 它們也可讓您從控制的基礎架構中設定及管理第一方Cookie。

當您的主要目標是應用程式到網頁的移轉或跨多個網域的身分連續性時，FPID不是合適的工具。 若是這些案例，請參閱行動裝置對網頁的身分共用和跨網域共用。

使用FPID的好處包括：

使用FPID的權衡包括：

高階設定路徑

FPID的運作方式 how-fpids-work

傳遞至Adobe Experience Cloud的FPID會使用確定性演演算法轉換為ECID。 每次將相同的FPID傳送至Edge Network時，相同的ECID都會從FPID內建。 一旦使用FPID來設定ECID的種子後，就會從identityMap中將其捨棄，並取代為產生的ECID。 FPID不會儲存在Adobe Experience Platform或Experience Cloud解決方案中。

當ECID和FPID同時存在時，系統會一律使用ECID來先識別使用者。 此優先順序可確保在瀏覽器Cookie存放區中存在現有ECID時，保留其主要識別碼，且現有訪客計數不會增加風險。 對於現有使用者，在ECID過期或因瀏覽器原則或手動動作而遭到刪除之前，FPID不會成為主要身分。

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

產生並設定FPID Cookie set-fpid-cookie

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

伺服器端Cookie設定 set-cookie-server

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

使用使用DNS A記錄 （適用於IPv4）或AAAA記錄 （適用於IPv6）的伺服器（與DNS CNAME或JavaScript程式碼相反）設定第一方Cookie時，其最有效。

請注意，A或AAAA記錄僅支援設定和追蹤Cookie。 資料收集的主要方法是透過DNS CNAME。 使用A或AAAA記錄設定FPID，並使用CNAME傳送至Adobe。 Adobe-Managed Certificate Program可讓您設定資料收集的CNAME。

何時設定Cookie when-to-set-cookie

理想情況下，在傳送資料至Edge Network之前，請先設定FPID Cookie。 如果您的實作在收集資料之前需要同意，請參閱使用第一方裝置ID的同意，以取得協調FPID Cookie與您的同意流程的指引。 當您確定FPID可用來從第一個要求為ECID設定種子時，即可減少訪客數量膨脹。 在無法提供的情況下，仍會使用現有方法產生ECID，並在Cookie存在時作為主要識別碼。 產生的FPID不會成為主要識別碼，直到ECID不再存在為止。 假設ECID最終受到瀏覽器刪除原則影響，但FPID未受到影響，則FPID會在下次造訪時成為主要識別碼，並用於在後續每次造訪時設定ECID種子。

設定有效期 set-expiration

Adobe建議您仔細考慮FPID Cookie的存留期。 請務必將貴組織的隱私權政策，以及貴組織營運所在國家或地區的法律和政策納入考量。 根據您組織的設定，您可以採用全公司的Cookie設定原則，或根據您營運所在每個地區設定中使用者的不同而採用的原則。 無論初始Cookie過期時間為何，請務必加入每次發生新網站造訪時都會延長過期時間的邏輯。

Cookie標幟 cookie-flags

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

將FPID傳送至Edge Network send-fpid

您可透過兩種方式將FPID傳送至Edge Network：

方法1：設定CNAME並在資料流中設定第一方ID Cookie setting-cookie-datastreams

若要從您自己的網域設定FPID Cookie，您必須為網頁SDK呼叫設定您自己的CNAME，然後在資料流設定中啟用第一方ID Cookie功能。 DNS中的CNAME記錄可讓您建立從某個網域名稱到另一個網域名稱的別名。 此別名可讓第三方服務看起來像是您自己的網域的一部分，讓其Cookie看起來像是第一方Cookie。 當使用CNAME啟用第一方資料收集時，您網域的所有Cookie都會在對資料收集端點提出請求時傳送。

方法2：在identityMap中使用FPID identityMap

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

以下是如何在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": "user@example.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

啟用第一方資料收集時，如果FPID包含在Edge Network正在讀取的Cookie中，請僅擷取已驗證的CRM ID：

{
  "identityMap": {
    "EMAIL": [
      {
        "id": "user@example.com",
        "authenticatedState": "authenticated",
        "primary": true
      }
    ]
  }
}

下列identityMap導致來自Edge Network的錯誤回應，因為它遺失FPID的primary指標。 identityMap中至少有一個識別碼必須標示為primary。

{
  "identityMap": {
    "FPID": [
      {
        "id": "123e4567-e89b-12d3-a456-426614174000",
        "authenticatedState": "ambiguous"
      }
    ],
    "EMAIL": [
      {
        "id": "user@example.com",
        "authenticatedState": "authenticated"
      }
    ]
  }
}

移轉至FPID migrating-to-fpid

如果您要從先前的實施移轉至第一方裝置ID，可能很難在低層級視覺化轉換內容。 為了協助說明此程式，請思考先前曾造訪過您網站的客戶案例，以及FPID移轉對Adobe解決方案中識別該客戶的方式有何影響。