Salesforce Marketing Cloud

Am heutigen Feature Friday widmen wir uns wieder einmal einem vermeintlich einfachen Thema: den Wait Steps im Journey Builder. Wir haben die Erfahrung gemacht, dass viele User nicht alle Möglichkeiten kennen, die die Salesforce Marketing Cloud hier bietet. Daher stellen wir die Wait Activities noch einmal vor und zeigen auch, wie Wartezeiten für jeden Journey-Kontakt individualisiert werden können.

Wait Until Date

Bei der Warteaktivität Wait Until Date wird ein fester Zeitpunkt festgelegt, zu dem alle Kontakte die Journey fortsetzen. Einstellbar sind Datum und Uhrzeit. Die Wartezeit endet hier für alle Journey-Kontakte zum gleichen Zeitpunkt.

Wait By Duration

Mit dieser Wait Activity kann eine Wartedauer eingestellt werden. Diese kann zwischen wenigen Minuten oder mehreren Monaten liegen. Außerdem kann zusätzlich zur Dauer auch noch eine Uhrzeit festgelegt werden, zu der die Kontakte den Wait Step verlassen. Beispiel: Warte 3 Tage und verlängere die Wartezeit bis 15:00 Uhr.  Endet die dreitägige Wartezeit für einen Kontakt um 16:00 Uhr, wartet er also noch einmal bis zum nächsten Tag, 15:00 Uhr. Auch bei dieser Warteaktivität sind die Einstellungen für alle Kontakte gleich.

Wait by Attribute

Während mit den beiden erstgenannten Wait Steps für alle Journey-Kontakte dieselben Wartezeiten eingestellt werden, bietet die Activity Wait by Attribute eine deutlich größere Flexibilität. Diese Wait Activity greift auf ein Datumsfeld in einer Data Extension zurück; der Kontakt verbleibt in der Wartestufe, bis der Datumswert in diesem Feld erreicht wird. Für jeden Kontakt kann dieses Datum in der Data Extension ein anderes sein – das heißt, dass auch die Wartezeiten bei dieser Activity individuell sind.

Der genaue Zeitpunkt, wann ein Kontakt den Wait Step verlässt, kann weiter konfiguriert werden. Folgende Einstellungen sind möglich:

• Der Kontakt verlässt den Wait Step zu dem Zeitpunkt, wenn der Attributwert erreicht wird. Das Warteintervall kann bis zu einer spezifischen Uhrzeit verlängert werden. Beispiel: Warte bis zu dem Zeitpunkt, der im Datumsfeld „Reminder“ steht und verlängere die Wartezeit bis 09:00 Uhr.
• Der Kontakt verlässt den Wait Step, bevor der Attributwert erreicht wird. Einstellbar sind Tage, Wochen oder Monate, außerdem kann das Warteintervall wieder verlängert werden. Beispiel: Warte bis 7 Tage vor dem Wert im Feld „Geburtstag“ und verlängere die Wartezeit bis 16:00 Uhr.
• Der Kontakt verlässt den Wait Step, nachdem der Attributwert erreicht wurde. Auch hier können wieder Tage, Wochen oder Monate eingestellt werden und die Wartezeit kann bis zu einer bestimmten Uhrzeit verlängert werden. Beispiel: Warte bis 1 Woche nach dem Wert im Feld „Veranstaltungsdatum“ und verlängere die Wartezeit bis 12:00 Uhr.

Der Vorteil dieser Wait Activity liegt auf der Hand: Für jeden Kontakt in der Journey kann ein eigener Datumswert vorliegen, die Wartezeiten sind also individuell. Erstellt man mehrere Datumsfelder in einer Data Extension, kann man auf diese Weise sogar die Wait Steps für eine ganze Journey definieren.

Voraussetzung für die Nutzung dieses Wait Steps ist natürlich, dass die entsprechenden Datumsfelder existieren und mit passenden Daten gepflegt werden. Die Felder müssen sich entweder in einer Data Extension im Kontaktmodell oder aber in den Journey-Daten befinden. Individuelle Daten für jeden Kontakt können beispielweise per SQL berechnet und in die Datumsfelder geschrieben werden.

Sind diese Voraussetzungen erfüllt, bietet die Activity Wait by Attribute hervorragende Möglichkeiten, Wartezeiten in Journeys für jeden Kontakt individuell zu gestalten. Der zeitliche Ablauf einer Journey kann also genauso auf die persönlichen Bedürfnisse eines Kontakts zugeschnitten werden wie Art und Inhalt der Nachrichten, die er erhält.

Unser Fazit: Die Wait Activities im Journey Builder bieten mehr Möglichkeiten, als man denkt! Die Tatsache, dass Wartezeiten auch individuell gestaltet werden können, ist vielen Nutzern nicht bekannt. Es lohnt sich, sich mit diesen Möglichkeiten auseinanderzusetzen – vielleicht werden dadurch Use Cases realisierbar, die man bisher für nicht umsetzbar hielt.

Weiterführende Informationen finden Sie in der Dokumentation