在此頁面上：瞭解如何使用自訂動作和外部資料來源來限制歷程處理，以便外部系統不會超出其支援的每秒要求數目。
當外部系統必須處理限定數量的每秒請求時，使用此使用案例可限制歷程處理。
使用案例的說明
Adobe Journey Optimizer可讓從業人員透過使用自訂動作和資料來源，將API呼叫傳送至外部系統。
您可以透過完成以下操作：
-
資料來源：從外部系統收集資訊，並將其用於歷程內容，例如，取得有關設定檔城市的天氣資訊，並據此建立專屬的歷程流程。
-
自訂動作：傳送資訊給外部系統，例如，使用Journey Optimizer的協調功能以及設定檔資訊、對象資料和歷程內容，透過外部解決方案傳送電子郵件。
如果您使用外部資料來源或自訂動作，您可能會想要透過限制歷程輸送量來保護外部系統：單一歷程每秒最多5,000個例項，對象觸發的歷程每秒最多20,000個例項。 在本節中進一步瞭解歷程處理速率和輸送量。
對於自訂動作，可在產品層級使用節流功能。 請參見此頁面。
對於外部資料來源，您可以在端點層級定義上限限制，以避免透過Journey Optimizer的上限API壓倒這些外部系統。 不過，達到限制之後會捨棄所有剩餘的請求。 在本節中，您將找到可用來最佳化輸送量的因應措施。
如需有關如何與外部系統整合的詳細資訊，請參閱此頁面。
實作
針對受眾觸發的歷程，您可以定義讀取受眾活動的讀取率，此讀取率將影響歷程輸送量。 閱讀全文
您可以將此值從每秒500個執行個體修改為每秒20,000個執行個體。 如果您需要低於500/s，您還可以新增包含等待活動的「百分比分割」條件，以將您的歷程分割成多個分支，並在特定時間執行這些分支。
讓我們以 受眾觸發的歷程 為例，此歷程使用10,000個設定檔的母體，並將資料傳送到支援 100個要求/秒 的外部系統。
-
您可以以500個設定檔/秒的輸送量定義讀取對象以讀取設定檔，這表示讀取所有設定檔將需要20秒。 在第1頁，您會閱讀其中500本、第2頁500本等等。
-
然後，您可以新增「百分比分割」條件活動（採用20%分割），以便每個分支中每秒有100個設定檔。
-
之後，使用每個分支中的特定計時器新增「等待」活動。 我們在這裡設定30秒等候每一個。 每秒鐘有100個設定檔流入每個分支。
-
在分支1上，它們將等待30秒，這表示：
- 在第二個1,100個設定檔將等待第二個31
- 在第二個2,100個設定檔將等待第二個32等。
-
在分支2上，則會等待60秒，這表示：
- 在第二個1,100個設定檔將等待第二個61 （1英尺1英吋）
- 在第二個2,100個設定檔將等待第二個62 （1英尺2英吋）等。
-
知道我們預計最多需要20秒來讀取所有設定檔，每個分支之間將不會重疊，第二個20是設定檔將流入條件的最後一個。 在第二個31和第二個51之間，將處理分支1中的所有設定檔。 在第二個61 （1’01英吋）和第二個81 （1’21英吋）之間，將處理分支2中的所有設定檔等。
-
作為護欄，您還可以新增第六個分支，使每個分支少於100個設定檔，特別是如果您的外部系統僅支援100個請求/秒。
-
作為額外的護欄，您也可以使用「上限」功能。
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 explains how to limit journey throughput when external data sources or custom actions have a capped number of requests per second, using Read Audience rate configuration, percentage splits, and wait activities.
Intents:
- Limit the throughput of an audience-triggered journey to protect an external system from being overwhelmed
- Configure the reading rate of a Read Audience activity to control how many profiles enter per second
- Combine percentage split conditions and wait activities to spread profile processing over time
- Understand the difference between journey-level throughput workarounds and sandbox-level capping capabilities
- Apply capping capabilities to custom actions at the product level
Glossary:
- Throttling / throughput limiting: Controlling the rate at which profiles flow through a journey to avoid exceeding the request capacity of an external system. (product-specific)
- Read Audience reading rate: A configurable parameter on the Read Audience activity that sets the maximum number of profiles entering the journey per second (range: 500–20,000 instances/second). (product-specific)
- Capping API: A Journey Optimizer API that defines a maximum request limit per endpoint for external data sources; requests beyond the cap are dropped. (product-specific)
- Percentage split condition: A condition activity that divides the profile flow into branches by percentage, used here to distribute profiles across time-staggered wait paths. (product-specific)
Guardrails:
- Read Audience reading rate can be set between 500 and 20,000 instances per second; values below 500/s require a workaround using percentage splits and wait activities
- Unitary journeys support up to 5,000 instances/second; audience-triggered journeys support up to 20,000 instances/second
- The percentage-split + wait workaround operates only at journey level, not across all journeys in the sandbox
- When multiple journeys target the same external endpoint in parallel, this workaround does not account for the combined load — capping capabilities should be used instead
- Remaining requests that exceed the capping limit on external data sources are dropped, not queued
- The workaround must be thoroughly tested before going to production
Terminology:
- Canonical name: Throughput limiting — Acronym: none — variants: throttling, rate limiting, journey throughput control
- Synonyms: “Capping” = “throttling” in the context of external endpoint protection
- Do not confuse: “Capping API (endpoint-level)” ≠ “reading rate (journey-level)” — The Capping API applies globally to all journeys in a sandbox targeting an endpoint; the reading rate and split/wait workaround apply only to the individual journey
FAQ:
- Q: What is the maximum reading rate I can set on a Read Audience activity? — Between 500 and 20,000 profiles per second; to go below 500/s, use a percentage split with wait activities.
- Q: How do percentage splits and wait activities help limit throughput? — By splitting profiles into branches (e.g., 20% each) and adding staggered wait timers per branch, you ensure that only a controlled number of profiles reach the external system per second.
- Q: Does the percentage-split workaround protect all journeys targeting the same endpoint? — No; it only works at the individual journey level. If multiple journeys run in parallel against the same endpoint, use sandbox-level Capping capabilities instead.
- Q: What happens to requests that exceed the capping limit on an external data source? — They are dropped; the Capping API does not queue excess requests.
- Q: Should I use custom actions or data sources for external data use cases? — Custom actions are preferred because they support response handling; data sources should be used only when the use case specifically requires them.