Web SDK中的身分資料

Adobe Experience Platform Web SDK使用Adobe Experience Cloud ID (ECID)來追蹤訪客行為。 使用ECIDs時，您可以確保每個裝置都有唯一識別碼，此識別碼可以跨多個工作階段持續存在，將發生在網頁工作階段期間或跨網頁工作階段的所有點選繫結至特定裝置。

本檔案概述如何使用Web SDK管理ECIDs和CORE IDs。

使用Web SDK追蹤ECID tracking-ecids-web-sdk

Web SDK會使用Cookie指派及追蹤ECIDs，並有多種可用方法來設定這些Cookie的產生方式。

當新使用者進入您的網站時，Adobe Experience Cloud Identity Service會嘗試為該使用者設定裝置識別Cookie。

設定包含ECID的Cookie後，Web SDK產生的每個後續請求都會在kndctr_{YOUR-ORG-ID}_AdobeOrg_identity Cookie中包含編碼的ECID。

使用Cookie來識別裝置時，您有兩種方式可與Edge Network互動：

如下節所述，您選擇使用的資料收集方法會直接影響各瀏覽器的Cookie存留期。

使用Web SDK追蹤核心ID tracking-coreid-web-sdk

使用已啟用第三方Cookie的Google Chrome且未設定kndctr_{YOUR-ORG-ID}_AdobeOrg_identity Cookie時，第一個Edge Network請求會通過demdex.net網域，其會設定Demdex Cookie。 此Cookie包含CORE ID。 這是不重複的使用者ID，與ECID不同。

根據您的實作，您可能要存取 CORE ID。

第一方資料收集 first-party

第一方資料收集涉及透過您自己的網域上指向adobedc.net的CNAME設定Cookie。

雖然瀏覽器長期以來以與網站擁有端點所設定類似的方式處理CNAME端點所設定的Cookie，但瀏覽器最近實作的變更已對CNAME Cookie的處理方式造成差異。 雖然目前沒有瀏覽器預設會封鎖第一方CNAME Cookie，但有些瀏覽器會將使用CNAME設定的Cookie存留期限製為僅七天。

協力廠商資料收集 third-party

第三方資料收集涉及直接傳送資料至Edge Network網域adobedc.net。

近年來，網頁瀏覽器在處理第三方設定的Cookie時，限制日益嚴格。 有些瀏覽器預設會封鎖第三方Cookie。 如果您使用第三方Cookie來識別網站訪客，則這些Cookie的存留期幾乎總是比使用第一方Cookie所能提供的短。 有時第三方Cookie最快會在七天後過期。

此外，使用第三方資料收集時，有些廣告封鎖程式會完全將流量限制在Adobe資料收集端點。

Cookie有效期限對Adobe Experience Cloud應用程式的影響 lifespans

無論您是選擇第一方還是第三方資料收集，Cookie可儲存的時間長度會直接影響Adobe Analytics和Customer Journey Analytics中的訪客計數。 此外，在網站上使用Adobe Target或Offer decisioning時，一般使用者可能會遇到不一致的個人化體驗。

例如，假設您已建立個人化體驗，且使用者在過去七天內檢視過任何專案三次，此體驗會將任何專案提升至首頁。

如果一般使用者一週瀏覽三次，然後七天未返回網站，則該使用者在返回網站時可視為新使用者，因為其Cookie可能已遭到瀏覽器原則刪除（取決於使用者瀏覽網站時所使用的瀏覽器）。 如果發生此情況，您的Analytics工具會將訪客視為新使用者，即使他們剛在七天多一點前造訪網站。 此外，使用者個人化體驗的任何工作都會重新開始。

第一方裝置ID (FPID) fpid

如上所述，若要考慮Cookie有效期限的影響，您可以選擇設定並管理您自己的裝置識別碼。 如需詳細資訊，請參閱第一方裝置識別碼的指南。

擷取目前使用者的ECID和區域 retrieve-ecid

根據您的使用案例，有兩種方法可以存取ECID：

透過資料收集的資料準備擷取ECID retrieve-ecid-data-prep

使用資料彙集的「資料準備」將ECID對應到XDM欄位。 這是存取ECID的建議方式。

要執行此操作，請將來源欄位設定為以下路徑：

xdm.identityMap.ECID[0].id

然後，將目標欄位設定為欄位型別為string的XDM路徑。

透過getIdentity()命令擷取ECID retrieve-ecid-getidentity

若要擷取目前訪客的唯一ECID，請使用getIdentity命令。 對於尚無ECID的首次訪客，這個命令會產生新的ECID。 getIdentity也會傳回訪客的地區ID。

alloy("getIdentity")
  .then(function(result) {
    // The command succeeded.
    console.log("ECID:", result.identity.ECID);
    console.log("RegionId:", result.edge.regionId);
  })
  .catch(function(error) {
    // The command failed.
    // "error" will be an error object with additional information.
  });

擷取目前使用者的核心ID retrieve-coreid

若要擷取使用者的核心ID，您可以使用getIdentity()命令，如下所示。

alloy("getIdentity",{
  "namespaces": ["CORE"]
});

使用identityMap using-identitymap

使用XDM identityMap欄位，您可以使用多個識別碼來識別裝置/使用者、設定其驗證狀態，以及決定要將哪個識別碼視為主要識別碼。 如果尚未將任何識別碼設為primary，則主要預設值為ECID。

identityMap欄位已使用sentEvent命令更新。

alloy("sendEvent", {
  xdm: {
    "identityMap": {
      "ID_NAMESPACE": [ // Notice how each namespace can contain multiple identifiers.
        {
          "id": "1234",
          "authenticatedState": "authenticated",
          "primary": true
        }
      ]
    }
  }
});

identityMap中的每個屬性都代表屬於特定身分名稱空間的身分。 屬性名稱應為身分名稱空間符號，您可以在Adobe Experience Platform使用者介面的"身分"下方找到該符號。 屬性值應該是屬於該身分名稱空間的身分陣列。

身分陣列中的每個身分物件包含下列屬性：

使用identityMap欄位來識別裝置或使用者，會產生與使用ID Service API中的setCustomerIDs方法相同的結果。 如需詳細資訊，請參閱ID服務API檔案。

從訪客API移轉至ECID migrating-visitor-api-ecid

從使用訪客API移轉時，您也可以移轉現有的AMCV Cookie。 若要啟用ECID移轉，請在設定中設定idMigrationEnabled引數。 ID移轉可啟用下列使用案例：

更新要移轉的特徵

將XDM格式資料傳送到Audience Manager時，移轉時必須將此資料轉換為訊號。 必須更新您的特徵，以反映XDM提供的新索引鍵。 使用Audience Manager已建立的BAAAM工具，可讓此程式更容易。

用於事件轉送

如果您目前已啟用事件轉送，並且正在使用appmeasurement.js和visitor.js，您可以保持事件轉送功能已啟用，這樣就不會造成任何問題。 在後端，Adobe會擷取任何AAM區段，並將其新增至Analytics呼叫。 如果對Analytics的呼叫包含這些區段，Analytics將不會呼叫Audience Manager來轉送任何資料，因此不會有任何雙重資料收集。 使用Web SDK時也不需要位置提示，因為後端會呼叫相同的區段端點。