Die BPM-Journey erstellen
Die BPM-Journey ist der eigentliche Lebenszyklus, in dem Sie die einzelnen Abschnitte (Schritte) des Lebenszyklus festlegen. Er beginnt immer mit einer BPM in-Komponente statt mit einer Zielgruppe, wie bei anderen Journeys. Auf die BPM in-Komponente folgt eine Reihe von BPM-Statuskomponenten mit den entsprechenden Events (Trigger), die von einem Status zum nächsten wechseln. Wird hier für einen Kontakt ein Status eingetragen, wird eine Mail verschickt.
1. Erstellen Sie eine neue Journey und fügen Sie eine BPM in-Komponente sowie drei BPM-Statuskomponenten hinzu.
2. Wählen Sie in den Eigenschaften der BPM in-Komponente die Zielgruppentabelle aus, für die der Welcome Stream gedacht ist. Wenn Sie "einzelne Benutzer" aktivieren, kann der Kontakt nur einmal zu diesem BPM-Lebenszyklus hinzugefügt werden.
Wenn Sie die Journey speichern, wird eine BPM-tabelle als Profilerweiterung (1:1) zur Zielgruppentabelle erstellt. Ein Datensatz wird für den Kontakt erstellt, wenn er den Welcome Stream über die BPM in-Komponente betritt. Ist diese Option nicht aktiviert, kann der Kontakt dem BPM-Prozess mehrfach hinzugefügt werden. Es werden dann mehrere Datensätze für diesen Kontakt erstellt.
Die BPM-tabelle enthält die Informationen darüber, wann und in welchem Status der Kontakt sich gerade befindet. Das Feld STATEID enthält die ID der für den Kontakt aktuellen BPM-Statuskomponente. Klicken Sie auf die Schaltfläche "1" in der oberen linken Ecke, um die IDs jeder Komponente anzuzeigen (auch Journey "Aktions-IDs") genannt.
Wenn Sie zusätzliche Daten speichern müssen, um sie im BPM-Lebenszyklus zu verwenden, können Sie in der Registerkarte "Felder" ein neues Feld in der BPM-tabelle erstellen. Da dies für unser Beispiel nicht notwendig ist, überspringen wir diesen Schritt.
3. Direkt nachdem die BPM in-Komponente weitergegeben wurde, wird der Kontakt durch das Event "Neuer Datensatz" in den BPM-Status "Erstkontakt" versetzt. Definieren Sie nun die anderen Events für die BPM-Statuskomponente:
- Von Erst- zu Zweitkontakt: 3 Tage später und kein Einkauf
- Von Zweit- zu Drittkontakt: 4 Tage später und kein Einkauf
4. Klicken Sie in den Eigenschaften des BPM-Status Erstkontakt auf die Registerkarte 'Events' und fügen Sie ein neues Event hinzu.
5. Benennen Sie dieses Event mit "+3t und kein Einkauf". Belassen Sie den Typ bei 'Datenprüfung', da wir das erweiterte Profil Produktinformation daraufhin überprüfen müssen, ob der Kontakt bereits einen Einkauf getätigt hat oder nicht. Wählen Sie eine Schaltfläche aus und legen Sie eine Zeitverzögerung von 3 Tagen fest.
6. Klicken Sie auf "Bearbeiten", um den Constraint für die Datenprüfung zu erstellen. Klicken Sie auf "Filter einstellen" und erstellen Sie den folgenden Constraint:
PURCHASEINFO.PURCHASE_COUNT=0 OR PURCHASEINFO.PURCHASE_COUNT Is Empty
HINWEIS: Verwenden Sie beim Definieren von Constraints nur tatsächliche Werte. Im Feld „Prüfen“ wird das Constraint mit der korrekten Syntax angezeigt.
Verwenden Sie keine Funktionen im Feld „Value“, da dies zu einer falschen Syntax führen kann!
Beispiel eines korrekt eingestellten Werts im Constraint-Editor und der erzeugten Constraint-Syntax im Fel „Prüfen“ in den BPM-Zustandseigenschaften:
7. Schließen Sie das Eigenschaftenfenster des BPM-Status und verknüpfen Sie "Erstkontakt" mit "Zweitkontakt" mithilfe des neu erstellten Events "+3t und kein Einkauf".
8. Wiederholen Sie diesen Schritt für die BPM-Statuskomponente "Zweitkontakt", allerdings mit einer Verzögerung von 4 Tagen.
9. Betritt der Kontakt einen neuen Status, wird ihm eine Mail geschickt. Verbinden Sie die drei Mails über "Eintrag" mit den BPM-Statuskomponenten:
- Erstkontakt = Mail Willkommensangebot
- Zweitkontakt = Erinnerung an neue Produkte
- Drittkontakt = Das dürfen Sie nicht verpassen
In diesem Beispiel kann der Kontakt jeden Status nur einmal betreten. In anderen BPM-Lebenszyklen ist es jedoch möglich, dass der Kontakt zu einem Status zurückkehrt, den er bereits verlassen hat. In einem solchen Fall wird die entsprechende Mail jedes Mal wieder versendet, wenn der Kontakt den Status betritt.
10. Stellen Sie eine 'datengesteuerte' Durchführung der Journey alle 60 Minuten ein. Starten Sie nun die Journey. Bei jeder Durchführung, also alle 60 Minuten, werden die Kontakte im BPM-Prozess ausgewertet (Datenprüfungs-Events), um festzustellen, ob der jeweilige Kontaktstatus geändert werden muss.
BPM-Journeys müssen datengesteuert sein, wenn sie Datenprüfungs-Events enthalten. Enthält eine BPM-Journey nur getriggerte oder interaktive Events und wird die ursprüngliche BPM-Journey sofort ausgeführt (z.B. getriggert durch einen API-Aufruf durch eine Input Komponente), wird die Journey auch ausgeführt, wenn sie sich noch 'in Entwicklung' befindet (also noch nicht gestartet wurde). In diesem Beispiel werden keine getriggerten und interaktiven BPM-Status-Events verwendet.
Zurück zu Beispiel 'Willkommensszenario'
