Trigger ausführen: Zeitplan, Vorschau und Ausführungsprotokoll

Sobald Ihre Trigger-Regeln eingerichtet sind, findet sich alles rund um deren Ausführung im Tab Delivery. Dieser Artikel behandelt den täglichen Zeitplan, manuelle Läufe und Einzelmitglied-Tests, die Schutzmechanismen Quiet hours und Frequenzobergrenzen, die Funktionsweise der Vorschau sowie die vollständige Referenz des Ausführungsprotokolls einschließlich Spalten, Statuswerten und Backend-Skip-Gründen.

Contents

• Zeitplan und Ausführung
• Quiet hours und Frequenzobergrenzen
• Die vollständige Eignungskette
• Vorschau
• Referenz des Ausführungsprotokolls
• Spalten
• Statuswerte
• Backend-Skip-Gründe

Zeitplan und Ausführung

Alles rund um die Ausführung von Triggern findet sich im Tab Delivery: der tägliche Zeitplan, Quiet hours, Frequenzobergrenzen und das Panel Execute Triggers. Einige Elemente innerhalb des Tabs behalten die Bezeichnung Execution (zum Beispiel Execution Results, Execution Run und Executed At).

Der Tab Delivery: täglicher Zeitplan, Quiet hours, Frequenzobergrenzen und manuelle Läufe an einer Stelle.

Täglicher Zeitplan

• Legen Sie eine Uhrzeit und eine Zeitzone an der Konfiguration fest und schalten Sie den Zeitplan ein oder aus.
• Der Zeitplan wird von allen Studios geteilt, die die Konfiguration nutzen.
• Der Scheduler prüft jede Minute auf fällige Konfigurationen und führt alle aktiven Regeln für alle angeschlossenen Studios aus.
• Eine Regel läuft am selben Kalendertag nicht zweimal (in der lokalen Zeitzone des Studios). Wenn eine Regel heute bereits gelaufen ist, ob automatisch oder manuell, wird sie nicht erneut ausgeführt.

Manueller Lauf ("Run now")

• Führt die Regel sofort für das aktuelle Studio aus. Dabei werden echte Nachrichten gesendet. Für eine gesendete Nachricht gibt es kein Rückgängigmachen.
• Ein manueller Lauf steht für sich: Er dedupliziert nicht gegen andere Regeln des täglichen Laufs.
• Wenn die Regel heute bereits gelaufen ist (automatisch oder manuell), wird der manuelle Lauf blockiert, um doppelte Nachrichten zu verhindern.

Test with single member (Test mit einem einzelnen Mitglied)

• Führt die Regel gegen ein bestimmtes, von Ihnen gewähltes Mitglied aus.
• Sie wählen das Mitglied über dessen Customer ID, nicht über die Mitgliedsnummer. Kopieren Sie diese aus dem Profil des Mitglieds: Öffnen Sie das Profil und nehmen Sie die Nummer aus der Seiten-URL, zum Beispiel bedeutet .../#/customermanagement/1562839240/overview Customer ID 1562839240.
• Umgeht den Bedingungsabgleich: Das Mitglied wird verarbeitet, unabhängig davon, ob es auf die Bedingungen passt.
• Versendet stets als Group A, ohne das Mitglied in einen Control-Bucket zu sperren, sodass der Test nie stillschweigend in der Kontrollgruppe landet.
• Nutzen Sie dies, um Kanaleinrichtung und Vorlagen vor dem Aktivieren einer Regel durchgängig zu überprüfen.

Quiet hours und Frequenzobergrenzen

Zwei der Nachrichten-Schutzmechanismen sind globale Einstellungen, konfiguriert im Tab Delivery und geteilt von allen an die Konfiguration angeschlossenen Studios. (Die anderen beiden Schutzmechanismen, der Cooldown pro Regel und der Dedup bei Mehrfachtreffern, werden in Trigger-Regeln erstellen und bearbeiten behandelt.)

Ruhezeiten. Legen Sie eine Start- und eine Endzeit in der Zeitzone des Studios fest. Über-Nacht-Bereiche funktionieren (22:00 bis 07:00 überspannt Mitternacht). Quiet hours sind deaktiviert, wenn nur eine der beiden Zeiten gesetzt ist oder wenn Start und Ende identisch sind.

Was während der Quiet hours passiert. Nachrichten, die fällig werden, während das Fenster geöffnet ist, werden nicht verworfen: Sie werden in die Warteschlange gestellt und gesendet, sobald das Quiet-hours-Fenster für den Versand öffnet (das heißt, sobald das Fenster endet). Der Trigger-Editor warnt Sie, wenn eine konfigurierte Ausführungszeit in ein aktives Quiet-hours-Fenster fällt, und das Panel für den täglichen Zeitplan zeigt dieselbe Warnung für den täglichen Lauf. Ereignisgesteuerte Lead-Trigger (der New-Lead welcome) unterliegen nicht den Quiet hours und werden sofort gesendet.

Reihenfolge der Schutzmechanismen. Für jeden Lauf werden die Schutzmechanismen in einer festen Reihenfolge ausgewertet: Quiet hours, dann die Tagesobergrenze, dann die Wochenobergrenze, dann der Cooldown pro Regel.

Tägliche und wöchentliche Frequenzobergrenzen. Rollierende Limits pro Mitglied: eine maximale Anzahl von Engage-Nachrichten pro Tag (rollierendes 24-Stunden-Fenster) und pro Woche (rollierendes 7-Tage-Fenster). Jede Obergrenze hat ihren eigenen Ein/Aus-Schalter im Tab Delivery. Wenn ein Mitglied eine Obergrenze bereits erreicht hat, werden weitere Nachrichten übersprungen.

Die Obergrenzen gelten global pro Mitglied über alle Engage-Trigger hinweg, nicht pro Trigger gezählt, sodass ein Mitglied, das früher im Fenster bereits eine Nachricht von einer anderen Regel erhalten hat, aus dieser herausfallen kann. Ein Lauf zählt als eine Nachricht, auch wenn sie auf mehreren Kanälen hinausgeht. Die Fenster sind rollierend (die letzten 24 Stunden und die letzten 7 Tage), nicht Kalendertage oder -wochen.

Siehe auch: Trigger-Regeln erstellen und bearbeiten (Nachrichten-Schutzmechanismen, Priorität und Auflösung mehrfacher Treffer).

Die vollständige Eignungskette

Ein Mitglied kann auf jede von Ihnen geschriebene Bedingung passen und dennoch nichts erhalten, weil Bedingungen nur ein Schritt sind. Für jeden Lauf wendet Engage diese Kette der Reihe nach an:

1. Zielgruppe — aktives Mitglied, ehemaliges Mitglied oder Lead.
2. Kommunikationsstopp — Mitglieder, die widersprochen haben (keine Newsletter-Einwilligung), werden entfernt.
3. Vertragstyp — der Einschluss-/Ausschluss-Filter der Regel nach Vertragstyp.
4. Ihre Bedingungen — die Bedingungsfelder der Regel.
5. Erreichbarkeit auf dem ausgewählten Kanal — WhatsApp und SMS brauchen eine Telefonnummer, Email braucht eine E-Mail-Adresse.

Fehlende Kontaktdaten auf dem ausgewählten Kanal sind der häufigste Grund, warum ein passendes Mitglied nichts erhält. Ein Vorbehalt zum Bedingungsschritt: Eine Bedingung passt nur auf Mitglieder, die für dieses Feld tatsächlich einen Wert haben. Ein Mitglied ohne Wert wird von jedem Operator ausgeschlossen, auch von Verneinungen, sodass ein Mitglied ohne Zahlungsmethode nicht auf "Zahlungsmethode ist nicht Lastschrift" passt. Um Mitglieder ohne Wert zu erreichen, verwenden Sie eine explizite "is empty"-Bedingung, sofern das Feld eine solche anbietet.

Vorschau

Die Vorschau prüft die Reichweite einer Regel, bevor sie irgendetwas sendet.

• Die Vorschau wertet den aktuellen Entwurf der Regel aus, so wie Sie ihn im Editor haben, nicht die zuletzt gespeicherte Version.
• Sie liefert die Gesamtzahl der passenden Mitglieder und eine Stichprobenliste mit Name, Churn-Risiko-Band und wichtigen Besuchskennzahlen.
• Die Vorschau ist ein Echtzeit-Snapshot: Sie zeigt nur, wer jetzt gerade auf die Bedingungen passt, basierend auf dem Datenstand des aktuellen Tages (Mitglieder-Kennzahlen werden einmal pro Tag aktualisiert).
• Sie können die vollständige, paginierte Liste der passenden Mitglieder laden, was in großen Studios hilft.

Eine Zählung von 0 ist kein Problem. Wenn die Vorschau 0 Mitglieder zeigt, bedeutet das nur, dass heute niemand passt. Es bedeutet nicht, dass die Regel defekt ist oder dass morgen niemand passen wird: Mitglieder bewegen sich in die Bedingungen hinein und wieder heraus, wenn sich ihre Daten ändern, zum Beispiel wenn über Nacht ein Schwellenwert für den Vertragsablauf überschritten wird oder ein Mitglied die Dormancy-Schwelle überschreitet.

Nutzen Sie die Vorschau, um Schwellenwerte vor dem Aktivieren abzustimmen. Wenn eine Dormancy-Regel auf das halbe Studio passt, ist die Schwelle wahrscheinlich zu eng für eine sinnvolle Kampagne; erhöhen Sie den Wert für Tage seit dem letzten Besuch und rufen Sie die Vorschau erneut auf.

Die Vorschau zeigt, wer auf die Bedingungen passt. Sie simuliert keine Schutzmechanismen, daher kann die tatsächliche Anzahl der in einem Lauf gesendeten Nachrichten geringer ausfallen, sobald Cooldowns, Frequenzobergrenzen, Quiet hours, Dedup und die A/B-Kontrollgruppe angewendet werden. Behandeln Sie die Vorschau als "wer ist geeignet", nicht als "wer wird angeschrieben".

Referenz des Ausführungsprotokolls

Jedes ausgewertete Mitglied erhält eine Zeile, sodass Sie stets nachvollziehen können, warum jemand kontaktiert wurde oder nicht. Der Tab Delivery zeigt Übersichtskarten (Total matched, Group A, Group B) und eine Ergebnistabelle pro Mitglied. Die Ergebnisse lassen sich nach Zeitraum, Execution Run, Trigger, Kanal und A/B-Gruppe filtern und nach CSV exportieren.

Delivery-Ergebnisse: eine Zeile pro ausgewertetem Mitglied, mit Path (One-way oder Agent), Kanal, A/B-Gruppe und Ergebnis.

Spalten

Statuswerte

Jeder Versandversuch endet in genau einem der unten aufgeführten Ergebnisse, angezeigt in der Spalte Status. Die daneben liegende Spalte Path zeigt Agent (über den MagicAI-Chat-Agenten zugestellt) oder Einseitig (direkt gesendet) und ist bei übersprungenen und Control-Zeilen leer.

Dies sind die vom Engineering bestätigten Zustellprotokoll-Status (der ml-backend-Nachrichtenstatus-Satz). Jedes ausgewertete Mitglied erzeugt pro Lauf eine Zeile mit seinem Ergebnis. Der Status "Skipped (backend)" trägt ein zweitrangiges Grund-Feld, das die genaue Ursache benennt (siehe Backend-Skip-Gründe unten). Umfangreichere Zustellberichte pro Sendung (ein Status Succeeded, Failed oder Pending pro Nachricht mit dem Fehlergrund) sind für ein späteres Release geplant, nicht für das Go-live. Der genaue Bildschirmtext für die selteneren Status ist gegen die GA-UI bestätigt.

Backend-Skip-Gründe

Wenn der Status "Skipped (backend)" lautet, erklärt das Grund-Feld, warum das Zustellsystem die Nachricht zurückgehalten hat:

Siehe auch: WhatsApp für Engage einrichten. Siehe auch: Impact Analysis.