在此頁面上:檢閱 Adobe Journey Optimizer 的系統、歷程、客群、管道和內容限制,以便規劃可擴充的部署,而不會發生失敗。
當使用 Adobe Journey Optimizer 時,您將找到下列護欄和限制。
權益、產品限制和效能護欄全都列於 Adobe Journey Optimizer 產品說明頁面上。
-
即時客戶輪廓資料、分段的護欄也適用於 Adobe Journey Optimizer。
-
另請參閱即時客戶設定檔中資料攝取的護欄
系統與平台 system-platform
支援的瀏覽器 browsers
Adobe Journey Optimizer 介面的設計可在最新版 Google Chrome 中以最佳方式運作。 您在舊版或其他瀏覽器上使用某些功能時可能會遇到問題。
資料集護欄 datasets-guardrails
自 2025 年 2 月起,將在 新沙箱和新組織 中,向 Journey Optimizer 系統產生的資料集,開放使用存留時間 (TTL) 護欄功能,如下所示:
- 輪廓存放區中的資料為 90 天
- 資料湖中的資料為 13 個月
此變更將從 2026 年 10 月 1 日 開始,強制在 現有客戶沙箱 中執行。 進一步瞭解資料集存留時間 (TTL) 護欄
歷程 journeys-guardrails
本節涵蓋歷程的護欄和限制,包括一般歷程限制、歷程元件 (動作、事件、資料來源)、歷程活動以及自訂動作和運算式編輯器等特定功能。
一般歷程護欄 journeys-guardrails-journeys
-
歷程中的活動數限定為最多 50 個。 活動數會顯示於歷程畫布的左上方區段。
由於歷程接近此限制,編輯和發佈效能可能會降低,並且可能會發生儲存或驗證失敗。 如果發生此情況,請使用跳轉活動將您的歷程分割為較小的子歷程,或在新版本中重新建立歷程。 無法增加活動限制。
-
可同時處於作用中狀態的即時、關閉、暫停和試運行歷程數量,在生產沙箱中的上限為 200 個,開發沙箱中的上限為 100 個。 此限制會在您發佈歷程時強制執行。 目前的歷程數目會顯示在歷程畫布上方。
當您發佈歷程時,我們會自動縮放和調整,以確保輸送量與穩定性達到最高。 已關閉的歷程只有在此護欄推出後建立才計算在內。
-
在歷程中使用客群資格篩選時,該客群資格篩選活動最多可能需要 10 分鐘,才會啟用和接聽進入或退出客群的輪廓。
-
輪廓的歷程執行個體大小上限為 1 MB。 在歷程執行過程中收集的所有資料都會儲存在該歷程執行個體中。 因此,來自傳入事件的資料、從 Adobe Experience Platform 擷取的輪廓資訊、自訂動作回應等會儲存在該歷程執行個體中,並影響歷程大小。 當歷程以事件開始時,建議限制該事件承載的大小上限 (例如:低於 800 KB),以避免在歷程執行中經過幾項活動後達到該限制。 此800 KB指南不適用於業務事件或單一事件,其受以下所述的更嚴格64 KB限制的約束。 當達到1 MB限制時,設定檔處於錯誤狀態並將從歷程中排除。
-
任何開始或進入歷程的事件(包括商業事件和單一事件)都必須遵守額外、更嚴格的護欄:事件承載上限為64 KB的未壓縮縮制JSON。 超過此大小的事件會遭到捨棄,而不會觸發歷程。 這與上述1 MB歷程執行個體限制不同,也更嚴格。 進一步瞭解如何設定商業活動。
-
對於每個輪廓和歷程版本,歷程執行階段會保留最多 10 個待處理事件的內部佇列,同時處理一個事件。 如果達到此限制,則會出於
maxInstanceStackEventsReached原則捨棄其他事件,直到堆疊耗盡為止。 檢視由於封鎖歷程執行個體而捨棄的事件。 -
除了歷程活動中使用的逾時之外,還有一個不會顯示在介面且無法變更的全域歷程逾時。 此全域逾時會在個人進入歷程 91 天後停止其進度。 閱讀更多
歷程承載大小驗證 journey-payload-size
當您儲存或發佈歷程時,Journey Optimizer會驗證序列化歷程定義的大小,以保留穩定性和效能。 有效負載大小是以位元組為單位測量,而非僅由活動數量決定。 每個活動會根據其儲存的設定做出貢獻,包括運算式、條件、資料對應、引數和其他設定值。
常見貢獻者包括:
- 具有複雜運算式的條件活動。
- 含有許多欄位或深度巢狀運算式的自訂動作活動。
- 大型資料對應。
- 具有大量引數或設定的活動。
沒有固定的每個活動大小值。 具有相同活動數的兩個歷程根據其設定而定,可能會有不同的裝載大小。 當顯示警告或錯誤時,請檢閱訊息中識別出貢獻最大的活動。
預設設定
- 預設歷程承載大小上限: 2 MB (2,000,000位元組)。 某些組織可能有 Adobe 設定的自訂限制。
- 警告臨界值:上限的 90%。
- 錯誤臨界值:上限的 100%。
疑難排解與建議
- 檢閱在警告或錯誤中反白顯示貢獻最大的活動。
- 簡化複雜的運算式和條件、減少資料對應,以及移除不必要的欄位或引數。
- 如有需要,請考慮將歷程分割為較小的歷程。
- 如果您認為您的組織需要更高的限制,請聯絡您的 Adobe 代表。
若要在發佈之前監視您歷程的目前承載大小,請使用歷程屬性面板中的 目前歷程承載大小 指標。 瞭解如何檢查您的歷程承載大小
序列化的歷程裝載包含歷程活動的設定。 參照的實體(例如電子郵件動作參照的電子郵件內容)不會包含在此裝載中。 電子郵件內容在電子郵件護欄區段中受個別郵件內容大小的護欄限制。
授權套件比較 select-package-limitations
對於使用 Select 授權套件的客戶,下列額外限制尤其適用於單一歷程 (以事件或客群資格鑑定開始的歷程):
ERR_PKG_SELECT_8ERR_PKG_SELECT_7ERR_PKG_SELECT_6ERR_PKG_SELECT_2歷程版本 journey-versions-g
下列防護措施適用於歷程版本:
- 在 v1 中以事件活動開始的歷程,在後續版本中也不能以事件以外的項目開始。 您無法透過 客群資格篩選 事件開始歷程。
- 在 v1 中以 客群資格篩選 活動開始的歷程,在後續版本中必須一律以 客群資格篩選 開始。
- 在「客群鑑定」 (第一個活動) 中所選擇的客群與命名空間,無法在新版本中變更。
- 所有歷程版本中的重新進入規則必須相同。
- 以 讀取客群 開始的歷程在後續版本中無法以另一個事件開始。
- 您無法建立使用增量讀取方式的新讀取客群歷程版本。 您必須重複歷程。
歷程與輪廓建立 journeys-limitation-profile-creation
在 Adobe Experience Platform 中建立/更新以 API 為基礎的輪廓會有延遲。 對於第 95 個百分位數的請求,服務層級目標 (SLT) 從擷取到統一輪廓的延遲時間小於 1 分鐘,每秒請求量為 20K (RPS)。
如果在建立輪廓的同時觸發歷程,並立即從輪廓服務檢查/擷取資訊,則可能無法正常運作。
您可以從以下兩種解決方案中選擇一種:
-
在第一個事件後新增等待活動,為 Adobe Experience Platform 提供執行攝取至輪廓服務所需的時間。
-
設定不會立即善用輪廓的歷程。 例如,如果歷程的設計是要確認帳戶的建立,則體驗事件可能包含傳送第一個確認訊息 (名字、姓氏、電子郵件地址等) 所需的資訊。
活動 events-g
下列防護措施適用於您旅程的事件:
- 在所有沙箱中,Journey Optimizer 單一事件的傳入歷程事件尖峰量支援每秒 5,000 個傳入歷程事件,而基於「讀取客群」的歷程事件同樣支援每秒 5,000 個傳入歷程事件。 請在此頁面深入了解此限制。
- 事件觸發的歷程最多可能需要 5 分鐘來處理歷程的第一個動作。
- 對於系統產生的事件,必須先在 Journey Optimizer 中設定用於啟動客戶歷程的串流資料,才能取得唯一的協調流程 ID。 此協調流程 ID 必須附加至傳入 Adobe Experience Platform 的串流裝載。 此限制不適用於規則型事件。
- 業務事件不能與單一事件或客群資格篩選活動結合使用。
- 在全部即時、已關閉、已暫停、測試模式和試運行歷程中,單一事件在任何時間最多僅能由 25 個歷程所參考。 當達到此限制時,將封鎖發佈任何使用該事件的其他歷程。
- 在所有即時、已關閉、已暫停、測試模式和試運行歷程中,單一 XDM 結構描述一次最多可由 100 個事件所參考。 當達到此限制時,將封鎖發佈任何包含參考該結構描述的事件節點的歷程。
- 單一歷程 (從事件或客群資格篩選開始) 包含可防止同一事件多次錯誤觸發歷程的護欄。 在預設情況下,輪廓重新進入時會暫時封鎖 5 分鐘。 例如,如果某個事件在 12:01 觸發了特定設定檔的歷程,而另一個事件在 12:03 到達 (無論是相同事件,或是觸發相同歷程的不同事件),則此輪廓的歷程將不會再次開始。
- Journey Optimizer 需將事件串流至資料彙集核心服務 (DCCS),才能觸發歷程。 批次擷取的事件、透過 查詢服務 插入的事件,或來自內部 Journey Optimizer 資料集的事件 (訊息意見回饋、電子郵件追蹤等等) 不能用於觸發歷程。 對於無法取得串流事件的使用案例,請根據這些事件建置對象,然後改為使用 讀取對象 活動。 技術上可使用客群資格篩選,但不建議使用,因為它可能會根據所使用的操作導致下游挑戰。
資料來源 data-sources-g
下列防護措施適用於您旅程的資料來源:
- 可在客戶歷程中利用外部資料來源即時查詢外部資料。 這些來源必須可透過 REST API 使用、支援 JSON 並且能夠處理大量請求。
- 內部 Adobe 地址 (
.adobe.*) 不允許在 URL 及 API 中使用。
一般動作 general-actions-g
下列防護措施適用於您旅程的行動:
自訂動作 custom-actions-g
下列防護措施適用於您旅程的自訂動作:
- 為每個主機和每個沙箱的所有自訂動作,定義 1 分鐘內 300,000 次呼叫的上限。 此上限會針對回應時間少於 0.75 秒的端點,強制作為每個沙箱和每個端點的滑動視窗。 對於回應時間超過 0.75 秒的端點,適用另外的 每 30 秒 150,000 次呼叫 的限制 (也是滑動視窗)。
- 自訂動作 URL 不支援動態參數。
- 支援 POST、PUT 和 GET 呼叫方法。
- 查詢參數或標題的名稱不得以「.」開頭 或「$」。
- URL 中不允許使用 IP 位址。 請使用主機名稱。
- 內部 Adobe 地址 (
.adobe.*) 不允許在 URL 及 API 中使用。 - 無法移除內建自訂動作。
- 自訂動作僅在使用請求或回應裝載時支援 JSON 格式。 請參閱此頁面。
- 自訂動作的任何目標端點必須支援至少 200 TPS。 請留意,節流設定不可低於 200 TPS。 根據預期輸送量,高回應時間可能會影響實際輸送量。
補充識別碼 supplemental
特定護欄適用於在歷程中使用補充識別碼。 它們會在本頁面中列出。
運算式編輯器 expression-editor
下列護欄適用於歷程運算式編輯器:
- 從讀取客群、客群資格篩選或商業事件活動開始的歷程中,無法使用體驗事件欄位群組。 您必須建立新的客群,才能在歷程中使用
inaudience條件。 - 無法在運算式編輯器中使用
timeSeriesEvents屬性。 若想在設定檔等級存取體驗事件,請根據XDM ExperienceEvent結構描述建立新的欄位群組。
歷程活動 activities
客群資格鑑定活動 audience-qualif-g
下列護欄適用於「客群鑑定」歷程活動:
- 客群資格篩選活動無法與 Adobe Campaign 活動搭配使用。
- 客群資格鑑定歷程不支援補充識別碼。
- 在所有即時、已關閉、已暫停、測試模式和試運行歷程中,沙箱最多可包含 300 個「客群鑑定」活動。 此限制也適用於用作退出條件的「客群鑑定」活動。 當達到此限制時,會封鎖發佈包含其他「客群鑑定」活動的歷程。
在本節中深入了解歷程處理速率和輸送量限制。
其他護欄 (包括串流與批次客群的建議以及構成客群限制) 列於此頁面。
行銷活動 ac-g
下列護欄適用於 Campaign v7/v8 和 Campaign Standard 活動:
- Adobe Campaign 活動不能與讀取客群或客群資格篩選活動搭配使用。
- Campaign Standard 活動不能與其他管道活動搭配使用:卡片、程式碼型體驗、電子郵件、推播、簡訊、應用程式內訊息、網頁。
- Campaign v7/v8 活動可與同一歷程中的原生管道活動搭配使用。
回應事件 reaction-events-g
特定護欄適用於 回應 事件,包括必須在管道動作後立即放置活動,以及無法追蹤不同歷程中傳送的訊息。 它們會列出於此頁面。
應用程式內活動 in-app-activity-limitations
下列護欄適用於 應用程式內訊息 動作。 請在此頁面深入了解有關應用程式內訊息的更多資訊。
-
此功能目前不適用於醫療保健客戶。
-
個人化只能包含輪廓屬性。
-
應用程式內活動無法搭配 Campaign Standard 活動使用。
-
應用程式內顯示會繫結至歷程期限,這表示當輪廓的歷程結束時,該歷程中的所有應用程式內訊息都將不再顯示給該輪廓。 因此,無法直接從歷程活動停止應用程式內訊息。 而是必須結束整個歷程,才能停止將應用程式內訊息顯示給輪廓。
-
在測試模式中,應用程式內顯示取決於歷程的有效期限。 為避免歷程在測試期間過早結束,請調整 等待 活動的 等待時間 值。
-
回應活動無法用於對應用程式內開啟或點按做出反應。
-
啟動延遲可能發生在使用者輪廓到達畫布中的應用程式內活動的時刻和他們開始看到該應用程式內訊息的時刻之間。
-
應用程式內訊息內容大小限制為 2 MB。 包含大型影像可能會阻礙發佈過程。
內容決策活動 content-decision-g
特定護欄適用於 內容決策 活動,包括更新的同意原則在決策原則中生效之前的 48 小時延遲。 它們會列出於此頁面。
跳轉活動 jump-g
特定護欄適用於 跳轉 活動。 它們會列出於此頁面。
讀取客群活動 read-segment-g
下列護欄適用於讀取對象歷程活動:
- 串流客群一律為最新狀態,但擷取時不會計算批次客群。 它們僅在每日批次評估時間每天進行評估。
- 在進入歷程時,輪廓會使用批次客群快照中的屬性值。 但是,當輪廓達到 等待 活動時,歷程會透過從統一輪廓服務 (UPS) 擷取最新資料來自動重新整理輪廓屬性。 這表示在歷程執行期間,輪廓屬性可能會變更。
- 讀取客群活動無法搭配 Adobe Campaign 活動使用。
- 讀取客群活動只能作為歷程中的第一個活動,或商業事件活動後的第一個活動。
- 歷程只能有一個 讀取客群 活動。
- 讀取客群活動在每個歷程中只能鎖定一個客群。 如果需要多個客群,請先將這些客群合併為單一客群。 瞭解如何使用構成工作流程合併客群。
- 每個組織在所有沙箱和歷程中最多可同時執行 五個 讀取客群 執行個體 (已排程或已觸發業務事件)。 避免同時開始超過五個具有 讀取客群 的歷程;讓它們相隔 5 到 10 分鐘。 在本節中深入了解歷程處理速率。
- 沙箱輸送量:系統管理每個沙箱的處理,在所有 讀取客群 活動中每秒最多共用 20,000 個輪廓。 個別活動可設定為每秒 500 至 20,000 個輪廓。 如果達到沙箱限制,工作可能會排入佇列。
- 工作處理逾時:無法於 12 小時內處理的 讀取客群 工作會自動清除,且不會執行。
- 擷取匯出工作時,預設會對客群觸發的歷程套用重試。 如果在匯出工作建立期間發生錯誤,將每隔 10 分鐘進行重試,最長為 1 小時。 之後,該歷程會被視為失敗,因此最多可在排程時間後的 1小 時內執行。
- 對於使用補充識別碼的歷程,每個歷程執行個體的 讀取客群 活動讀取速率限制為每秒最多 500 個輪廓。
另請參閱讀取客群活動的建議與設定。
更新輪廓活動 update-profile-g
特定護欄套用於 更新輪廓 活動。 它們會列出於此頁面。
歷程暫停 pause-g
特定護欄適用於暫停歷程,包括組織中所有暫停歷程的最長暫停期間 14 天和 10,000,000 個輪廓上限。 它們會列出於此頁面。
歷程試運行 dry-run-g
特定護欄適用於歷程試運行,包括計算可互動的輪廓和即時歷程配額。 它們會列出於此頁面。
歷程片段 fragments-journey-g
特定護欄適用於歷程片段,包括每個片段最多 20 個節點,以及每個沙箱最多 200 個作用中片段。 它們會列出於此頁面。
使用波段傳送 waves-g
特定護欄適用於歷程中的波段傳送,包括 2-10 波段範圍以及波段之間的 30 分鐘最小間隔。 它們會列出於此頁面。
歷程模擬 simulation-g
特定護欄適用於歷程模擬。 它們會列出於此頁面。
客群和輪廓 audiences-profiles
本節涵蓋客群管理、輪廓處理和可互動輪廓考量事項的護欄。
客群和輪廓護欄 audience
管道與傳訊 channel-guardrails
本節涵蓋所有通訊管道的護欄,包括電子郵件、簡訊、傳入管道 (網頁、應用程式內、程式碼型、內容卡) 和交易型訊息。
電子郵件護欄 message-guardrails
下列防護措施適用於電子郵件頻道:
-
您無法使用相同的傳送網域從Adobe Journey Optimizer和其他產品 (例如Adobe Campaign或Adobe Marketo Engage) 傳送電子郵件訊息。
-
在設計電子郵件訊息時,系統會檢查關鍵設定並顯示警告 (建議和最佳做法) 和錯誤 (封鎖會阻礙測試或啟用的問題) 的警示。 在本節中進一步了解電子郵件警示和驗證需求。
歷程發佈的訊息內容大小 message-content-size
發佈包含電子郵件訊息的歷程時,後端處理後的訊息內容大小總計不得超過 2 MB。 在發佈期間,系統會透過修補連結、影像和套用轉換來自動處理訊息內容,這會增加承載大小,超過編寫的內容大小。
此大小限制也適用於處理完整電子郵件裝載的其他後端作業,例如多語言內容管理中的複製到其他地區設定。 即使您僅在不同地區設定之間複製內容,作業仍會序列化及處理完整的電子郵件裝載,因此可能會失敗,並出現相同大小的錯誤。
防止失敗的最佳實務:
- 將編寫的電子郵件內容保持在 1 MB 以下
- 將內容變化版本的數量減到最少
- 在將影像新增至訊息之前,請先最佳化及壓縮影像
- 移除未使用的資產及不必要的 HTML 元素
- 在將歷程發佈到生產環境之前測試訊息大小
- 將內容複製到多個地區設定時,請一次複製到較少的地區設定,以減少處理額外負荷
如果由於內容大小而導致發佈或復製作業失敗,請減少訊息內容,然後再試一次。
SMS 護欄 sms-guardrails
下列防護措施適用於 SMS 頻道:
- MMS 適用的媒體檔案可透過支援的 URL 加入。 請確定媒體檔案已個別上傳。
- 訊息回饋同步目前不適用於 MMS。
- 同意管理在 MMS 的 SMS 管道層級運作。
傳入頻道護欄 inbound-guardrails
-
若要在 Journey Optimizer 中使用程式碼型體驗動作,並傳送您的應用程式可以使用的程式碼內容承載,請遵循此頁面詳述的先決條件。
-
若要使用 Journey Optimizer 在歷程與行銷活動中傳送應用程式內訊息,請遵循此頁面上列出的傳遞先決條件。
-
若要讓 Adobe Journey Optimizer 正確顯示內容卡,您必須設定此頁面上列出的 Adobe Experience Platform 設定。
-
Journey Optimizer 支援 每秒 5,000 個傳入請求 的尖峰量。 此護欄適用於所有傳入請求,這些請求可源自任何 Journey Optimizer 支援的傳入頻道 (網頁、應用程式內、程式碼型體驗、內容卡)。
-
Journey Optimizer 在任何時間支援最多 500 個作用中的傳入動作。 這些傳入動作若是即時行銷活動的一部分,或為即時歷程中使用的節點,則會計算在內。 達到此數目後,您必須停用使用傳入動作的舊版行銷活動或歷程,才能啟動新行銷活動或歷程。
傳入管道的輪廓管理 profile-management-inbound
Journey Optimizer傳入管道可鎖定假名輪廓,這表示輪廓尚未驗證或還處於未知狀態,因為它們之前從未在其他管道上有過互動。 例如,當根據類似 ECID 的臨時 ID 來鎖定所有訪客或客群時,就會發生這種情況。
這樣做會增加可互動輪廓總數,如果其超過您購買的可互動輪廓合約數量,可能會影響成本。 各個套件的授權量度都列在 Journey Optimizer 產品說明頁面上。 您可以在授權使用儀表板中檢查可互動輪廓的數量。
為了將您的可互動輪廓保持在合理限制內,Adobe 建議設定存留時間 (TTL),以在指定時間範圍內未看到假名輪廓或未與之互動時,自動從即時客戶輪廓中刪除該輪廓。 Adobe 建議將 TTL 值設為 14 天,以符合目前的 Edge 輪廓 TTL。
交易型訊息護欄 transactional-message-guardrails
Journey Optimizer 在行銷活動中支援 每秒 500 則交易型訊息 的尖峰量。
子網域護欄 subdomain-guardrails
本頁詳細說明了套用至 Journey Optimizer 子網域委派的護欄和限制。
內容與資產 content-assets
本節涵蓋內容建立與管理的護欄,包括登入頁面與片段。
內容製作護欄 content-authoring
建議的內容型別大小限制如下:
當內容變體超過其建議的大小臨界值時,會顯示警告。 這適用於所有內容型別和管道,且不會阻礙儲存或發佈。
「產生內容」護欄 ai-assistant-g
「產生內容」的護欄與限制,包括支援的管道 (電子郵件、推播、網頁、簡訊) 和個人化編輯器限制,均列於此頁面。
登陸頁面護欄 lp-guardrails
下列防護措施適用於登陸頁面:
- 一個主頁面只能使用一個 表單 元件。
- 此 表單 元件無法在子頁面中使用。
- 您無法將預覽文字新增至登陸頁面。
- 在設計登陸主要頁面時,您無法選取 自行編碼 選項。
片段護欄 fragments-guardrails
下列防護措施適用於片段:
-
若要建立、編輯、封存和發佈片段,您需要 Content Library Manager 產品設定檔中包含的 Manage library items 和 [發佈片段] 權限。 了解更多
-
視覺片段僅可用於電子郵件管道。
-
運算式片段不適用於應用程式內管道。
-
片段不能超過700 KB。 若要維持在此臨界值以下,請將大型內容分割為多個可重複使用的片段、減少大量標籤,並最佳化連結資產。
-
片段計數限制:在編寫期間會驗證內容片段中所使用的不重複片段數目。 僅計算直接引用的片段(包括AEM片段) — 巢狀在其他片段中的片段不會單獨計算。
- 每個變體:每個內容變體最多60個獨特片段。 當使用量達到45 (達到限制的75%)時會顯示警告;發佈在60時會遭到封鎖。
- 跨變體:單一訊息的所有變體最多有120個不重複片段。 當使用量達到90 (達到限制的75%)時會顯示警告;發佈在120時會遭到封鎖。
-
若要在歷程或行銷活動中使用片段,它現在必須處於 即時 狀態。
-
片段中不支援內容屬性。
-
視覺片段在使用主題和手動樣式模式之間不相容。 為了能夠在您想要套用主題的內容中使用片段,此片段必須在使用主題模式中建立。 進一步了解主題
-
在歷程或行銷活動中啟用追蹤時,如果您將連結新增至片段,且此片段用於訊息中,則這些連結會像訊息中包含的所有其他連結一樣受到追蹤。 進一步了解連結和追蹤
決策管理 decision-management
決策與決策管理護欄 decisioning-guardrails
決策和決策管理部分詳細說明了使用決策或決策管理時需要牢記的護欄與限制:
行銷活動協調 campaign-orchestration
行銷活動協調護欄 orchestration-guardrails
本節詳細說明使用行銷活動協調時要牢記的護欄和限制:護欄和限制。
This section contains structured knowledge intended to support interpretation, retrieval, and question answering related to this topic.
For complete understanding, this information should be combined with the documentation on this page. Neither source is intended to stand alone; the page describes the feature, while this section provides additional context that helps disambiguate terminology, intent, applicability, and constraints.
- TL;DR: This page lists the system, journey, audience, channel, and content guardrails and limitations of Journey Optimizer, including numeric limits and their scopes, so you can plan deployments that scale without hitting failures.
Intents:
- Plan journeys within the activity limit and the concurrent journey limits per sandbox type
- Size event payloads and journey instances within their limits
- Configure custom actions and Read Audience activities within their throughput and concurrency limits
- Keep email, in-app, inbound, and content assets within their size and volume limits
- Understand which limits are hard (enforced) versus recommended
Glossary:
- Journey instance: The per-profile store of all data gathered during journey execution, which has a maximum size of 1 MB (product-specific)
- Unitary journey: A journey starting with an event or an audience qualification, subject to specific Select package limitations (product-specific)
- Dry run: A journey type that counts toward the engageable profile and live journey quotas and is counted in several publication-time guardrail scopes (product-specific)
- Test mode: A journey state counted in several publication-time guardrail scopes (for events, XDM schemas, and Audience Qualification activities) (product-specific)
- Engageable profile: A profile counted toward your contractual engageable profile count, which pseudonymous inbound profiles can increase (product-specific)
Guardrails:
- Datasets Time-To-Live guardrail: 90 days for data in the profile store and 13 months for data in the data lake, rolled out to new sandboxes and new organizations as of February 2025 and enforced on existing customer sandboxes starting October 1, 2026.
- The number of activities in a journey is limited to 50; this activity limit cannot be increased (hard limit).
- The number of live, closed, paused, and dry run journeys active at one time is limited to 200 in production sandboxes and 100 in development sandboxes (hard limit, enforced when you publish a journey).
- A journey instance for a profile has a maximum size of 1 MB (hard limit); it is advised to limit an event payload below 800 KB (recommended); business events and unitary events are subject to a stricter 64 KB limit.
- Any event that starts or enters a journey is limited to a maximum of 64 KB of uncompressed, minified JSON (hard limit); events exceeding this size are dropped and do not trigger the journey.
- The journey runtime keeps an internal queue of up to 10 pending events per profile and journey version; additional events are discarded with the
maxInstanceStackEventsReachedreason. - A global journey timeout stops the progress of individuals 91 days after they enter; it is not displayed in the interface and cannot be changed (hard limit).
- Journey payload size validation uses a default maximum journey payload size of 2 MB (2,000,000 bytes); the size reflects the serialized journey definition (activity configuration, expressions, conditions, data mappings, parameters) and is not determined by activity count alone; referenced entities such as email content are excluded. A soft warning is shown at 90 to 99 percent of the limit, and at 100 percent or more save or publish is blocked with HTTP 413 Request Entity Too Large (hard limit).
- Events throughput: peak volume of 5,000 inbound journey events per second for unitary events and 5,000 inbound journey events per second for Read Audience based journey events, across all sandboxes.
- A single event can be referenced by a maximum of 25 journeys, and a single XDM schema by a maximum of 100 events, across all live, closed, paused, test mode, and dry run journeys at one time (hard limit; publishing is blocked when reached).
- Profile reentrance into unitary journeys is temporally blocked by default for 5 minutes.
- Custom actions capping: 300,000 calls over one minute per host and per sandbox for endpoints with response times under 0.75 seconds (default cap, sliding window — raisable via the Capping or Throttling APIs); a separate 150,000 calls per 30 seconds applies to endpoints over 0.75 seconds; any targeted endpoint must support at least 200 TPS and throttling cannot go below 200 TPS.
- A sandbox can include a maximum of 300 Audience Qualification activities across all live, closed, paused, test mode, and dry run journeys (hard limit; publishing is blocked when reached).
- You can publish up to 10 audience compositions in a given sandbox.
- Read Audience: each organization can run up to five Read Audience instances concurrently across all sandboxes and journeys; sandbox throughput is a maximum of 20,000 profiles per second shared across all Read Audience activities (individual activities configurable from 500 to 20,000 profiles per second); jobs not processed within 12 hours are cleaned up and will not execute; for supplemental IDs the reading rate is limited to a maximum of 500 profiles per second.
- In-app message content size is limited to 2 MB (hard limit).
- Email message content for journey publication must not exceed 2 MB after backend processing (hard limit; the operation fails); keep authored content well below 2 MB, ideally under 1 MB, to allow a 300 to 400 KB buffer (recommended).
- Inbound: peak volume of 5,000 inbound requests per second across all inbound channels, and a maximum of 500 active inbound actions at any moment in time (hard limit).
- Transactional messages: peak volume of 500 transactional messages per second in campaigns.
- Content authoring recommended size limits: Template 1200 KB, Fragment 700 KB, Message 1200 KB, Landing page 1000 KB (recommended); a warning is surfaced when a variant exceeds its threshold but it does not block saving or publishing.
- Fragments cannot exceed 700 KB (hard limit); up to 60 unique fragments per content variant (warning at 45, publishing blocked at 60) and up to 120 across all variants of a single message (warning at 90, publishing blocked at 120); a fragment must be in Live status to be used.
- For pseudonymous inbound profiles, Adobe recommends setting a Time-To-Live of 14 days to match the current Edge profile TTL (recommended).
Terminology:
- Canonical name: Guardrails and limitations — variants: guardrails, limits
- TPS: transactions per second — RPS: requests per second
- Do not confuse: “production sandboxes” (limit of 200 concurrent live, closed, paused, and dry run journeys) ≠ “development sandboxes” (limit of 100)
- Do not confuse: journey status scope “live, closed, paused, and dry run” (the 200/100 concurrent journey limit) ≠ “live, closed, paused, test mode, and dry run” (the event, XDM schema, and Audience Qualification limits)
- Do not confuse: 1 MB journey instance limit ≠ 64 KB event payload limit ≠ 2 MB journey payload (serialized journey definition) limit ≠ 2 MB email message content limit
FAQ:
- Q: Can the 50-activity journey limit be increased? — No; the activity limit cannot be increased. If you approach it, split the journey into smaller sub-journeys using jump activities or recreate it in a new version.
- Q: How many journeys can be active at one time? — Up to 200 live, closed, paused, and dry run journeys in production sandboxes and 100 in development sandboxes, enforced when you publish.
- Q: What is the maximum event payload size? — Any event that starts or enters a journey is limited to 64 KB of uncompressed, minified JSON; events exceeding this size are dropped and do not trigger the journey.
- Q: What is the custom action call cap? — 300,000 calls over one minute per host and per sandbox for endpoints under 0.75 seconds, or 150,000 calls per 30 seconds for endpoints over 0.75 seconds.
- Q: What are the size limits for email content when publishing journeys? — The processed message content must not exceed 2 MB after backend processing or the operation fails; keep authored content ideally under 1 MB to leave a 300 to 400 KB buffer.
- Q: How many Read Audience instances can run concurrently? — Each organization can run up to five Read Audience instances concurrently across all sandboxes and journeys, with a sandbox throughput maximum of 20,000 profiles per second shared across all Read Audience activities.