使用绑定 ID 跨触发器关联

项目
01/31/2024

对于基于触发器的可重复旅程，客户可以重复旅程而无需完成上一次运行。例如，考虑一个发送约会确认和提醒的旅程。当某人注册第一个约会时，他将进入旅程并收到确认。他将继续在旅途中等待，直到在约会前一天收到提醒。在此期间，同一个人可以注册第二个约会。对于第二个约会，旅程参与者将再次开始相同旅程。换句话说，同一个人现在正在经历同一旅程的两个实例。

在这种情况下，如果旅程参与者取消其中一个约会，他应该只退出与取消的约会关联的旅程。例如，如果他取消第一个约会，他应该会退出与第一个约会关联的旅程，但会继续与第二个约会关联的旅程。如果您使用的是现成的基于 Dataverse 的事件，行为将是自动的，不需要其他操作。但是，如果您使用自定义触发器，则必须配置触发器以正确识别触发器必须与之关联的旅程的特定实例。

使用 bindingId 属性来唯一标识旅程的每个实例

每个自定义触发器都有一个可选的 bindingId 属性，可用于将触发器绑定到旅程的特定实例。当 bindingId 属性不存在时，触发器将作用于该人参与的旅程的所有实例。例如，如果该人员已注册两个约会但取消了一个，如果取消的触发器未使用 bindingId，该人员将退出旅程的两个实例。如果您打算在可重复的旅程中使用触发器，强烈建议您在触发器中包含 bindingId。

当开始旅程的触发器包含 bindingId 时，该 ID 用于标识旅程实例。要标识旅程实例，任何其他事件都应使用相同的 bindingId。 bindingId 的格式如下：{entityType}/{entityId}。例如，如果您的开始事件是一个名为预约已确认的约会实体，它的 entityId 为“123”，bindingId 将为 Appointment/123。您的退出事件预约已取消应具有相同的实体类型，而且应使用相同的 bindingId (Appointment/123) 唯一标识旅程实例。

如果您仅在旅程中使用自定义触发器，可以依靠唯一字符串来标识旅程实例。

备注

如果缺少 bindingId 或绑定针对不同的实体类型，自定义触发器将作用于某人参与的旅程的所有实例。

跨自定义触发器和现成事件或自定义业务事件关联

如果您想要使用自定义触发器和现成或自定义业务事件的组合，bindingId 将使用特殊格式来唯一标识 Dataverse 表和行。例如，您的旅程可以从现成的事件商机已创建开始。然后，您可以为退出事件使用名为赢得商机的自定义触发器。自定义触发器赢得商机必须包含一个采用商机已创建事件的模式的 bindingId 来唯一标识每个实例。

每当旅程由现成或自定义业务事件开始时，旅程的每个实例都可以由模式 {entityType}/{unique row ID} 唯一标识。此模式必须包含在任何自定义触发器的 bindingId 属性中，以关联自定义触发器和现成或自定义业务事件。

对于赢得商机自定义触发器，bindingId 可以是：

bindingId = opportunity/{unique ID of the opportunity row}

如果自定义触发器采用上述 bindingId 模式，它们可用于识别确切的旅程实例，即使与其他业务事件一起使用。当 bindingId 被实现时，它作用于旅程的所有实例。

备注

绑定只对相同实体类型有效。

如何将 bindingId 添加到自定义触发器

您可以在自定义触发器的代码片段中修改 bindingId 属性。

要访问现有自定义触发器的代码片段：

转到Customer Insights - Journeys>交互>触发器。
选择要添加 bindingId 的自定义触发器。
选择转到代码片段。
复制代码片段并将其粘贴到您选择的代码编辑器中。按照上述格式修改 bindingId 属性（如果您仅将其与自定义触发器一起使用，则为唯一字符串，在跨自定义触发器和现成事件或业务事件关联时，则为 {table_name}/{unique row ID}）。

在创建新的自定义触发器时，您可以按照相同的步骤添加 bindingId。

bindingId 解释

保留 / 字符。始终假定 bindingId 采用以 / 分隔的格式，并且任何前导或尾随 / 都被删除。此外，结果中没有 /。应用会始终尝试以此 {entityType}/{entityId} 方式解释它。

示例:

"A/B"
will be interpreted as 
{entityType = "A"}/{entityId = "B"}

"A"
will be interpreted as 
{entityType = ""}/{entityId = "A"}

"A/B/C" 
will be interpreted as 
{entityType = "AB"}/{entityId = "C"}

""
will be interpreted as 
{entityType = ""}/{entityId = ""}

"A/B/"
will be interpreted as 
{entityType = "A"}/{entityId = "B"}

"///A/B////"
will be interpreted as 
{entityType = "A"}/{entityId = "B"}

比较算法：

[Case 0] trigger has bindingId = "", meaning no restriction at all
    Always resume.
[Case 1] entityType matches, and entityId matches:
    Resume.
[Case 2] entityType matches, but entityId doesn't match:
    No resume.
[Case 3] entityType doesn't match trigger:
    It doesn't make sense to apply binding, so we fall back to what we have now and let it resume the journey instance.

示例:

Trigger event: "incident/000"
Resume event: "incident/000"
Result: Case 1 resume

Trigger event: "incident/000"
Resume event: "incident/001"
Result: Case 2 no resume

Trigger event: "incident/000"
Resume event: "opportunity/001"
Result: Case 3 resume

Trigger event: "incident/000"
Resume event: "opportunity/000"
Result: Case 3 resume

Trigger event: "incident/000"
Resume event: "random string"
Result: Case 3 resume

Trigger event: "random string"
Resume event: "random string"
Result: Case 1 resume

Trigger event: "random string 1"
Resume event: "random string 2"
Result: Case 2 no resume

Trigger event: "random string 2"
Resume event: ""
Result: Case 2 no resume

Trigger event: ""
Resume event: ""
Result: Case 0 resume

Trigger event: ""
Resume event: "incident/000"
Result: Case 0 resume

Trigger event: "incident/000"
Resume event: ""
Result: Case 3 resume

通过