Zum Hauptinhalt springen

In mehrere Fälle aufteilen

Standardmäßig hat eine Regel ein Bündel von Aktionen, das ausgeführt wird, wann immer ihr Trigger feuert und ihre Bedingungen erfüllt sind. In mehrere Fälle aufteilen verwandelt dieses einzelne Bündel in eine Liste sich gegenseitig ausschließender Zweige, jeder mit seiner eigenen Bedingung und seinem eigenen Stapel von Aktionen. Verwende es, wenn die richtige Belohnung davon abhängt, wer das Mitglied ist oder wie das Auslöserereignis aussah — nicht nur, ob es passiert ist.

Was ein Fall ist​

In Schritt 3 des Regel-Assistenten ist das Standardlayout ein einzelner Aktionsblock: Aktion auswählen, konfigurieren, optional weitere Aktionen darunter hinzufügen, und alle laufen zusammen, wenn die Regel feuert. Das Aktivieren von In mehrere Fälle aufteilen ersetzt diesen einzelnen Block durch einen Stapel von Fall-Blöcken, jeder folgendermaßen aufgebaut:

  • Eine Bedingung-Zeile oben im Fall (gleiche Drei-Slot-Anatomie aus Feld / Operator / Wert wie in Schritt 2 — siehe die Bedingungs-Referenz).
  • Eine oder mehrere Aktionen, im Fall gestapelt, genauso wie Aktionen in einer nicht aufgeteilten Regel gestapelt werden.
  • Ein Verzögerung-Steuerelement pro Aktion, wie in jeder Aktion.

Nur die Aktionen im ersten passenden Fall werden ausgeführt. Fälle werden von oben nach unten gegen das auslösende Ereignis ausgewertet — der erste Fall, dessen Bedingung erfüllt ist, ist derjenige, der feuert, und die übrigen Fälle werden übersprungen.

Wann man Fälle verwendet​

Drei Muster decken den Großteil der realen Anwendung ab:

ODER-Logik. Bedingungen in Schritt 2 werden mit UND verknüpft — jede Bedingung muss erfüllt sein. Wenn die gewünschte Logik "feuere bei X ODER Y" lautet, teile die Regel in zwei Fälle auf: einen mit X als Bedingung und einen mit Y. Beide Fälle können dieselben Aktionen haben, wenn die Belohnung identisch ist; oder sie können sich unterscheiden, wenn X und Y unterschiedliche Behandlung verdienen.

Gestaffelte Belohnungen für einen Trigger. Eine einzelne Kauf-Regel, die VIPs 15 %, Stammkunden 10 % und allen anderen 5 % zurückgeben soll, sind drei Fälle: Tag = VIP → Guthaben hinzufügen 15 %, Tag = Stammkunde → Guthaben hinzufügen 10 %, und ein Auffangfall ohne Bedingung (oder mit einer permissiven) → Guthaben hinzufügen 5 %. Eine Regel, drei Belohnungspfade, keine Duplizierung von Trigger- und Timing-Setup.

Filterung auf Mitgliederebene für Trigger ohne Bedingungen. Einige Trigger (Gesamtausgaben aktualisiert, Besuch aktualisiert) zeigen in Schritt 2 keine Bedingungsfelder — das Ereignis selbst ist der Filter. Um sie nach Mitgliedsattributen einzugrenzen (Gesamtausgaben überschritten 500 €, Tag angewendet, Einwilligung erteilt), verwende stattdessen einen Fall in Schritt 3. Fall-Bedingungen reichen in Mitgliedsattribute hinein — Tags, Guthaben, Einwilligungs-Flags, Aktivitätszähler — die Schritt-2-Bedingungen in der Regel nicht erreichen.

tipp

Wenn du dich dabei ertappst, zwei fast identische Regeln zu schreiben, die sich nur in einer Bedingung unterscheiden, fasse sie zu einer einzigen Regel mit zwei Fällen zusammen. Du bekommst ein einziges Trigger-Setup, eine einzige Timing-Kachel, eine einzige Häufigkeitsbegrenzung — und die "welcher Zweig feuert"-Logik lebt an einem Ort statt verteilt auf zwei Regel-Datensätze.

Fälle vs. gestapelte Aktionen​

Fälle und gestapelte Aktionen lösen unterschiedliche Probleme; vermische sie nicht.

  • Gestapelte Aktionen laufen alle zusammen, wenn die Regel feuert. Verwende sie, wenn jede Aktion bei jedem Feuern passieren soll — "Guthaben hinzufügen und SMS senden" wird gestapelt, weil beides immer gewünscht ist.
  • Fälle laufen einen Zweig nach dem anderen — die Aktionen des ersten passenden Falls werden ausgeführt, der Rest übersprungen. Verwende sie, wenn die Aktionen von einer Bedingung abhängen, die das Auslöserereignis nicht aus sich heraus ausdrücken kann.

Du kannst mehrere Aktionen innerhalb eines einzelnen Falls stapeln — jeder Fall ist strukturell ein mini gestapelter Aktionsblock. Das Gesamtmodell lautet also: die Regel teilt sich in Fälle auf; innerhalb jedes Falls stapeln sich Aktionen.

Wie sich Fall-Bedingungen von Schritt-2-Bedingungen unterscheiden​

Schritt-2-Bedingungen filtern das Ereignis — überstieg der Kauf 20 €, war er in der Filiale Innenstadt, war der Gutschein in deiner benannten Liste? Fall-Bedingungen in Schritt 3 können dieselben Felder auf Ereignisebene filtern und zusätzlich in den Mitgliedszustand hineingreifen — wer die Person zum Zeitpunkt des Auslösens war.

In der Praxis bedeutet das, dass Fall-Bedingungen Dinge ausdrücken können wie:

  • Das Mitglied hat (oder hat nicht) ein bestimmtes Tag.
  • Der Punkte- oder Guthaben-Saldo des Mitglieds liegt über / unter einem Schwellenwert.
  • Die lebenslangen Gesamtausgaben oder die Besuchszahl des Mitglieds überschreiten einen Wert.
  • Das Mitglied hat einem bestimmten Kanal zugestimmt.

Die genaue Feldliste hängt vom Trigger ab; öffne das Bedingungs-Dropdown innerhalb eines Falls, um zu sehen, was aktuell verfügbar ist. Wenn du einen Filter willst, den Schritt 2 nicht zulässt, probier es zuerst mit Schritt 3 — meistens ist er dort.

Eine aufgeteilte Regel bauen​

Der Schritt-3-Workflow für eine aufgeteilte Regel ist unkompliziert — aber eines lohnt sich, bevor du anfängst zu klicken: plane die Reihenfolge deiner Fälle im Voraus. Fälle werden von oben nach unten ausgewertet und können nach der Erstellung nicht neu angeordnet werden. Wenn du auf halbem Weg merkst, dass Fall 3 eigentlich Fall 1 hätte sein sollen, musst du die späteren Fälle löschen und in der richtigen Reihenfolge neu aufbauen.

Mit dieser Warnung aus dem Weg:

  1. Aktiviere in Schritt 3 In mehrere Fälle aufteilen.
  2. Wähle im ersten Fall eine Bedingung — die Regel dafür, wann dieser Fall feuern soll — und füge eine oder mehrere Aktionen darunter hinzu. Setze deinen spezifischsten Fall an erste Stelle.
  3. Klicke auf + Fall hinzufügen, um den nächsten Fall hinzuzufügen. Wiederhole, ordne von spezifischer zu permissiver.
  4. Wenn du einen Auffangzweig für alle willst, die nicht in die früheren Fälle gepasst haben, füge einen abschließenden Fall ohne Bedingung (oder die permissivste, die du schreiben kannst) hinzu. Da Fälle von oben nach unten ausgewertet werden, läuft dieser Fall nur, wenn alle früheren Bedingungen fehlgeschlagen sind.
  5. Sieh dir Schritt 4 in der Vorschau an, um zu bestätigen, dass die Verzweigung das tut, was du erwartest.
warnung

Fälle können nicht neu angeordnet werden. Plane die Reihenfolge von spezifisch zu permissiv, bevor du anfängst, Details auszufüllen — eine falsche Reihenfolge bedeutet, die Fälle unterhalb des Fehlers zu löschen und neu zu bauen.

Stolperfallen​

4 Dinge, die oft zu Verwirrung führen
  • Aufteilung umzuschalten, nachdem Aktionen konfiguriert wurden, löscht sie. Wenn du Aktionen in Schritt 3 bereits ausgefüllt hast und dann In mehrere Fälle aufteilen aktivierst (oder deaktivierst), warnt dich der Assistent und löscht die vorherige Konfiguration. Entscheide dich für die Struktur, bevor du die Details ausfüllst. Wenn du auf halbem Weg merkst, dass du Fälle brauchst, beende die aktuelle Regel und plane die Struktur bei der nächsten im Voraus.
  • Erste Übereinstimmung gewinnt — Reihenfolge zählt, und sie ist gesperrt. Ein Fall mit einer breiten Bedingung, der über einem Fall mit einer engen platziert wird, schluckt den engen — der enge Fall bekommt nie die Chance zu feuern. Da Fälle nach der Erstellung nicht neu angeordnet werden können, setze die spezifischsten Fälle nach oben und den Auffangfall nach unten schon beim Bauen.
  • Fälle teilen sich Trigger, Timing, Häufigkeitsbegrenzung und Zielgruppe der Regel. Ein Fall ist nur ein Zweig auf der Aktionsseite — er filtert weder den Trigger noch das Timing-Fenster neu. Wenn zwei Zweige wirklich unterschiedliche Trigger oder unterschiedliche Häufigkeitsbegrenzungen brauchen, sollten sie zwei separate Regeln sein, nicht zwei Fälle einer Regel.
  • Die Häufigkeitsbegrenzung gilt für die ganze Regel, nicht pro Fall. Eine Regel, die auf "einmal pro Mitglied pro Tag" begrenzt ist, feuert höchstens einmal, unabhängig davon, welcher Fall passte. Wenn du unabhängige Begrenzungen pro Zweig brauchst (VIP einmal pro Tag, Stammkunde einmal pro Woche), teile in separate Regeln auf.

Durchgearbeitetes Beispiel — gestaffelter Cashback​

Ziel: VIP-Mitgliedern 15 % zurückgeben, Mitgliedern mit dem Tag regular 10 %, allen anderen 5 %, alles auf demselben Kauf-Trigger.

  • Trigger: Tätigt einen Kauf.
  • Schritt-2-Bedingungen: keine über das hinaus, was die Standard-Zielgruppen-/Timing-Kacheln bereits abdecken — die Aufteilung auf Mitgliederebene passiert in den Fällen.
  • Schritt 3: aktiviere In mehrere Fälle aufteilen, dann:
    • Fall 1 — Bedingung: Tag = VIP. Aktion: Guthaben hinzufügen, 15 % des ausgegebenen Betrags. Denk daran, den memberCredit-Ausschluss unter Nicht akkumulieren für diese Zahlungsmethoden hinzuzufügen.
    • Fall 2 — Bedingung: Tag = Stammkunde. Aktion: Guthaben hinzufügen, 10 % des ausgegebenen Betrags. Gleicher memberCredit-Ausschluss.
    • Fall 3 — Bedingung: keine (Auffangfall). Aktion: Guthaben hinzufügen, 5 % des ausgegebenen Betrags. Gleicher memberCredit-Ausschluss.

Da Fälle von oben nach unten ausgewertet werden, bekommt ein als VIP getaggtes Mitglied 15 %, ein Nicht-VIP mit dem Tag regular bekommt 10 %, und alle anderen — ohne Tag, anonym (sofern die Zielgruppe es zulässt) oder mit etwas anderem als VIP / Stammkunde getaggt — bekommen 5 %. Eine Regel, drei Belohnungspfade.