在此頁面上：瞭解如何使用補充識別碼（例如訂單或預訂ID之類的次要識別碼）來針對每個識別碼執行個別的歷程執行個體，並使用其屬性個人化訊息。
依預設，歷程會在 設定檔ID 的內容中執行。這表示，只要設定檔在指定歷程中處於作用中狀態，就無法將設定檔重新進入另一個歷程。為避免此問題，除了設定檔ID之外，Journey Optimizer可讓您擷取補充識別碼，例如訂單ID、訂閱ID、處方ID。
在此範例中，我們已新增 預訂ID 作為補充識別碼。
如此一來，歷程會在與補充識別碼（此處為預訂ID）相關聯的設定檔ID內容中執行。 每個補充識別碼的疊代都會執行一個歷程例項。 如果訪客已進行不同預約，這可在歷程中讓多個入口使用相同的設定檔ID。
此外，Journey Optimizer可讓您運用補充識別碼的屬性來自訂訊息（例如預訂編號、處方續約日期、產品型別），確保高度相關的通訊。
➡️ 在影片中探索此功能
護欄與限制 guardrails
-
支援的歷程： 事件觸發和 讀取對象 歷程支援補充識別碼。 對象資格歷程（亦即以對象資格活動開始的歷程）中不支援。
-
傳入動作：目前不支援傳入動作（例如應用程式內和Web動作）的補充識別碼。
-
並行執行個體限制：設定檔不能有超過10個並行歷程執行個體。
-
資料型別和結構描述結構：補充識別項必須是型別
string。 它可以是獨立的字串屬性，也可以是物件陣列中的字串屬性。 獨立的字串屬性會產生單一歷程例項，而物件陣列中的字串屬性則會導致物件陣列的每個疊代產生唯一的歷程例項。 不支援字串陣列和地圖。 -
歷程重新進入
具有補充識別碼的歷程重新進入行為遵循現有的重新進入原則：
- 如果歷程不可重新進入，則相同的設定檔ID +補充ID組合無法重新進入歷程。
- 如果歷程透過時間視窗重新進入，則相同的設定檔ID +補充ID組合可在定義的時間視窗後重新進入。
-
資料使用標籤與實作(DULE) — 未對補充ID執行DULE驗證檢查。 這表示當歷程尋找資料治理原則違規時，不會考慮此屬性。
-
下游事件設定
如果您在歷程下游使用另一個事件，該事件必須使用相同的補充ID並具有相同的ID名稱空間。
-
讀取對象歷程
- 商務事件：如果您使用商務事件，則補充ID已停用。
- 事件和內容欄位：補充識別碼不得來自事件或歷程內容欄位。
- 屬性選擇：任何非身分屬性（或非個人身分）都可做為所有對象型別（統一設定檔服務、CSV匯入和同盟對象構成）的補充ID。 不允許以人員為基礎的身分屬性。 若為外部對象，請參閱外部對象的補充識別碼以瞭解支援的資料模式和組態需求。
- 讀取率：對於使用陣列型別補充ID欄位的讀取對象歷程，讀取對象活動的讀取率限製為每秒500個設定檔。
具有補充ID的退出條件行為 exit-criteria
先決條件：為補充ID啟用歷程（透過單一事件或讀取對象活動）
下表說明設定退出條件時，設定檔在啟用ID的補充歷程中的行為：
注意：補充ID名稱空間必須符合初始節點的名稱空間。
新增補充識別碼並在歷程中運用 add
若要在事件觸發的歷程中使用補充識別碼，請遵循下列步驟：
-
將補充ID新增至事件
-
建立或編輯所需的事件。 瞭解如何設定單一事件
-
在事件組態畫面中，勾選 使用補充識別碼 選項。
-
使用運算式編輯器來選取您要當作補充ID使用的欄位（例如，預訂ID、訂閱ID）。
note NOTE 請確定您在 進階模式 中使用運算式編輯器來選取屬性。
-
-
將事件新增至歷程
將已設定的事件拖曳至歷程畫布。 它會根據設定檔ID和補充ID來觸發歷程專案。
若要在讀取對象歷程中使用補充識別碼，請遵循下列步驟：
-
在歷程中新增並設定讀取對象活動
-
在您的歷程中拖曳 讀取對象 活動。
-
在活動屬性窗格中，開啟 使用補充識別碼 選項。
-
在 Supplemental identifier 欄位中，使用運算式編輯器來選取補充識別碼屬性。
針對從CSV檔案匯入的對象🔗，如果您的CSV對象包含每個設定檔ID的多個列，請確定先啟用「快速啟用」 — 請參閱外部對象的補充識別碼。
[！NOTE]
請確定您在 進階模式 中使用運算式編輯器來選取屬性。
-
善用補充ID屬性
使用運算式編輯器和個人化編輯器來參照個人化或條件邏輯的補充識別碼屬性。 可從 內容屬性 功能表存取屬性。
針對事件觸發的歷程，如果您使用陣列（例如，多個處方或原則），請使用公式來擷取特定元素。
在補充ID為bookingNum且屬性位於相同層級bookingCountry的物件陣列中，歷程將根據bookingNum逐一檢視陣列物件，並為每個物件建立歷程執行個體。
-
條件活動中的下列運算式將逐一檢視物件陣列，並檢查
bookingCountry的值是否等於「FR」：code language-none @event{<event_name>.<object_path>.<object_array_name>.all(currentEventField.<attribute_path>.bookingNum==${supplementalId}).at(0).<attribute_path>.bookingCountry}=="FR" -
電子郵件個人化編輯器中的下列運算式將會逐一檢視物件陣列、提取適用於目前歷程執行個體的
bookingCountry，並在內容中顯示它：code language-none {{#each context.journey.events.<event_ID>.<object_path>.<object_array_name> as |l|}} {%#if l.<attribute_path>.bookingNum = context.journey.technicalProperties.supplementalId%} {{l.<attribute_path>.bookingCountry}} {%/if%} {{/each}} -
用來觸發歷程的事件範例：
code language-none "bookingList": [ { "bookingInfo": { "bookingNum": "x1", "bookingCountry": "US" } }, { "bookingInfo": { "bookingNum": "x2", "bookingCountry": "FR" } } ]
補充ID和歷程仲裁 arbitration
歷程仲裁（包括規則集中的並行上限和登入計數）在設定檔ID層級操作，而不是（設定檔ID、補充ID）配對層級。 這表示並行次數上限為1可能會封鎖相同設定檔的第二個歷程例項，即使其中包含不同的補充ID值亦然。
在依賴生產中的特定仲裁設定之前，請聯絡您的Adobe代表以取得仲裁行為的指引。
相關檔案：
外部對象的補充識別碼 external-audiences
外部對象支援補充ID，包括從CSV檔案🔗匯入的對象以及使用同盟對象構成建立的對象。 設定從CSV或Federated對象構成對象讀取的歷程時，您可以指定該對象中的任何非身分屬性作為補充ID。 接著Journey Optimizer會為每個唯一設定檔+補充ID組合建立個別的歷程執行個體。
-
使用案例1：每個唯一設定檔一列+補充ID組
這是CSV和同盟對象構成對象的主要使用案例。 對象包含多列，每一列代表設定檔（例如客戶）和補充ID （例如帳戶或訂單ID）的唯一組合。 每一列都會被視為獨立的啟用記錄。
table 0-row-3 1-row-3 2-row-3 3-row-3 profile_id account_id （補充識別碼） other_attributes customer_001 ACC-1001 … customer_001 ACC-1002 … customer_002 ACC-2001 … 在此範例中，
customer_001有兩個帳戶。 Journey Optimizer會為每個唯一設定檔+account_id配對建立個別的歷程執行個體。 -
使用案例2：具有補充ID陣列的每個設定檔一列
此使用案例適用於支援陣列的對象型別。 對象中的單一列包含設定檔，其陣列屬性保留多個補充ID值。 Journey Optimizer會在陣列中為每個值建立一個歷程例項。
table 0-row-3 1-row-3 2-row-3 profile_id account_ids （陣列，補充識別碼） other_attributes customer_001 [ACC-1001、ACC-1002] … customer_002 [ACC-2001] … 在此範例中，Journey Optimizer為
customer_001產生兩個歷程執行個體（每個帳戶ID一個執行個體），並為customer_002產生一個執行個體。 此行為與補充ID對統一設定檔服務對象的運作方式一致。
如何設定 external-configuration
針對使用案例1的CSV對象（對象有意包含相同設定檔ID的多列），您必須在設定歷程之前啟用「快速啟用」。 請參閱下列必要條件。 對於所有其他情況，請直接設定歷程。
| note important |
|---|
| IMPORTANT |
此先決條件僅適用於CSV對象，該對象有意包含相同設定檔ID的多個列（使用案例1）。 同盟對象構成對象預設會啟用「快速啟動」，不需要此步驟。 Audience Portal UI不支援設定expressActivation — 您必須使用外部對象API。 |
您必須在建立時啟用對象的expressActivation。 這會告訴Journey Optimizer要獨立啟用每筆記錄，而不需依設定檔ID重複資料刪除。 建立受眾後，就無法變更此標幟。
建立對象時，請使用下列API呼叫：
端點：
| code language-http |
|---|
|
必要的標頭：
| code language-http |
|---|
|
要求內文（設定expressActivation: true）：
| code language-json |
|---|
|
| note |
|---|
| NOTE |
expressActivation預設為false。 它必須在建立對象時設定，並且無法在建立後變更。 所有同盟對象構成對象預設都會啟用「快速啟動」，不需要此標幟。 |
如需完整參考資訊，請參閱建立外部對象API檔案。
設定歷程：
- 開啟或建立具有 讀取對象 節點的歷程。
- 在 讀取對象 節點設定中，選取您的CSV或同盟對象構成對象。
- 開啟 使用增補識別碼 選項，然後在 增補識別碼 欄位中，在 進階模式 中使用運算式編輯器，以選擇要用作次要識別碼的屬性（例如，
account_id、order_number）。 - 選取的屬性會視為歷程的補充ID — 不需要身分註冊。
重複資料刪除行為 external-dedup
當對象啟用「快速啟用」（同盟對象構成一律為True — 必須為CSV明確設定）時，Journey Optimizer會根據歷程的設定方式處理重複資料刪除：
範例使用案例
這些範例顯示補充識別碼如何支援多個相關記錄。
原則更新通知
-
案例：保險公司針對客戶持有的每個有效保單傳送續約提醒。
-
執行：
- 設定檔： “John”。
- 補充ID：
"AutoPolicy123", "HomePolicy456"。 - 歷程會針對每個原則個別執行，並提供個人化的續約日期、涵蓋範圍詳細資料和進階資訊。
訂閱管理
-
案例：當訂閱觸發事件時，訂閱服務會針對每個訂閱傳送量身打造的訊息。
-
執行：
- 設定檔： 「Jane」。
- 補充ID：
"Luma Yoga Program ", "Luma Fitness Program"。 - 每個事件都包含訂閱ID和該訂閱的詳細資訊。 歷程會針對每個事件/訂閱個別執行，允許每個訂閱提供個人化的續約優惠。
產品推薦
-
案例：電子商務平台會根據客戶購買的特定產品傳送建議。
-
執行：
- 設定檔： 「Alex」。
- 補充ID：
"productID1234", "productID5678"。 - 歷程會針對每個產品個別執行，並提供個人化的追加銷售機會。
作法影片 video
瞭解如何在Adobe Journey Optimizer中啟用並套用補充識別碼。
本節包含結構化知識，用於支援與本主題相關的解譯、擷取和問答。
如需完整瞭解，此資訊應結合本頁的檔案。 兩者皆非獨立來源；頁面說明功能，本節提供額外內容，以協助去除術語、意圖、適用性和限制條件的歧義。
- TL；DR：此頁面說明如何在Adobe Journey Optimizer歷程中使用補充識別碼，以允許單一設定檔擁有多個並行歷程執行個體，每個執行個體都限定為不同的次要ID，例如預訂、訂閱或原則ID。
意圖：
- 瞭解何時及為何使用補充識別碼，而非僅依賴設定檔ID
- 在事件方案中將屬性標籤為身分，以在事件觸發的歷程中設定補充識別碼
- 啟用讀取對象活動中的選項，在讀取對象歷程中設定補充識別碼
- 使用運算式編輯器參考訊息個人化和條件邏輯的補充識別碼屬性
- 套用正確的運算式語法，以透過補充ID作為索引鍵的物件陣列進行反複運算
- 在歷程中實作補充識別碼之前，識別護欄和限制
字彙表：
- 補充識別碼：與設定檔識別碼搭配使用的次要識別碼（例如，訂單ID、預訂ID、訂閱ID），以將歷程執行個體範圍設定為特定記錄，為每個設定檔 （產品特定） 啟用多個並行執行個體
- 設定檔識別碼：預設用來執行歷程的主要識別碼；歷程中作用中的設定檔若沒有補充ID，就無法重新進入另一個歷程
- 非人員識別碼名稱空間：不代表人員的身分名稱空間（補充ID所需）；必須與主要身分名稱空間不同
- joai名稱空間：不適用於此頁面（請參閱傳入動作疑難排解）
- DULE：資料使用標籤和實行 — Adobe Experience Platform中的資料治理原則驗證架構；補充ID不受DULE檢查
護欄：
- 僅事件觸發和讀取對象歷程支援補充識別碼，對象資格歷程不支援
- 設定檔不能有超過10個同時歷程執行個體
- 即使透過補充識別碼建立，每個歷程執行個體都會計入頻率上限
- 補充識別碼必須是型別
string；不支援字串陣列和對應 - 在結構描述中，補充ID屬性不可標示為主要身分
- 用於補充ID的名稱空間必須是非人員識別碼名稱空間
- 將非人員身分名稱空間套用至結構描述後，必須建立新事件或欄位群組；無法重新整理現有實體
- 對於具有補充ID的讀取對象歷程：每個歷程執行個體的讀取率限製為每秒500個設定檔；僅支援統一設定檔服務對象；補充ID必須是設定檔欄位（而非事件/內容欄位）
- 相同歷程中的下游事件必須使用相同的補充ID和名稱空間
- 使用業務事件的讀取對象歷程已停用補充ID
術語：
- 正式名稱：增補識別碼 — 縮寫：none — 變體：增補ID、次要識別碼
- 同義字： “supplemental identifier” = “supplemental ID” （在UI和檔案中可互換使用）
- 請勿混淆：「supplemental identifier」≠「primary identity」 — 在結構描述中，絕不可將補充ID標示為主要身分
常見問題集：
- 問：什麼是Supplemental ID用於？ — 它可讓單一設定檔同時多次輸入及執行歷程，而每個執行個體範圍限定為不同的次要記錄，例如預訂、訂閱或原則ID。
- 問：哪些歷程型別支援補充識別碼？ — 事件觸發的歷程和讀取對象歷程。 對象資格歷程不支援補充識別碼。
- 問：設定檔可以有多少個並行歷程執行個體具有補充識別碼？ — 每個設定檔最多10個同時歷程執行個體。
- 問：我可以在訊息個人化中使用補充ID屬性嗎？ — 是。 透過運算式編輯器或個人化編輯器中的內容屬性選單，參考這些內容。
- 問：補充ID是否需要在結構描述中標示為主要身分？ — 否。 它必須標籤為身分，但不得設定為主要身分。
- 問：DULE治理原則是否套用至補充識別碼？ — 否。 補充識別碼上不會執行DULE驗證檢查。