命名空間優先等級
每個客戶實作都是獨一無二，並根據特定組織的目標量身打造，因此，特定名稱空間的重要性因客戶而異。 現實世界的範例包括：
- 貴公司可能會將每個電子郵件地址視為代表單一人員實體，因此使用身分設定將電子郵件名稱空間設定為唯一。 但其他公司可能想要將單一人員實體表示為具有多個電子郵件地址，因此將電子郵件名稱空間設定為非唯一。 這些公司需要使用另一個身分名稱空間作為唯一，例如CRMID名稱空間，因此可能會有一個單一人員識別碼連結到多個電子郵件地址。
- 您可以使用「登入ID」名稱空間收集線上行為。 此登入ID可能會與CRMID維持1:1關係，而CRMID則會儲存CRM系統的屬性，且可能會被視為最重要的名稱空間。 在此案例中，您接著會判斷CRMID名稱空間是人員的更精確表示法，而「登入ID」名稱空間是第二重要的。
您必須在Identity Service中進行反映名稱空間重要性的設定，因為這會影響設定檔及其相關身分圖表的形成和分割方式。
決定您的優先順序
名稱空間優先順序的判斷會依據下列因素：
身分圖表結構
如果貴組織的圖表結構是分層的，則名稱空間優先順序應反映這一點，以便在圖表摺疊時移除正確的連結。
-
「圖表摺疊」是指多個不同的設定檔不慎合併到單一身分圖表中的情況。
-
分層圖表是指具有多重連結層級的身分圖表。 檢視下方影像以取得含有三個圖層的圖形範例。
名稱空間的語意意義
身分代表真實世界的物件。 身分圖中有三個物件代表。 按照重要性順序，它們是：
- 人員（跨裝置、電子郵件、電話號碼）
- 硬體裝置
- 網頁瀏覽器(Cookie)
與硬體裝置（例如IDFA、GAID）相比，人員名稱空間相對不可變，而硬體裝置相對於網頁瀏覽器則相對不可變。 基本上，您（人員）永遠是單一實體，擁有多部硬體裝置（手機、筆記型電腦、平板電腦等），並使用多部瀏覽器(Google Chrome、Safari、FireFox等)
處理此主題的另一種方法是使用基數。 對於指定的人員實體，將會建立多少身分？ 在大多數情況下，人員會有一個CRMID、數個硬體裝置識別碼（IDFA/GAID重設不應該經常發生），以及甚至更多Cookie （個人可視需要瀏覽多個裝置、使用無痕模式或在任何指定時間重設Cookie）。 一般而言，較低的基數表示具有較高值 的名稱空間。
驗證名稱空間優先順序設定
瞭解如何排列名稱空間的優先順序後，您就可以在UI中使用圖表模擬工具來測試各種圖表摺疊情況，並確保優先順序設定傳回預期的圖表結果。 如需詳細資訊，請閱讀使用圖表模擬工具的指南。
設定名稱空間優先順序
可使用身分設定UI來設定名稱空間優先順序。 在身分設定介面中，您可以拖放名稱空間以判斷其相對重要性。
名稱空間優先順序使用方式
目前，名稱空間優先順序會影響即時客戶個人檔案的系統行為。 下圖說明了此概念。 如需詳細資訊，請閱讀Adobe Experience Platform和應用程式架構圖的指南。
Identity Service：身分最佳化演演算法
對於相對複雜的圖表結構，名稱空間優先順序在確保在圖表摺疊情況發生時移除正確連結方面扮演重要角色。 如需詳細資訊，請閱讀身分最佳化演演算法總覽。
即時客戶個人檔案：體驗事件的主要身分確定
-
在您設定好指定沙箱的身分設定後，體驗事件的主要身分將由設定中最高的名稱空間優先順序決定。
- 這是因為體驗事件的本質是動態的。 身分對應可能包含三個或更多身分，而名稱空間優先順序可確保最重要的名稱空間與體驗事件相關聯。
-
因此，即時客戶設定檔 將不再使用下列設定：
- 使用Web SDK、Mobile SDK或Edge Network伺服器API在identityMap中傳送身分時，主要身分設定(
primary=true) （身分名稱空間和身分值將繼續用於設定檔中）。 注意： Real-time Customer Profile以外的服務(如Data Lake Storage或Adobe Target)將繼續使用主要身分設定(primary=true)。 - 任何在XDM體驗事件類別結構描述上標示為主要身分的欄位。
- Adobe Analytics來源聯結器（ECID或AAID）中的預設主要身分設定。
- 使用Web SDK、Mobile SDK或Edge Network伺服器API在identityMap中傳送身分時，主要身分設定(
-
另一方面，名稱空間優先順序不會決定設定檔記錄 的主要身分。
- 針對設定檔記錄，您應該繼續在結構描述中定義身分欄位，包括主要身分。 如需詳細資訊，請參閱在UI中定義身分欄位的指南。
-
名稱空間優先順序是 名稱空間 的屬性。 這是指派給名稱空間的數值，可指出其相對重要性。
-
主要身分是儲存設定檔片段所針對的身分。 設定檔片段是儲存特定使用者相關資訊的資料記錄：屬性（例如CRM記錄）或事件（例如網站瀏覽）。
範例情境
本節提供優先順序設定如何影響資料的範例。
假設為給定沙箱建立了以下設定：
基於上述設定，使用者動作和主要身分的判定將依下列方式解析：
{ECID}{ECID, IDFA}{CRMID, ECID}{CRMID, ECID, AAID}{CRMID, GAID, ECID}細分服務：區段會籍中繼資料儲存
對於指定的合併設定檔，區段會籍會根據具有最高名稱空間優先順序的身分來儲存。
例如，假設有兩個設定檔：
-
設定檔1代表John。
- John的設定檔符合S1 （區段會籍1）資格。 例如，S1可能指識別為男性的客戶區段。
- John的設定檔也符合S2 （區段會籍2）資格。 這可能代表忠誠度狀態為金色的客戶區段。
-
個人資料2代表Jane。
- Jane的個人資料符合S3 （區段會籍3）資格。 這可能是指識別為女性的客戶區段。
- Jane的個人資料也符合S4 （區段會籍4）資格。 這可以指代忠誠度狀態為白金級的客戶區段。
如果John和Jane共用裝置，則ECID （網頁瀏覽器）會從一個人傳輸給另一個人。 不過，這不會影響針對John和Jane所儲存的區段會籍資訊。
如果區段資格標準完全以根據ECID儲存的匿名事件為基礎，則Jane將符合該區段的資格
對其他Experience Platform服務的影響 implications
本節概述名稱空間優先順序如何影響其他Experience Platform服務。
進階資料生命週期管理
對於指定的身分，資料衛生記錄刪除請求會以下列方式運作：
- 即時客戶設定檔：刪除任何將指定身分識別為主要身分的設定檔片段。 設定檔上的主要身分現在將根據名稱空間優先順序來判定。
- 資料湖：刪除任何以指定身分作為主要身分的記錄。 與即時客戶設定檔不同，資料湖中的主要身分是以WebSDK (
primary=true)上指定的主要身分或標示為主要身分的欄位為基礎
如需詳細資訊，請閱讀進階生命週期管理概觀。
計算屬性
如果啟用身分設定，則計算屬性將使用名稱空間優先順序來儲存計算屬性值。 對於指定的事件，具有最高名稱空間優先順序的身分將會擁有針對其寫入的計算屬性的值。 如需詳細資訊，請閱讀計算屬性UI指南。
資料湖
資料湖的資料擷取將繼續遵循在Web SDK和結構描述上設定的主要身分設定。
資料湖不會根據名稱空間優先順序來判斷主要身分。 例如，Adobe Customer Journey Analytics將繼續使用身分對應中的值，即使在啟用名稱空間優先順序後（例如，將資料集新增到新連線），因為Customer Journey Analytics會消耗其來自資料湖的資料。
Experience Data Model (XDM)結構
任何不是XDM體驗事件的結構描述（例如XDM個別設定檔）將繼續遵循您標籤為身分的任何欄位。
如需有關XDM結構描述的詳細資訊，請閱讀結構描述概觀。
Intelligent services
選取資料時，您需要指定名稱空間，用於決定計算分數的事件，以及儲存計算分數的事件。 建議您選取代表個人的名稱空間。
- 如果您使用WebSDk收集Web行為資料，建議您在身分對應中選擇CRMID名稱空間。
- 如果您使用Analytics來源聯結器收集網頁行為資料，則應該選取身分描述項(CRMID)。
此設定導致僅使用已驗證的事件計算分數。
如需詳細資訊，請閱讀Attribution AI和客戶人工智慧上的檔案。
合作夥伴建立的目的地
與共用裝置相關之設定檔的更新對象資格取消結果可能不會傳送至下游目的地。 這種情況可能會發生在某些罕見的情況下，例如：
- 對象資格僅以匿名活動為基礎。
- 在短時間內可以跨多個設定檔登入。
如需合作夥伴建立的目的地詳細資訊，請閱讀目的地概觀。
Privacy Service
針對指定的身分，以下列方式Privacy Service刪除要求功能：
- 即時客戶設定檔：刪除任何將指定身分值作為主要身分的設定檔片段。 設定檔上的主要身分現在將根據名稱空間優先順序來判定。
- 資料湖：刪除具有指定身分作為主要或次要身分的任何記錄。
如需詳細資訊，請閱讀隱私權服務概觀。
Adobe Target
使用邊緣細分時，Adobe Target可能會針對共用裝置案例產生非預期的使用者目標定位。