Używanie identyfikatorów powiązań do korelacji między wyzwalaczami

Artykuł
01/30/2024

W przypadku powtarzalnych pozyskań opartych na wyzwalaczu, klient może powtórzyć pozyskania, nie ukończywszy poprzedniej. Na przykład, rozważ podróż, która wysyła potwierdzenia i przypomnienia o spotkaniach. Kiedy osoba rejestruje się na swoje pierwsze spotkanie, wchodzi w podróż i otrzymuje potwierdzenie. Będą nadal czekać w pozyskaniu, aż otrzymają przypomnienie na dzień przed umówionym spotkaniem. W tym czasie ta sama osoba mogła zarejestrować się na drugie spotkanie. Uczestnik podróży wyruszy w to samo pozyskanie po raz drugi na drugie spotkanie. Innymi słowy, ta sama osoba przechodzi teraz przez dwie instancje tego samego pozyskania.

W takiej sytuacji, jeśli uczestnik pozyskania odwoła jedno ze spotkań, powinien opuścić tylko podróż związaną z odwołanym spotkaniem. Na przykład, jeśli odwołają pierwsze spotkanie, powinni zakończyć pozyskanie związane z pierwszym spotkaniem, ale kontynuować pozyskanie związane z drugim spotkaniem. Jeśli używasz gotowych zdarzeń Dataverse, zachowanie jest automatyczne i nie są wymagane żadne inne działania. Jeśli jednak używasz niestandardowych wyzwalaczy, musisz skonfigurować je tak, by poprawnie identyfikowały konkretną instancję pozyskania, z którą ten wyzwalacz ma być związany.

Używanie atrybutu bindingId do jednoznacznej identyfikacji każdego wystąpienia pozyskania

Każdy niestandardowy wyzwalacz ma opcjonalny atrybut bindingId, którego można użyć do powiązania wyzwalacza z określonymi wystąpieniami pozyskania. Gdy atrybut bindingId nie jest obecny, wyzwalacz będzie działał na wszystkich wystąpieniach pozyskania, w której uczestniczy dana osoba. Na przykład, jeśli dana osoba zarejestrowała się na dwa spotkania, ale anuluje jedno, a anulowany wyzwalacz nie użył bindingId, ta osoba opuści oba wystąpienia podróży. Jeśli zamierzasz używać wyzwalaczy w powtarzalnym pozyskaniu, zdecydowanie zaleca się dołączenie do wyzwalacza identyfikatora bindingId.

Gdy wyzwalacz rozpoczynający pozyskanie zawiera identyfikator bindingId, identyfikator ten jest używany do identyfikacji wystąpienia pozyskania. Aby zidentyfikować wystąpienie pozyskania, każde inne zdarzenie powinno używać tego samego bindingId. Format wyrażenia bindingId jest następujący: {entityType}/{entityId}. Na przykład, jeśli twoim zdarzeniem początkowym jest podmiot o nazwie Potwierdzenie spotkania i ma on entityId równy „123”, to bindingId będzie brzmiał Appointment/123. Twoje zdarzenie wyjścia Spotkanie anulowane powinno być tego samego typu encji i powinno używać tego samego bindingId (Appointment/123), aby jednoznacznie zidentyfikować instancję pozyskania.

Jeśli używasz tylko niestandardowych wyzwalaczy w pozyskaniu, możesz polegać na unikalnych łańcuchach do identyfikacji instancji pozyskaniu.

Uwaga

Niestandardowy wyzwalacz będzie działał na wszystkich instancjach pozyskania, w której ktoś uczestniczy, jeśli brakuje bindingId lub jeśli wiązanie dotyczy innego typu encji.

Korelacja pomiędzy niestandardowymi wyzwalaczami i niestandardowymi zdarzeniami lub niestandardowymi zdarzeniami biznesowymi

Jeśli chcesz używać kombinacji własnych wyzwalaczy i domyślnych lub własnych zdarzeń biznesowych, bindingId używa specjalnego formatowania do unikalnej identyfikacji tabeli i wiersza Dataverse. Na przykład Twoja podróż może rozpocząć się od gotowego wydarzenia Stworzona szansa sprzedaży. Następnie możesz użyć niestandardowego wyzwalacza o nazwie Zdobyta szansa sprzedaży dla zdarzenia wyjścia. Wyzwalacz niestandardowy Zdobyta szansa sprzedaży musi zawierać bindingId, który jest zgodny ze wzorem zdarzenia Utworzona szansa sprzedaży, aby jednoznacznie identyfikować każdą instancję.

Za każdym razem, gdy pozyskanie jest rozpoczynane przez standardowe lub niestandardowe zdarzenie biznesowe, każda instancja pozyskania może być jednoznacznie identyfikowana przez wzorzec {entityType}/{unique row ID}. Wzorzec ten musi być zawarty w atrybucie bindingId każdego wyzwalacza niestandardowego, aby skorelować wyzwalacze niestandardowe ze zdarzeniami biznesowymi.

W przypadku niestandardowego wyzwalacza Zrealizowane szanse sprzedaży bindingId może być następujący:

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

Jeśli wyzwalacze niestandardowe są zgodne ze wzorcem bindingId opisanym powyżej, można ich użyć do zidentyfikowania dokładnego wystąpienia pozyskiwania, nawet jeśli są używane z innymi zdarzeniami biznesowymi. Po wdrożeniu bindingId działa on we wszystkich przypadkach pozyskiwania.

Uwaga

Powiązanie działa tylko w tych samych typach encji.

Jak dodać bindingId do wyzwalacza niestandardowego

Atrybut bindingId można zmodyfikować we wstawce kodu dla wyzwalacza niestandardowego.

Aby uzyskać dostęp do kodu wstawki dla istniejącego wyzwalacza niestandardowego:

Przejdź do obszaru Customer Insights - Journeys>Zaangażowanie>Wyzwalacze.
Wybierz niestandardowy wyzwalacz, do którego chcesz dodać bindingId.
Wybierz Przejdź do wstawki kodu.
Skopiuj wstawkę i wklej ją do wybranego edytora kodu. Zmodyfikuj atrybut bindingId zgodnie z formatami wymienionymi powyżej (unikatowy ciąg, jeśli używasz go tylko z wyzwalaczami niestandardowymi lub {table_name}/{unique row ID}podczas korelacji między wyzwalaczami niestandardowymi i zdarzeniami gotowymi do użycia lub niestandardowymi zdarzeniami biznesowymi).

Możesz wykonać te same kroki, aby dodać bindingId podczas tworzenia nowego wyzwalacza niestandardowego.

Interpretacja bindingId

Znak / jest zarezerwowany. Zawsze zakłada się, że bindingId jest w oddzielonym przez / formacie, a wszelkie wiodące lub końcowe / zostaną usunięte. Brak / w wynikach. Aplikacja zawsze stara się zinterpretować w ten sam sposób – {entityType}/{entityId}.

Przykłady:

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

Algorytm porównawczy:

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