Jaa


Sitovien tunnusten käyttö herättimien välillä korrelointiin

Käynnistinpohjaisissa, toistettavissa siirtymissä asiakas voi toistaa siirtymän suorittamatta edellistä ajoa loppuun. Esimerkkinä siirtymä, joka lähettää tapaamisvahvistuksia ja muistutuksia. Kun henkilö ilmoittautuu ensimmäiseen tapaamiseensa, hän saapuu siirtymään ja saa vahvistuksen. Henkilö odottaa siirtymässä, kunnes saa muistutuksen päivää ennen tapaamista. Tänä aikana sama henkilö voisi ilmoittautua toiseen tapaamiseen. Siirtymän osallistuja aloittaa saman siirtymän toisen kerran toista tapaamista varten. Toisin sanoen sama henkilö käy nyt läpi kahta saman siirtymän ilmentymää.

Tällaisessa tilanteessa, jos siirtymän osallistuja peruuttaa yhden tapaamisen, hänen tulee poistua vain peruutettuun tapaamiseen liittyvästä siirtymästä. Jos hän esimerkiksi peruuttaa ensimmäisen tapaamisen, hänen on poistuttava ensimmäiseen tapaamiseen liittyvästä siirtymästä, mutta jatkettava toiseen tapaamiseen liittyvässä siirtymässä. Jos käytät käyttövalmiita Dataverse-pohjaisia tapahtumia, toiminta on automaattinen eikä muita toimia tarvita. Jos kuitenkin käytät mukautettuja herättimiä, sinun on määritettävä herätin tunnistamaan siirtymän tietty esiintymä, johon herätin on liitettävä.

Määritteen bindingId käyttäminen siirtymän jokaisen esiintymän yksilölliseen tunnistamiseen

Jokaisella mukautetulla herättimellä on valinnainen bindingId-määrite, jota voidaan käyttää herättimen sitomiseen siirtymän tiettyihin esiintymiin. Kun bindingId-määritettä ei ole, herätin vaikuttaa kaikkiin siirtymän esiintymiin, joihin henkilö osallistuu. Jos henkilö on esimerkiksi rekisteröitynyt kahteen tapaamiseen, mutta peruuttaa yhden, ja peruutettu herätin ei käyttänyt bindingId-määritettä, kyseinen henkilö poistuu siirtymän molemmista esiintymistä. Jos aiot käyttää herättimiä toistettavissa siirtymissä, on hyvin suositeltavaa sisällyttää bindingId herättimeen.

Kun siirtymän käynnistävä herätin sisältää bindingId-määritteen, kyseistä tunnusta käytetään siirtymän esiintymän tunnistamiseen. Siirtymän esiintymän tunnistamiseksi kaikkien muiden tapahtumien tulee käyttää samaa bindingId-määritettä. Määritteen bindingId muoto on seuraava: {entityType}/{entityId}. Jos aloitustapahtuma on esimerkiksi Appointment-entiteetti nimeltä Tapaaminen vahvistettu ja sillä on entiteetin tunnus “123,” bindingId olisi Appointment/123. Poistumistapahtuman Tapaaminen peruutettu tulee olla samaa entiteettityyppiä ja sen tulee käyttää samaa bindingId (Appointment/123) -määritettä, jotta siirtymän esiintymä tunnistetaan yksilöllisesti.

Jos käytät siirtymässä vain mukautettuja herättimiä, voit käyttää yksilöllisiä merkkijonoja siirtymän esiintymien tunnistamiseen.

Huomautus

Mukautettu herätin vaikuttaa siirtymän kaikkiin esiintymiin, joihin joku osallistuu, jos bindingId puuttuu tai jos sidonta on eri entiteettityyppiä varten.

Korreloi mukautettujen herättimien ja valmiiden tapahtumien tai mukautettujen yritystapahtumien välillä

Jos haluat käyttää mukautettujen herättimien ja valmiiden tai mukautettujen liiketoimintatapahtumien yhdistelmää, bindingId käyttää erityistä muotoilua Dataverse-taulukon ja -rivien yksilölliseksi tunnistamiseksi. Siirtymä voi alkaa esimerkiksi valmiilla tapahtumalla Mahdollisuus luotu. Sitten mukautettua herätintä nimeltä Mahdollisuus voitettu voi käyttää poistumistapahtumana. Mukautetussa herättimessä Mahdollisuus voitettu on oltava bindingId, joka seuraa Mahdollisuus luotu -tapahtuman mallia, jotta jokainen esiintymä tunnistetaan yksilöllisesti.

Aina kun siirtymä aloitetaan valmiilla tai mukautetulla liiketoimintatapahtumalla, malli {entityType}/{unique row ID} voi tunnistaa yksilöllisesti siirtymän jokaisen esiintymän. Tämän mallin on oltava kaikkien mukautettujen herättimien bindingId-määritteessä, jotta mukautettujen herättimien ja valmiiden tai mukautettujen liiketoimintatapahtumien välillä voidaan korreloida.

Mukautetussa herättimessä Mahdollisuus voitettubindingId voisi olla:

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

Jos mukautetut herättimet noudattavat yllä kuvattua bindingId-mallia, niitä voi käyttää siirtymän tietyn esiintymän tunnistamiseen, vaikka niitä käytettäisiin muissa liiketoimintatapahtumissa. Kun bindingId on käytössä, se vaikuttaa siirtymän kaikkiin esiintymiin.

Huomautus

Sidonta toimii vain samojen entiteettityyppien välillä.

Määritteen bindingId lisääminen mukautettuun herättimeen

Voit muokata bindingId-määritettä mukautetun herättimen koodikatkelmassa.

Aiemmin luodun mukautetun herättimen koodikatkelman käyttäminen:

  1. Siirry kohtaan Customer Insights - Journeys>Yhteydenotto>Käynnistimet.
  2. Valitse mukautettu herätin, johon haluat lisätä bindingId-määritteen.
  3. Valitse Siirry koodikatkelmaan.

    Näyttökuvassa koodikatkelmaan siirtyminen.

  4. Kopioi katkelma ja liitä se haluamaasi koodieditoriin. Muokkaa bindingId-määritettä yllä mainittujen mallien mukaisesti (yksilöllinen merkkijono, jos käytät sitä vain mukautettujen herättimien tai kohteen {table_name}/{unique row ID} kanssa, kun korreloidaan mukautettujen herättimien ja valmiiden tapahtumien ja mukautettujen liiketoimintatapahtumien välillä).

Voit noudattaa samoja vaiheita, kun lisäät bindingId-määritteen uutta mukautettua herätintä luotaessa.

bindingId-tulkinta

Merkki / on varattu. Aina oletetaan, että bindingId on /-merkin erottelema malli, ja kaikki edeltävät tai perässä olevat /-merkit poistetaan. Myöskään tuloksessa ei ole /-merkkiä. Sovellus yrittää aina tulkita sitä tällä {entityType}/{entityId} tavalla.

Esimerkkejä:

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

Vertailualgoritmi:

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

Esimerkkejä:

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