文件Journey OptimizerJourney Optimizer 指南

設定您的歷程屬性 jo-properties

Last update: Wed Jun 26 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
  • 主題：

建立對象：

  • undefined
  • undefined

存取歷程的屬性 access-properties

歷程的屬性會集中在右邊欄中。 建立新歷程時，預設會顯示此區段。 對於現有歷程，按一下歷程名稱旁的鉛筆圖示以開啟歷程。

從此區段，您可以定義歷程的名稱、新增說明，以及：

NOTE
若為即時歷程，此畫面只會顯示發佈日期和發佈歷程的使用者名稱。

此 複製技術細節 可讓您複製支援團隊可用於疑難排解的歷程相關技術資訊。 下列資訊已複製： JourneyVersion UID， OrgID， orgName， sandboxName， lastDeployedBy， lastDeployedAt.

進一步瞭解與特定設定檔的歷程相關的技術欄位及其使用方式 在此頁面中.

進入和重新進入 entrance

設定檔專案模式是在歷程層級的右側設定窗格中定義。 設定如下所述。

設定檔入口管理取決於歷程型別。 在中進一步瞭解設定檔進入和重入管理 此頁面.

允許重新進入 allow-re-entrance

依預設，新歷程允許重新進入。 您可以取消勾選 允許重新進入 「單次」歷程的選項，例如，如果您想在某人進入商店時提供一次性禮物。

重新進入等待期 re-entrance-wait

當 允許重新進入 選項已啟用， 重新進入等待期 欄位。 此欄位可讓您定義在允許設定檔在單一歷程中再次進入歷程 (從事件或對象資格開始) 之前等待的時間。 這可防止同一事件多次錯誤觸發歷程。預設情況下，欄位會設為 5 分鐘。 持續時間上限為90天。

管理存取權 manage-access

若要指派自訂或核心資料使用標籤給歷程，請按一下 管理存取權 按鈕。 深入瞭解物件層級存取控制(OLAC)

歷程和設定檔時區 timezone

時區是在歷程層級定義。 您可以輸入固定時區，或使用Adobe Experience Platform設定檔來定義歷程時區。 如果在Adobe Experience Platform設定檔中定義了時區，則可在歷程中擷取該時區。

如需時區管理的詳細資訊，請參閱 此頁面.

開始和結束日期 dates

您可以定義 開始日期. 如果您尚未指定，則會在發佈時自動定義。

您也可以新增 結束日期. 這可讓設定檔在達到日期時自動退出。 如果未指定結束日期，則設定檔可保留至 全域歷程逾時 （通常為91天）。 唯一的例外是循環讀取受眾歷程，具有 在重複時強制重新進入 已啟用，在下一次事件的開始日期結束。

逾時 timeout

歷程活動逾時或錯誤 timeout_and_error

編輯動作或條件活動時，您可以定義替代路徑，以防錯誤或逾時。 如果處理詢問協力廠商系統的活動超過中定義的逾時期間。 逾時或錯誤 歷程屬性的欄位中，將選擇第二個路徑來執行潛在的遞補動作。

授權值介於1到30秒之間。

建議您最好定義一個非常簡短的 逾時或錯誤 值（如果您的歷程有時效性，例如：對個人的即時位置有所反應），因為您的動作無法延遲超過幾秒鐘。 如果您的歷程較不有時效性，您可以使用較長的值，讓系統有更多時間呼叫，以傳送有效回應。

歷程也會使用全域逾時，如下所述。

全域歷程逾時 global_timeout

除了 逾時 在歷程活動中使用，會套用全域歷程逾時。 它不會顯示在介面中，且無法變更。

此全域逾時會停止歷程中個人的進度 91天 在他們進入之後。 這表示個人的歷程不能持續超過91天。 在此逾時期間後，個人的資料會被刪除。 在逾時期間結束時仍在歷程中流動的個人將會停止，且將不會在報表中將其列入考量。 因此，您可能會看到更多人進入歷程而不是退出。

由於91天歷程逾時，當歷程不允許重新進入時，我們無法確保重新進入封鎖將超過91天。 事實上，當我們移除在進入歷程91天後進入歷程之人員的所有相關資訊時，我們無法得知此人之前已進入（超過91天前）。

個人只有在歷程剩餘的時間夠在91天歷程逾時前的等待期間完成時，才能進入等待活動。 請參閱此頁面。

存留時間(TTL)與資料保留常見問題集 timeout-faq

自2024年6月Adobe Journey Optimizer發行版本開始，歷程全域逾時已從30天移動至91天。 影響會列於以下的常見問題集中：

針對單一歷程

TTL擴充功能推出後發佈的歷程會如何？
進入新歷程的設定檔會自動具有91天的TTL。
進入TTL擴充功能啟動前所發佈之歷程的個人資料會發生什麼事？
設定檔的TTL為30天（HIPAA為7天），與歷程的初始發佈時間一致。
啟動TTL擴充功能時，已進入歷程的個人資料會發生什麼事？
根據歷程的原始發佈時間，設定檔將保留30天的TTL （HIPAA為7天）。
在TTL擴充功能啟動後重新發佈的舊版歷程中的設定檔會有什麼改變？
設定檔將維持30天（HIPAA為7天）的TTL，與原始歷程版本的發佈時間一致。
在TTL擴充功能啟動後，新設定檔進入重新發佈的歷程版本會發生什麼事？
設定檔的TTL為91天，符合新重新發佈的歷程版本的TTL。

針對區段觸發歷程

TTL擴充功能之後發佈的新一次性歷程有什麼改變？
進入新歷程的設定檔會自動擁有91天的TTL。
在TTL擴充功能之後發佈的新週期性歷程沒有強制重新進入會怎樣？
進入新歷程的設定檔會自動擁有91天的TTL。
在TTL擴充功能之後發佈的新循環歷程會如何處理，因為會強制重新進入？
進入新歷程的設定檔的TTL將等於週期期間。 例如，如果歷程每日執行，則TTL將為1天。
進入TTL擴充功能啟動前所發佈之歷程的個人資料會發生什麼事？
設定檔的TTL為30天（HIPAA為7天），與原始發佈時間一致。 對於具有強制重新進入的週期性歷程，TTL將符合週期性期間。
啟動TTL擴充功能時，透過歷程執行的設定檔會發生什麼事？
根據歷程的原始發佈時間，設定檔將保留30天的TTL （HIPAA為7天）。 對於具有強制重新進入的週期性歷程，TTL將符合週期性期間。
在TTL擴充功能啟動後重新發佈的先前歷程版本中，執行中的設定檔有何改變？
設定檔將保留30天（HIPPA為7天）的TTL，與原始歷程版本的發佈時間一致。 對於具有強制重新進入的週期性歷程，TTL將符合週期性期間。
在TTL擴充功能啟動後，新設定檔進入重新發佈的歷程版本會發生什麼事？
設定檔的TTL為91天，符合新重新發佈的歷程版本的TTL。 對於具有強制重新進入的週期性歷程，TTL將符合週期性期間。

合併政策 merge-policies

Journey在從Adobe Experience Platform擷取設定檔資料時使用合併原則。 根據歷程型別，會使用不同的合併原則：

  • 在讀取對象或對象資格歷程中：使用來自對象的合併原則
  • 在單一事件歷程中：使用預設合併原則
  • 在業務事件歷程中：使用以下讀取對象活動中來自目標對象的合併原則

歷程將遵循在整個歷程中使用的合併原則。 因此，如果歷程中使用多個對象（例如：「inAudience」函式中），導致歷程使用的合併原則不一致，則會引發錯誤並封鎖發佈。 不過，如果在訊息個人化中使用不一致的對象，則儘管不一致，仍不會引發警報。 因此，強烈建議您在訊息個人化使用此對象時，檢查與對象相關聯的合併原則。

若要深入瞭解合併原則，請參閱 Adobe Experience Platform檔案.

recommendation-more-help
b22c9c5d-9208-48f4-b874-1cefb8df4d76