Web SDK中的身分資料
Adobe Experience Platform Web SDK使用Adobe Experience Cloud ID (ECID)來追蹤訪客行為。 使用ECID,您可以確保每個裝置都有唯一識別碼,此識別碼可以跨多個工作階段持續存在,繫結特定裝置在Web工作階段期間和之間發生的所有點選。
本檔案概述如何使用Platform Web SDK管理ECID。
使用SDK追蹤ECID
Platform Web SDK會使用Cookie指派及追蹤ECID,並有多種可用方法來設定這些Cookie的產生方式。
當新使用者進入您的網站時,Adobe Experience Cloud Identity Service會嘗試為該使用者設定裝置識別Cookie。 首次造訪訪訪客時,系統會在首次從Adobe Experience PlatformEdge Network回應時產生並傳回ECID。 若為重複訪客,ECID會從kndctr_{YOUR-ORG-ID}_AdobeOrg_identity
Cookie擷取並由Edge Network新增至裝載。
設定包含ECID的Cookie後,Web SDK產生的每個後續請求都會在kndctr_{YOUR-ORG-ID}_AdobeOrg_identity
Cookie中包含編碼的ECID。
使用Cookie來識別裝置時,您有兩個選項可與Edge Network互動:
如下節所述,您選擇使用的資料收集方法會直接影響各瀏覽器的Cookie存留期。
協力廠商資料收集 third-party
第三方資料收集涉及直接傳送資料至Edge Network網域adobedc.net
。
近年來,網頁瀏覽器在處理第三方設定的Cookie時,限制日益嚴格。 有些瀏覽器預設會封鎖第三方Cookie。 如果您使用第三方Cookie來識別網站訪客,則這些Cookie的存留期幾乎總是比使用第一方Cookie所能提供的短。 有時第三方Cookie最快會在七天後過期。
此外,當使用第三方資料收集時,某些廣告封鎖程式會完全將流量限制在Adobe資料收集端點。
第一方資料收集 first-party
第一方資料收集涉及透過您自己的網域上指向adobedc.net
的CNAME設定Cookie。
雖然瀏覽器長期以來以與網站擁有端點所設定類似的方式處理CNAME端點所設定的Cookie,但瀏覽器最近實作的變更對CNAME Cookie的處理方式造成差異。 雖然目前沒有瀏覽器預設會封鎖第一方CNAME Cookie,但有些瀏覽器會將使用CNAME設定的Cookie存留期限製為僅七天。
Cookie有效期限對Adobe Experience Cloud應用程式的影響 lifespans
無論您是選擇第一方還是第三方資料收集,Cookie能持續存在的時間長度會直接影響Adobe Analytics和Customer Journey Analytics中的訪客計數。 此外,在網站上使用Adobe Target或Offer Decisioning時,一般使用者可能會遇到不一致的個人化體驗。
例如,假設您已建立個人化體驗,且使用者在過去七天內檢視過任何專案三次,此體驗會將任何專案提升至首頁。
如果一般使用者一週瀏覽三次,然後七天未返回網站,則該使用者在返回網站時可視為新使用者,因為其Cookie可能已遭到瀏覽器原則刪除(取決於使用者瀏覽網站時所使用的瀏覽器)。 如果發生這種情形,您的Analytics工具會將訪客視為新使用者,即使他們剛在七天多一點前造訪網站。 此外,使用者個人化體驗的任何工作都會重新開始。
第一方裝置ID
如上所述,若要考慮Cookie有效期限的影響,您可以選擇設定並管理您自己的裝置識別碼。 如需詳細資訊,請參閱第一方裝置識別碼的指南。
擷取目前使用者的ECID和區域 retrieve-ecid
根據您的使用案例,有兩種方法可以存取ECID:
- 透過「資料準備」擷取 ECID 以收集資料:建議您使用此方法。
- 透過
getIdentity()
命令擷取 ECID:只有在您需要使用者端的ECID資訊時,才使用此方法。
透過資料收集的資料準備擷取ECID retrieve-ecid-data-prep
使用資料彙集的「資料準備」將ECID對應到XDM欄位。 這是存取ECID的建議方式。
要執行此操作,請將來源欄位設定為以下路徑:
xdm.identityMap.ECID[0].id
然後,將目標欄位設定為欄位型別為string
的XDM路徑。
透過getIdentity()
命令擷取ECID retrieve-ecid-getidentity
getIdentity()
命令擷取ECID。 如果您只想將ECID對應到XDM欄位,請改用資料收集的資料準備。若要擷取目前訪客的唯一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.
});
使用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
}
]
}
}
});
CRMID
)傳送為主要身分。identityMap
中的每個屬性都代表屬於特定身分名稱空間的身分。 屬性名稱應為身分名稱空間符號,您可以在Adobe Experience Platform使用者介面的"身分"下方找到該符號。 屬性值應該是屬於該身分名稱空間的身分陣列。
identityMap
中傳遞的名稱空間ID區分大小寫。 請務必使用正確的名稱空間ID,以避免不完整的資料收集。身分陣列中的每個身分物件包含下列屬性:
id
authenticationState
ambiguous
、authenticated
和loggedOut
。primary
false
。使用identityMap
欄位來識別裝置或使用者,會產生與使用ID Service API中的setCustomerIDs
方法相同的結果。 如需詳細資訊,請參閱ID服務API檔案。
從訪客API移轉至ECID
從使用訪客API移轉時,您也可以移轉現有的AMCV Cookie。 若要啟用ECID移轉,請在設定中設定idMigrationEnabled
引數。 ID移轉可啟用下列使用案例:
- 當網域的某些頁面使用訪客API,而其他頁面使用此SDK時。 為了支援此情況,SDK會讀取現有的AMCV Cookie,並使用現有的ECID寫入新的Cookie。 此外,SDK會寫入AMCV Cookie,如此一來,如果先在使用SDK檢測的頁面上取得ECID,則使用訪客API檢測的後續頁面將具有相同的ECID。
- 在也具有Visitor API的頁面上設定Adobe Experience Platform Web SDK時。 為了支援此情況,如果未設定AMCV Cookie,SDK會在頁面上尋找訪客API,並呼叫它以取得ECID。
- 當整個網站使用Adobe Experience Platform Web SDK且沒有訪客API時,移轉ECID以便保留傳回的訪客資訊會很有用。 在與
idMigrationEnabled
一併部署SDK以便移轉大部分訪客Cookie之後,即可關閉設定。
更新要移轉的特徵
將XDM格式資料傳送到Audience Manager時,移轉時必須將此資料轉換為訊號。 必須更新您的特徵,以反映XDM提供的新索引鍵。 使用Audience Manager已建立的BAAAM工具,可讓此程式更容易。
用於事件轉送
如果您目前已啟用事件轉送,並且正在使用appmeasurement.js
和visitor.js
,您可以保持事件轉送功能已啟用,這樣就不會造成任何問題。 在後端,Adobe會擷取任何AAM區段,並將其新增至Analytics呼叫。 如果對Analytics的呼叫包含這些區段,Analytics將不會呼叫Audience Manager來轉送任何資料,因此不會有任何雙重資料收集。 使用Web SDK時也不需要位置提示,因為後端會呼叫相同的區段端點。