历程上限和仲裁 journey-capping

在此页面上:​限制一次可输入或注册用户档案的历程数,以便防止通信过载并优先处理最重要的历程。

历程上限可帮助您限制配置文件可注册的历程数,防止通信过载。 在Journey Optimizer中,您可以设置两种类型的上限规则:

  • 条目上限​限制配置文件在给定时间段内的历程条目数。
  • 并发上限​限制可同时注册用户档案的历程数。

这两种类型的历程上限都利用优先级得分来仲裁条目。

➡️ 通过观看视频了解此功能

创建历程频次封顶规则 create-rule

要创建历程上限规则,请执行以下步骤:

  1. 导航到​ 业务规则 ​菜单以访问规则集清单。

  2. 选择要添加上限规则的规则集,或创建新规则集:

    • 要使用现有规则集,请从列表中选择该规则集。 只能将历程上限规则添加到具有“journey”域的规则集。 您可以在​ ​列的规则集列表中检查此信息。

    • 要在新规则集中创建上限规则,请单击​创建规则集,为规则集指定唯一名称并从​ 规则集域 ​下拉列表中选择“历程”,然后单击​保存

  3. 在规则集屏幕中,单击​ 添加规则 ​按钮,然后为规则提供唯一名称。

  4. 在​ 规则类型 ​下拉列表中,指定规则的上限类型。

    • 历程进入次数上限:限制配置文件在给定时间段内进入历程的条目数。
    • 历程并发上限:限制可同时注册用户档案的历程数。

  5. 展开以下部分以了解如何配置每种类型的上限:

    accordion
    配置历程条目上限规则
    1. 在​ 上限 ​字段中,设置配置文件可以输入的最大历程数。
    2. 在​ 持续时间 ​字段中,定义要考虑的时间段。 请注意,持续时间基于UTC时区。 例如,每日上限将在UTC午夜重置。

    在本例中,我们希望限制用户档案在一个月内输入超过“5”个历程。

    note
    NOTE
    系统将考虑应用了此规则的即将计划历程的优先级。
    在本例中,如果营销人员已输入4个历程,并且本月有另一个具有较高优先级的计划历程,则将禁止客户进入较低优先级的历程。
    accordion
    配置历程并发上限规则
    1. 在​ 上限 ​字段中,设置用户档案可以同时注册的最大历程数。

    2. 使用​ 优先级预视 ​字段根据所选时段(例如,1天、7天、30天)内的优先级分数仲裁历程条目。

      此选项会扫描一周剩余时间内即将到来的计划读取受众历程,以确定是否应由于即将出现较高优先级的历程而禁止用户档案进入历程。 如果配置文件符合多个历程的条件,这有助于优先考虑进入价值更高的历程。

    在本例中,我们希望限制已注册到包含相同规则集的另一个历程的用户档案进入历程。 如果未来7天内的另一个历程的优先级分数更高,则用户档案不会进入此历程。

    {width="50%"}

  6. 重复上述步骤,根据需要向规则集添加任意数量的规则。

  7. 当上限规则准备好应用于历程时,激活已添加该规则的规则和规则集。 了解如何激活规则集

将频次封顶规则应用于历程 apply-capping

要将上限规则应用于历程,请访问历程并打开其属性。 在​ 上限规则 ​下拉列表中,选择相关的规则集。 一旦激活历程,规则集中定义的上限规则将生效。

NOTE
如果立即激活历程,则系统可能需要长达10分钟才能开始抑制客户。 因此,如果您尝试发布开始时间小于10分钟的历程,则会显示一条消息。

监控规则集排除项 monitor

一旦旅程处于活动状态,如果规则集导致在​ 历程排除项 ​表中从旅程中排除任何内容,则可以签入旅程报告。 “历程排除项”表包含按规则集和规则名称对排除项的详细细分,提供了有关配置文件被丢弃原因的分析。 了解如何使用历程报告

此外,您可以使用Adobe Experience Platform查询服务来构建查询,以识别导致配置文件无法进入给定历程的规则。 查询示例,包括放弃子原因(CAP_REACHEDLOWER_PRIORITY),在此节中可用。

操作方法视频 video

AI Knowledge Reference

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 create journey capping rules—entry capping and concurrency capping—inside a journey-domain rule set, and how they use priority scores to arbitrate which journeys a profile enters.

Intents:

  • Create a Journey Entry Cap to limit journey entries over a period
  • Create a Journey Concurrency Cap to limit simultaneous journey enrollments
  • Use Prioritization look ahead to arbitrate entries based on priority scores over a chosen period
  • Apply a journey rule set to a journey through the Capping rules drop-down
  • Monitor exclusions in the Journey Exclusions table and with Query Service

Glossary:

  • Entry capping: Limits the number of journey entries over a given period for a profile (product-specific)
  • Concurrency capping: Limits how many journeys a profile can be enrolled in simultaneously (product-specific)
  • Prioritization look ahead: Field that arbitrates journey entries based on priority scores over a chosen period, scanning upcoming scheduled Read-Audience journeys (product-specific)
  • Arbitration: Using priority scores to decide which journeys a profile enters when caps apply (product-specific)
  • Capping: Field setting the maximum number of journeys a profile can enter or be enrolled in simultaneously (product-specific)
  • CAP_REACHED / LOWER_PRIORITY: Discard sub-reasons that identify why a profile did not enter a journey (product-specific)

Guardrails:

  • Journey capping rules can only be added to rule sets with the “journey” domain.
  • Both entry capping and concurrency capping leverage priority scores to arbitrate entries.
  • Durations are based on the UTC time zone (for example, a Daily cap resets at midnight UTC).
  • For entry capping, the system takes into account the priority of upcoming scheduled journeys that have the same rule applied, and can suppress a profile from a lower-priority journey when a higher-priority one is scheduled.
  • If a journey is activated immediately, it can take up to 10 minutes for the system to begin suppressing customers; a message displays if you try to publish with a start time less than 10 minutes away.
  • Providing a priority score of 100 to a journey ensures that it is entered into.

Terminology:

  • Canonical name: journey capping — Acronym: n/a — variants: journey capping & arbitration, journey rule set
  • Synonyms: none
  • Do not confuse: “Journey Entry Cap” (entries over a period) ≠ “Journey Concurrency Cap” (simultaneous enrollments)
  • Do not confuse: “journey capping” (limits journey entries or concurrency) ≠ “channel capping” (limits messages per channel and communication type)
  • Do not confuse: “CAP_REACHED” (a cap was reached) ≠ “LOWER_PRIORITY” (excluded due to a lower priority)

FAQ:

  • Q: What is the difference between entry and concurrency capping? — Entry capping limits journey entries over a period; concurrency capping limits how many journeys a profile is enrolled in simultaneously.
  • Q: How are entries arbitrated when a cap is reached? — By priority scores; the Prioritization look ahead scans upcoming scheduled Read-Audience journeys to suppress entry when a higher-priority journey is coming up.
  • Q: How can I guarantee a journey is entered? — Give it a priority score of 100.
  • Q: Why can suppression be delayed after activation? — If a journey is activated immediately, it can take up to 10 minutes for the system to begin suppressing customers.
  • Q: How do I find why a profile did not enter a journey? — Check the Journey Exclusions table in the journey report, or query the discard sub-reason (CAP_REACHED or LOWER_PRIORITY).
recommendation-more-help
journey-optimizer-help