Compartir por


Usar ID de vinculación para correlacionar entre desencadeadores

Para viaxes baseadas en desencadenamentos e repetitivos, un cliente pode repetir unha viaxe sen completar a carreira anterior. Por exemplo, considere unha viaxe que envía confirmacións e recordatorios de citas. Cando unha persoa se inscribe para a súa primeira cita, entra na viaxe e recibe unha confirmación. Seguirán esperando na viaxe ata que reciban un recordatorio un día antes da cita. Durante este tempo, a mesma persoa podería inscribirse nunha segunda cita. O participante da viaxe iniciará o mesmo percorrido por segunda vez para a segunda cita. Noutras palabras, a mesma persoa atravesa agora dúas instancias da mesma viaxe.

En tal situación, se o participante da viaxe anula algunha das citas, deberá saír só o traxecto asociado á cita anulada. Por exemplo, se anulan a primeira cita, deberán saír do traxecto asociado á primeira cita pero continuar o traxecto asociado á segunda cita. Se está a usar eventos fóra de caixa Dataverse, o comportamento é automático e non se necesita ningunha outra acción. Non obstante, se está a usar desencadenamentos personalizados, debe configurar o gatillo para identificar correctamente a instancia específica da viaxe coa que debe asociarse o gatillo.

Usando o atributo bindingId para identificar de forma única cada instancia da viaxe

Cada desencadenamento personalizado ten un atributo de unión opcional que pode usarse para unir o desencadenamento a instancias específicas dunha viaxe. Cando o atributo vinculante non estea presente, o desencadenamento actuará en todas as instancias da viaxe na que participe a persoa. Por exemplo, se a persoa se rexistrou para dúas citas pero cancela unha, e se o desencadenamento cancelado non usou un vinculanteId, entón esa persoa sairá de ambos os casos da viaxe. Se ten intención de usar desencadenamentos en viaxes repetibles, é moi recomendable que inclúa unha unión no gatillo.

Cando o desencadenamento que inicia unha viaxe contén unha uniónId, ese DNI úsase para identificar a instancia de viaxe. Para identificar a instancia de viaxe, calquera outro evento debe usar a mesma unión. O formato para a uniónId é o seguinte: {entityType}/{entityId} Por exemplo, se o seu evento de inicio é unha entidade de cita chamada Cita confirmada e ten unha entidadeId de "123", sería o vinculanteAppointment/123. O seu evento de saída Cita cancelada debe ser do mesmo tipo de entidade e debe usar o mesmo vinculanteId (Appointment/123) para identificar de forma única a instancia de viaxe.

Se só está a usar desencadenamentos personalizados na viaxe, pode confiar en cadeas únicas para identificar as instancias de viaxe.

Nota

Un desencadenamento personalizado actuará en todas as instancias dunha viaxe na que alguén está participando se falta o vinculanteIdou se a unión é para un tipo de entidade diferente.

Correlacionarse a través de desencadenamentos personalizados e eventos fóra de caixa ou eventos comerciais personalizados

Se desexa usar unha combinación de desencadenamentos personalizados e eventos comerciais fóra de caixa ou personalizados, bindingId usa formato especial para identificar de forma única a táboa e fila Dataverse . Por exemplo, a túa viaxe podería comezar co evento fóra de caixa Opportunity Created. Podería entón usar un desencadenamento personalizado chamado Opportunity Won para o evento de saída. O desencadenamento personalizado de Opportunity Won debe conter unha uniónId que segue o patrón do evento Opportunity Created para identificar de forma única cada instancia.

Sempre que se inicie unha viaxe por un evento de negocios fóra de caixa ou personalizado, cada instancia da viaxe pode identificarse de forma única polo patrón {entityType}/{unique row ID}. Este patrón debe incluírse no atributo vinculante de calquera desencadenamento personalizado para correlacionarse a través de desencadenamentos personalizados e eventos comerciais fóra de caixa ou personalizados.

No caso do desencadenamento personalizado de Opportunity Won , a uniónId podería ser:

  • BindingId = opportunity/{unique ID of the opportunity row}

Se os desencadenamentos personalizados seguen o patrón de bindingId descrito anteriormente, poden usarse para identificar a instancia exacta de viaxe, mesmo cando se usa con outros eventos comerciais. Cando se implementa o vinculante, actúa sobre todos os casos da viaxe.

Nota

A vinculación só funciona nos mesmos tipos de entidades.

Como engadir unha ligazón a un gatillo personalizado

Pode modificar o atributo bindingId no fragmento de código para un desencadenamento personalizado.

Para acceder á fragmento de código para un gatillo personalizado existente:

  1. Vai a Customer Insights - Journeys>Interacción>Activadores.
  2. Seleccione o activador personalizado ao que desexa engadir un bindingId .
  3. Seleccione Ir a fragmento de código.

    Vaia á captura de pantalla fragmento de código.

  4. Copia o fragmento e pégao no editor de código que elixas. Modifica o atributo bindingId seguindo os formatos mencionados anteriormente (unha cadea única se a utilizas só con activadores personalizados ou {table_name}/{unique row ID} cando se correlaciona entre disparadores personalizados e eventos listos para usar ou eventos empresariais personalizados).

Podes seguir os mesmos pasos para engadir un bindingId ao crear un novo disparador personalizado.

bindingId interpretación

O / personaxe está reservado. Sempre se supón que o bindingId está nun / formato separado e eliminarase calquera inicio ou final / . Ademais, non hai / no resultado. A aplicación sempre tenta interpretalo desta {entityType}/{entityId} moda.

Exemplos:

"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"}

Algoritmo de comparación:

[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. 

Exemplos:

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