Del via


Brug af bindings-id'er til at korrelere på tværs af udløsere

I forbindelse med udløserbaserede kampagneforløb kan en kunde gentage et kampagneforløb uden at have fuldført det forrige forløb. Overvej f.eks. at et kampagneforløb sender aftalebekræftelser og påmindelser. Når en person tilmelder sig sin første aftale, deltager vedkommende i kampagneforløbet og modtager en bekræftelse. De vil blive ved med at vente i kampagneforløbet, indtil de modtager en påmindelse en dag før aftalen. I samme tidsrum kunne den samme person tilmelde sig endnu en aftale. Deltageren i kampagneforløbet starter det samme kampagneforløb igen ved den anden aftale. Med andre ord gennemgår den samme person nu to forekomster af samme kampagneforløb.

Hvis deltageren i et kampagneforløb i denne situation annullerer en af aftalerne i denne situation, bør vedkommende kun afslutte det kampagneforløb, der er knyttet til den annullerede aftale. Hvis de f.eks. annullerer den første aftale, bør de afslutte det kampagneforløb, der er knyttet til den første aftale, men fortsætte med det kampagneforløb, der er knyttet til den anden aftale. Hvis du bruger standardbaserede Dataverse-arrangementer, er funktionsmåden automatisk, og der kræves ikke yderligere handlinger. Men hvis du bruger brugerdefinerede udløsere, skal du konfigurere udløseren til korrekt at identificere den specifikke forekomst af det kampagneforløb, som udløseren skal knyttes til.

Brug attributten bindingId til entydig identifikation af hver forekomst af kampagneforløbet

Alle brugerdefinerede udløsere har en valgfri bindingId-attribut, der kan bruges til at binde udløseren til bestemte forekomster af et kampagneforløb. Når attributten bindingId ikke findes, virker udløseren på alle forekomster af det kampagneforløb, som personen deltager i. Hvis personen f.eks. har tilmeldt sig to aftaler, men annullerer én, og hvis den annullerede udløser ikke har brugt et bindingId, afslutter vedkommende begge forekomster af kampagneforløbet. Hvis du vil bruge udløsere i tilbagevendende kampagneforløb, anbefales det, at du medtager et bindingId i udløseren.

Når den udløser, der starter et kampagneforløb, indeholder et bindingId, bruges id'et til at identificere forekomsten af kampagneforløbet. Andre hændelser bør bruge det samme bindingId til at identificere forekomsten af et kampagneforløb. Formatet for bindingId er som følger: {entityType}/{entityId}. Hvis starthændelsen f.eks. er et aftaleobjekt, der kaldes Aftale bekræftet, og det har et objekt-id på "123", vil bindingId være Appointment/123. Afslutningshændelsen Aftale annulleret bør derfor være af samme objekttype og bør bruge samme bindingId (Appointment/123) til entydigt at identificere kampagneforløbsforekomsten.

Hvis du kun bruger brugerdefinerede udløsere i kampagneforløbet, kan du bruge entydige strenge til at identificere kampagneforløbsforekomster.

Bemærk

En brugerdefineret udløser fungerer på alle kampagneforløbsforekomster, som en person deltager i, hvis bindingId mangler, eller hvis bindingen gælder for en anden objekttype.

Korreler på tværs af brugerdefinerede udløsere og standardhændelser eller brugerdefinerede forretningshændelser

Hvis du vil bruge en kombination af brugerdefinerede udløsere og standardhændelser eller brugerdefinerede forretningshændelser, bruger bindingId særlig formatering til entydigt at identificere Dataverse-tabellen og -rækken. Dit kampagneforløb kan f.eks. starte med den standardhændelsen Salgsmulighed oprettet. Du kan derefter bruge en brugerdefineret udløser, der kaldes Salgsmulighed vundet, til afslutningshændelsen. Den brugerdefinerede udløser Salgsmulighed vundet skal indeholde et bindingId, der følger mønsteret for hændelsen Salgsmulighed oprettet, for at identificere de enkelte forekomster entydigt.

Når et kampagneforløb startes af en standardhændelse eller en brugerdefineret forretningshændelse, kan hver forekomst af kampagneforløbet entydigt identificere af mønstret {entityType}/{unique row ID}. Dette mønster skal inkluderes i attributten bindingId i en brugerdefineret udløser for at korrelere på tværs af brugerdefinerede udløsere og standardhændelser eller brugerdefinerede forretningshændelser.

I tilfælde af den brugerdefinerede udløser Salgsmulighed vundet kan bindingId være:

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

Hvis brugerdefinerede udløsere følger det bindingId-mønster, der er beskrevet ovenfor, kan de bruges til at identificere den nøjagtige forekomst af kampagneforløbet, selv når de bruges sammen med andre forretningshændelser. Når bindingId implementeres, sker det på alle forekomster af kampagneforløbet.

Bemærk

Bindingen fungerer kun på tværs af de samme objekttyper.

Sådan tilføjes et bindingId til en brugerdefineret udløser

Du kan ændre attributten bindingId i kodestykket i en brugerdefineret udløser.

Sådan får du adgang til kodestykket i en eksisterende brugerdefineret udløser:

  1. Gå til Customer Insights - Journeys>Engagement>udløsere.
  2. Vælg den brugerdefinerede udløser, som du vil tilføje et bindingId til.
  3. Vælg Gå til kodestykke.

    Skærmbillede af Gå til kodestykke.

  4. Kopiér kodestykket og indsæt den i en kodeeditor efter eget valg. Rediger attributten bindingId i overensstemmelse med de formater, der er nævnt ovenfor (en entydig streng, hvis du kun bruger den med brugerdefinerede udløsere, eller {table_name}/{unique row ID}, når du korrelerer på tværs af brugerdefinerede udløsere og standardhændelser eller brugerdefinerede forretningshændelser).

Du kan følge de samme trin for at tilføje et bindingId, når du opretter en ny brugerdefineret udløser.

Fortolkning af bindingId

Tegnet / er reserveret. Det antages altid, at bindingId er i et / adskilt format, og eventuelle foranstillede eller efterfølgende / fjernes. Der er endvidere ingen / i resultatet. Appen forsøger altid at fortolke det på denne {entityType}/{entityId} måde.

Eksempler:

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

Algoritme til sammenligning:

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

Eksempler:

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