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

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

NOTE
只有透過Web SDK將資料傳送至Experience Platform Edge Network時,才能使用第一方裝置ID支援。
IMPORTANT
第一方裝置ID與Web SDK中的第三方Cookie功能不相容。 您可以使用第一方裝置識別碼或第三方Cookie,但不可同時使用兩者。

先決條件 prerequisites

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

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

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

  • UUIDs是唯一的且隨機的,發生衝突的可能性微乎其微。
  • UUIDv4無法使用IP位址或任何其他個人識別資訊(PII)進行內建。
  • 用於產生UUIDs的程式庫可供各種程式語言使用。

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

  • 使用伺服器端指令碼語言產生Cookie
  • 設定Cookie以回應對子網域或網站上的其他端點發出的API請求
  • 使用CMS產生Cookie
  • 使用CDN產生Cookie

此外,您應該一律在您的網域的A記錄下設定FPID Cookie。

IMPORTANT
使用JavaScript的document.cookie方法設定的Cookie,幾乎永遠無法受到限制Cookie持續時間的瀏覽器原則的保護。

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

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

設定Cookie的有效期 set-expiration

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

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

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

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

HTTPOnly http-only

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

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

NOTE
使用HTTPOnly旗標並不會對可能限制Cookie存留期的Cookie原則造成影響。 不過,當您設定和讀取FPID的值時,還是應該考慮這個問題。

Secure secure

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

SameSite same-site

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

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

ID階層 id-hierarchy

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

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

  1. ECID包含在identityMap
  2. ECID儲存在Cookie中
  3. FPID包含在identityMap
  4. FPID儲存在Cookie中

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

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

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

圖表顯示客戶的ID值在移轉至FPID後如何在造訪之間更新

IMPORTANT
ECID Cookie一律優先於FPID
造訪
說明
首次造訪
假設您尚未開始設定FPID Cookie。 AMCV Cookie中包含的ECID將是用來識別訪客的識別碼。
第二次造訪
FPID解決方案的轉出已開始。 現有的ECID仍然存在,並且仍然是訪客識別的主要識別碼。
第三次造訪
在第二次和第三次造訪之間,已經過了足夠的時間且由於瀏覽器原則已刪除ECID。 但是,由於FPID是使用DNS A記錄設定的,因此FPID會持續存在。 FPID現在被視為主要ID,並用來設定寫入一般使用者裝置的ECID的種子。 在Adobe Experience Platform和Experience Cloud解決方案中,該使用者現在會被視為新訪客。
第四次瀏覽
在第三次和第四次造訪之間,已過了足夠的時間因瀏覽器原則而刪除ECID。 和上次造訪一樣,FPID會因設定方式而保留。 這次產生與上次造訪相同的ECID。 在整個Experience Platform和Experience Cloud解決方案中,使用者會被視為與上次造訪相同的使用者。
第五次瀏覽
在第四次和第五次造訪之間,使用者已清除其瀏覽器中的所有Cookie。 已產生新的FPID,並用來設定建立新ECID的種子。 在Adobe Experience Platform和Experience Cloud解決方案中,該使用者現在會被視為新訪客。

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

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

IMPORTANT
A或AAAA記錄僅支援設定和追蹤Cookie。 資料收集的主要方法是透過DNS CNAME。 使用A或AAAA記錄設定FPIDs,並使用CNAME傳送至Adobe。
第一方資料收集也支援Adobe管理的憑證方案

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

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

  • 方法1:為您的Web SDK呼叫設定CNAME,並在資料流設定中包含FPID Cookie的名稱。
  • 方法2:在身分對應中包含FPID。 如需詳細資訊,請參閱本檔案中有關identityMap中使用FPID的下一節。

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

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

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

範例

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

不含CNAME
與CNAME
  • 您的網站mywebsite.com使用Web SDK網域edge.adobedc.net傳送資料給Edge Network。
  • edge.adobedc.net設定的Cookie被視為協力廠商Cookie,因為它們並非來自您的mywebsite.com網域。 根據您的使用者瀏覽器,第三方Cookie可能會遭到封鎖,且您的資料無法送達Edge Network。
  • 您建立部署Web SDK的子網域,例如metrics.mywebsite.com
  • 您在DNS系統中設定CNAME記錄,使metrics.mywebsite.com指向edge.adobedc.net
  • 當您的網站透過metrics.mywebsite.com設定Cookie時,在瀏覽器中,它們將顯示為來自mywebsite.com (第一方)而非edge.adobedc.net (第三方)。 這能降低第一方ID Cookie遭到封鎖的可能性,確保資料收集作業更加準確。

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

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

IMPORTANT
此功能需要您啟用第一方資料收集

步驟 2.為您的資料流啟用 ​​第一方ID Cookie ​​ 功能

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

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

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

顯示資料流設定的平台UI影像,其中強調第一方ID Cookie設定

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

NOTE
使用第一方ID時,無法執行第三方ID同步。 協力廠商ID同步依賴於Visitor ID服務以及該服務產生的UUID。 使用第一方ID功能時,會產生ECID而不使用Visitor ID服務,因此無法同步第三方ID。

使用第一方ID時,由於Audience Manager合作夥伴ID同步主要是以UUIDsDIDs為基礎,因此不支援在合作夥伴平台中啟用的Audience Manager功能。 衍生自第一方ID的ECID未連結至UUID,使其無法定址。

方法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": "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}"
    }
}

常見問題集 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解決方案中。

recommendation-more-help
ad108910-6329-42f1-aa1d-5920a2b13636