Der Wait-Tile in Customer Insights Journeys hält Kontakte für eine definierte Zeit im Ablauf zurück, bevor sie den nächsten Schritt erreichen. Er kennt zwei Modi: eine feste Dauer ab dem Eintritt in die Kachel oder das Warten bis zu einem konkreten Datum mit Uhrzeit. Beide sind auf maximal 90 Tage begrenzt. Der Unterschied klingt harmlos, entscheidet aber darüber, ob Ihre Nachrichten gleichmäßig ausgeliefert werden oder ob sich bei großen Segmenten ein spürbarer Stau bildet.
Wie der Wait-Tile in Customer Insights Journeys funktioniert
Der Wait-Tile ist eine Bedingungskachel und hält den Kontakt für die eingestellte Wartezeit in der Journey. Microsoft beschreibt in der Dokumentation zu Journey-Aktionen zwei Konfigurationen:
- Feste Dauer: Die Wartezeit beginnt individuell, sobald ein Kontakt die Kachel erreicht, etwa eine Stunde oder ein Tag.
- Warten bis zu einem konkreten Datum mit Uhrzeit: Alle Kontakte warten stattdessen auf denselben Moment. Liegt dieser Zeitpunkt bereits in der Vergangenheit, gehen die Kontakte sofort weiter.
Feste Dauer staffelt, ein festes Datum synchronisiert
Dieser scheinbar kleine Unterschied verändert das Freigabeverhalten grundlegend. Die feste Dauer staffelt die Kontakte automatisch: Wer um zehn Uhr eintritt und einen Tag wartet, wird am nächsten Tag um zehn Uhr freigegeben, wer um elf Uhr eintritt, entsprechend eine Stunde später.
Das feste Datum dagegen synchronisiert alle auf eine einzige Sekunde. Genau hier liegt die Ursache für Verzögerungen bei großen Mengen.
Warum ein fixer Zeitpunkt bei großen Segmenten einen Stau erzeugt
Wenn zehntausende Kontakte auf denselben festen Zeitpunkt warten, wollen sie in dem Augenblick alle gleichzeitig in den nächsten Schritt. Meist ist das ein Versand über E-Mail, SMS oder Push. Die Zustellung hinter der Journey kann jedoch nur eine begrenzte Menge pro Zeiteinheit abarbeiten. Aus dem synchronen Schub wird deshalb eine Warteschlange: Die ersten Empfänger erhalten ihre Nachricht pünktlich, die letzten mit spürbarem Verzug. Wer eine Nachricht auf exakt neun Uhr terminiert, sollte nicht davon ausgehen, dass jeder Kontakt sie um neun Uhr im Postfach hat.
Ein Rechenbeispiel
Ein einfaches Rechenbeispiel macht den Effekt greifbar. Nehmen wir an, ein Segment mit 100.000 Kontakten wartet auf denselben festen Zeitpunkt und die effektive Verarbeitung schafft eine gewisse Menge Nachrichten pro Minute. Alle 100.000 wollen zur selben Sekunde losgeschickt werden, doch abgearbeitet wird die Schlange nur nach und nach. Die Spanne zwischen der ersten und der letzten Zustellung wächst mit der Segmentgröße. Bei einer relativen Wartezeit tritt derselbe Verteiler dagegen über Minuten oder Stunden verteilt in die Kachel ein, und genau so gestaffelt verlässt er sie wieder.
Warum eine relative Wartezeit den Durchsatz glättet
Die relative Wartezeit vermeidet das Problem also konstruktiv. Weil jeder Kontakt seine eigene Uhr ab dem Eintritt startet, verteilt sich die Freigabe automatisch über dasselbe Zeitfenster, in dem die Kontakte in die Journey eingetreten sind. Der Durchsatz bleibt geglättet, ohne dass Sie etwas zusätzlich konfigurieren müssen. Ein fixer Zeitpunkt ist damit vor allem für kleine, zeitkritische Segmente geeignet, während große Verteilungen von einer gestaffelten Freigabe profitieren.
Zeitzonen und der eine Moment
Ein festes Datum mit Uhrzeit ist ein einziger globaler Moment und wird nicht pro Empfänger in dessen Ortszeit umgerechnet. Für einen internationalen Verteiler bedeutet das: Neun Uhr sind nicht überall neun Uhr am Morgen. Wollen Sie in der lokalen Morgenzeit jedes Kontakts zustellen, braucht es eine Datumsangabe im auslösenden Trigger oder ein Terminfeld, auf das sich die Wartezeit relativ bezieht, etwa einen Tag vor einem Termin. Wie sich solche kanalübergreifenden Abläufe sauber steuern lassen, zeigt unser Leitfaden zur Multichannel-Journey-Orchestrierung in Dynamics 365 Marketing.
Statisches Warten gegen dynamische Bedingungen
Ein Wait-Tile ist immer dann richtig, wenn die Wartezeit vom Kalender abhängt und von nichts sonst. Sobald die nächste Aktion von einem Kundenverhalten oder einem Ereignis abhängen soll, sind dynamische Bedingungen die bessere Wahl. Customer Insights Journeys bietet dafür zwei Bausteine, die oft mit dem festen Warten verwechselt werden.
Der Wait-for-trigger-Branch
Der Wait-for-trigger-Branch, wegen seiner Logik auch If/Then-Branch genannt, wartet innerhalb eines definierten Zeitfensters darauf, dass eine Aktion eintritt, und verzweigt anschließend in einen Ja- und einen Nein-Pfad. Tritt die Aktion ein, etwa das Öffnen einer E-Mail, geht der Kontakt sofort in den Ja-Pfad. Bleibt sie aus, wechselt er nach Ablauf der Frist in den Nein-Pfad. Es gibt drei Bedingungstypen: das Warten auf eine Interaktion mit einer vorherigen Nachricht, ein Trigger-Attribut zu einem bestimmten Zeitpunkt oder das Warten, bis ein Kontakt Mitglied eines dynamischen Segments wird.
Der Attribut-Branch
Der Attribut-Branch arbeitet grundverschieden. Er wartet nie, sondern liest im Moment des Eintritts einen Wert aus dem Profil, der Segmentmitgliedschaft oder einem Trigger und leitet den Kontakt sofort weiter. Microsoft grenzt beide in der Dokumentation Attribut- versus If/Then-Branch klar ab: Attribut-Branches eignen sich für Dinge, die bereits geschehen sind und im Profil stehen, If/Then-Branches für ein erwartetes Verhalten. Anders als der Zweiwege-Trigger erlaubt der Attribut-Branch zudem mehrere Ausgänge zugleich.
| Kriterium | Wait-Tile (fest) | Wait for trigger | Attribut-Branch |
|---|---|---|---|
| Wartet | Ja, feste Zeit oder Datum | Ja, bis zur Aktion oder Frist | Nein |
| Auslöser | Kalender | Kundenaktion oder Ereignis | Vorhandener Wert |
| Ausgänge | Einer | Ja und Nein | Mehrere möglich |
| Freigabe bei großer Menge | Gestaffelt bei Dauer, gebündelt bei Datum | Individuell pro Kontakt | Sofort beim Eintritt |
| Typischer Zweck | Feste Pause im Ablauf | Follow-up, Erinnerung | Personalisierung nach Profil |
Journeys für eine gleichmäßige Zustellung bauen
Aus dem Verhalten der Kacheln ergeben sich ein paar klare Regeln für die Praxis:
- Relative Wartezeit als Standard: In den meisten Onboarding- und Nurturing-Strecken genügt der Abstand zwischen zwei Schritten. Das staffelt die Freigabe von selbst und hält den Durchsatz ruhig.
- Fester Zeitpunkt nur mit Puffer: Planen Sie zeitgebundene Sendungen nie auf die letzte Minute und entzerren Sie sehr große Mengen zusätzlich.
- Verhalten gehört in einen Branch: Reagiert der Ablauf auf eine Aktion, ersetzt ein Wait-for-trigger-Branch das feste Warten und erzeugt gar keinen synchronen Schub.
Fester Zeitpunkt: mit Puffer planen
Ist ein fester Zeitpunkt fachlich zwingend, etwa eine Ankündigung zur Messeeröffnung, dann planen Sie ihn nicht auf die letzte Minute. Ein Puffer vor dem Wunschtermin gibt der Zustellung Zeit, den Schub abzuarbeiten, sodass auch die letzten Empfänger im gewünschten Fenster liegen. Für zeitkritische Sendungen an sehr große Segmente lohnt es sich, die Menge über eine Audience-Split-Kachel oder gestaffelte Eintrittszeiten zu entzerren, statt alles auf einen Moment zu legen.
Verhaltensbasierte Strecken statt starrem Kalender
Reagiert Ihr Ablauf auf Verhalten, ersetzen Sie das feste Warten durch einen Wait-for-trigger-Branch. Er verzweigt jeden Kontakt individuell und erzeugt gar keinen synchronen Schub. Wer solche verhaltensbasierten Strecken erst aufbaut, findet die Grundlagen im Beitrag zu Dynamics 365 Marketing und Lead-Management. Und wer noch Journeys aus dem alten Modul überträgt, sollte die veränderte Warten-Logik früh einplanen, wie im Leitfaden zum Umstieg von Outbound-Marketing auf Real-Time beschrieben.
Der wichtigste Grundsatz bleibt einfach: Eine feste Zeit gehört in den Wait-Tile, eine feste Uhrzeit nur in kleine Segmente, und alles, was von Verhalten oder Profil abhängt, in einen Branch. Wenn Sie unsicher sind, wie Ihre Journeys skalieren und wo statisches Warten zum Engpass wird, sprechen Sie uns an. Wir prüfen Ihre Abläufe und bauen sie so, dass die Zustellung auch bei großen Mengen gleichmäßig läuft.
Häufig gestellte Fragen
Was ist der Unterschied zwischen fester Dauer und Warten bis zu einem Datum im Wait-Tile?
Bei fester Dauer startet die Wartezeit individuell, sobald ein Kontakt die Kachel erreicht. Zwei Kontakte, die im Abstand von einer Stunde eintreten, werden auch im Abstand von einer Stunde freigegeben. Beim Warten bis zu einem konkreten Datum mit Uhrzeit warten dagegen alle Kontakte auf denselben Moment und werden dann gemeinsam freigegeben. Liegt das Datum bereits in der Vergangenheit, gehen die Kontakte sofort zum nächsten Schritt weiter.
Warum verzögert ein Wait-Tile mit festem Zeitpunkt die Zustellung bei großen Segmenten?
Weil die Freigabe nicht gestaffelt, sondern synchron ist. Wenn zehntausende Kontakte auf denselben Zeitpunkt warten, wollen sie alle in derselben Sekunde in den nächsten Schritt, meist einen Versand. Die dahinterliegende Zustellung kann nur eine bestimmte Menge pro Zeiteinheit abarbeiten, also bildet sich eine Warteschlange. Die ersten Empfänger bekommen die Nachricht pünktlich, die letzten mit spürbarer Verzögerung.
Wann sollte ich Warten bis Bedingung erfüllt statt einer festen Wartezeit nutzen?
Immer dann, wenn die nächste Aktion von einem Kundenverhalten oder einem Ereignis abhängt und nicht von einem starren Kalender. Der Wait-for-trigger-Tile wartet innerhalb eines Zeitfensters auf eine Aktion wie das Öffnen einer E-Mail und verzweigt in einen Ja- und einen Nein-Pfad. Das ist die richtige Wahl für Follow-ups, Erinnerungen und Reaktionen auf konkrete Interaktionen.
Berücksichtigt der Wait-Tile die Zeitzone des Empfängers?
Ein festes Datum mit Uhrzeit ist ein einziger Moment und wird nicht pro Empfänger in dessen Ortszeit umgerechnet. Wer eine Nachricht in der lokalen Morgenzeit jedes Kontakts zustellen will, braucht dafür eine Datumsangabe im auslösenden Trigger oder ein Terminfeld, auf das sich eine relative Wartezeit bezieht, etwa einen Tag vor dem Termin.
Was ist der Unterschied zwischen Wait for trigger und einem Attribut-Branch?
Der Wait-for-trigger-Branch wartet über eine definierte Dauer darauf, dass eine Aktion eintritt, und unterstützt eine einfache Zweiwege-Verzweigung in Ja und Nein. Der Attribut-Branch wartet nicht. Er prüft im Moment des Eintritts einen Wert aus dem Profil, der Segmentmitgliedschaft oder einem Trigger und erlaubt mehrere Ausgänge zugleich.
Wie hoch ist die maximale Wartezeit eines Wait-Tiles?
Die maximale Wartezeit beträgt 90 Tage beziehungsweise 12 Wochen. Diese Grenze gilt gleichermaßen für die feste Dauer und für das Warten bis zu einem konkreten Datum. Längere Pausen lassen sich nicht in einer einzelnen Kachel abbilden und müssen anders modelliert werden.
Sie haben Fragen zu Dynamics 365?
Wir haben die Antworten.
Vereinbaren Sie einfach ein unverbindliches Erstgespräch mit einem Dynamics-Experten.
Termin vereinbaren
