Journeys starten, sobald etwas passiert
Das Trigger-based-Entry-Element startet eine Journey in dem Moment, in dem ein Nutzer etwas Wichtiges tut: in den Warenkorb legen, eine Zahlung fehlschlagen lassen, eine Bestellung aufgeben. Kein Warten auf den nächsten geplanten Segment-Abgleich.
Events und Journeys laufen auf eigener Hardware in den USA und Deutschland
Jedes Event, das ein Trigger-based-Entry-Element auswertet, läuft über dieselbe Infrastruktur wie die gesamte Plattform: Pushwoosh ist SOC 2 Type I und ISO 27001:2022 zertifiziert, DSGVO-konform und betreibt eigene Hardware in den USA und in Deutschland, unter dem deutschen Bundesdatenschutzgesetz (BDSG). Vollständige Details finden Sie auf der Seite Datensicherheit.
Der Moment zählt
Eine Journey soll in dem Moment starten, in dem etwas passiert – nicht wenn der nächste Segment-Abgleich zufällig ansteht. Das lässt sich leicht versprechen und schwer halten, sobald mehrere Automatisierungen parallel laufen: eine Warenkorb-Sequenz neben einem Dutzend anderer, jede für sich plausibel. Eine fehlgeschlagene Zahlung, die eine Stunde später von einem nächtlichen Batch-Lauf aufgegriffen wird, ist eine andere Nachricht als eine, die bereits läuft, während der Kunde noch auf sein Banking-App-Fenster schaut. Genau diese Lücke schließt Trigger-based Entry.
Was Trigger-based Entry leistet
Wählen Sie ein Event, und jeder, der es auslöst, tritt sofort in die Journey ein, statt auf den nächsten Scan eines gespeicherten Segments zu warten.
Reagiert in Echtzeit
Tritt in dem Moment ein, in dem das Event ausgelöst wird, nicht beim nächsten geplanten Scan.
Filtert auf die Nutzlast
Optionale Bedingungen auf den Event-Attributen qualifizieren den Eintritt über den Namen hinaus.
Führt mehrere Sessions gleichzeitig
Parallelität, verknüpft mit order_id oder product_id, lässt einen Nutzer mehrere parallele Durchläufe halten.
Steuert Re-Entry
Blockieren Sie einen wiederholten Trigger, oder lassen Sie ihn die Session neu starten, je Element.
| Einstellung | Optionen |
|---|---|
| Event-Quelle | SDK postEvent, REST API, Standard-PW_*-Events, benutzerdefinierte Events, Geozone-Eintritt oder -Austritt |
| Eintrittsbedingung | Optional: Filter auf den Event-eigenen Attributen (Attribut, Operator, Wert) |
| Wer eintritt | Der Nutzer, der das Event ausgelöst hat, oder ein in der Event-Nutzlast benannter Nutzer |
| Re-Entry | Nicht erlauben (Standard), oder erlauben und die Session neu starten |
| Parallelität | Eine aktive Session pro Nutzer, oder mehrere, verknüpft mit einem Session-Attribut wie order_id oder product_id |
Audience-based Entry prüft ein Segment nach Zeitplan erneut. Trigger-based Entry reagiert im selben Moment, in dem das Event ausgelöst wird, und mehrere Sessions pro Nutzer bedeuten, dass 3 offene Bestellungen jeweils ihre eigene Status-Journey durchlaufen können, statt in eine zu kollidieren. Ein späteres Event zurück zur richtigen dieser Sessions zu leiten, übernimmt der sitzungsbezogene Abgleich von Wait for Trigger weiter unten auf der Canvas. Das vollständige Element, Bedingungen und Re-Entry-Steuerung inklusive, ist im kostenlosen Plan enthalten.
Warum das für den Journey Builder zählt
Ein Journey Builder ist nur so gut wie seine Einstiegspunkte. Audience-based Entry deckt den geplanten Rhythmus ab: Newsletter, Rückgewinnungs-Wellen. Was ein Builder zusätzlich braucht, ist eine Reaktion in dem Moment, in dem eine Zahlung fehlschlägt, ein Warenkorb verlassen wird oder – etwa bei einer Automotive-App – ein Fahrzeug eine fällige Serviceerinnerung auslöst. Genau das liefert Trigger-based Entry für den Customer Journey Builder. Es liest aus demselben Event-Katalog, den der Rest der Canvas bereits für Segmentierung und Verzweigung nutzt, sodass das Signal, das die Tür öffnet, dasselbe ist, das den Ablauf danach steuert.
Was als Nächstes übergeben wird
Ein add_to_cart-Event löst aus und startet eine Journey zur Warenkorbabbrecher-Rückgewinnung. Ein Wait for Trigger-Element gibt dem Käufer dann bis zu 90 Tage, um den Kauf abzuschließen, bevor es in Win-back verzweigt. Keines der beiden Elemente versendet selbst etwas. Beide übergeben an einen Kanal-Baustein, und das Entry-Element hat entschieden, wer überhaupt im Ablauf war.
Das Event, das eine Session startet, kann auch den Schlüssel tragen, den ein späterer Zweig braucht, um eine Bestellung von einer anderen zu unterscheiden – alles auf derselben Customer Journey Builder-Canvas.
So funktioniert’s
-
Entry-Element hinzufügen
Fügen Sie auf der Canvas ein Trigger-based-Entry-Element hinzu und wählen Sie das Event: ein Standard-PW_*-Event oder ein benutzerdefiniertes, gesendet über SDK postEvent oder einen Server-Aufruf.
-
Eintritt qualifizieren und ausrichten
Fügen Sie eine Bedingung auf den Event-Attributen hinzu, um den Eintritt zu qualifizieren – add_to_cart, wobei cart_value über 50 liegt, zum Beispiel – und legen Sie fest, ob die Person, die das Event ausgelöst hat, eintritt, oder der in der Nutzlast benannte Nutzer.
-
Re-Entry und Parallelität festlegen
Entscheiden Sie, ob jemand, der bereits in der Journey ist, sie erneut auslösen kann, und ob ein Nutzer mehrere Sessions gleichzeitig halten kann, verknüpft mit einem Attribut wie order_id.
Machen Sie aus einem Event eine lebendige Journey.
Weitere Produkte entdecken
Planen und optimieren Sie Ihre Kampagnen mit einem einzigen visuellen Tool. Kommunizieren, engagieren, binden, konvertieren, segmentieren und experimentieren Sie mit dem Pushwoosh Customer Journey Builder.
DSGVO-konformes Event-Trigger Marketing: Kampagnen automatisch starten, wenn Nutzer aktiv sind. Echtzeit-Trigger für maximale Konversionen im DACH-Markt.
Bis zu 3 Zweige mit je 4 Events, UND/ODER-Logik, garantiertem vierten Zweig und 90 Tagen Wartefenster – DSGVO-konform in den USA und Deutschland gehostet.
Pausieren Sie Journeys per fester Dauer, Uhrzeit, Datum oder Wochentag – DSGVO- und BDSG-konform in den USA und Deutschland gehostet.
Verwandeln Sie verlassene Warenkörbe in Umsatz mit automatisierten Cart-Recovery-Kampagnen. Senden Sie rechtzeitige Erinnerungen, personalisierte Angebote und Anreize, die Conversions vorantreiben.
Prüft vor dem Versand, ob Push, E-Mail, SMS, WhatsApp oder LINE offen ist, und routet bei geschlossenem Kanal automatisch zur nächsten Fallback-Stufe.