Eventbasierte Marketing- und Transaktions-E-Mails verstehen: ein praktisches Modell für Trigger-Payloads, Veröffentlichung und spätere Bedingungsprüfungen.
Eine Trigger-E-Mail beginnt mit etwas, das passiert ist: einer Registrierung, einer fehlgeschlagenen Rechnungszahlung, einem abgeschlossenen Export oder einem anderen Event, das dein System beschreiben kann. Dieses Event liefert den Kontext für eine Nachricht.
Der Trigger entscheidet nicht, ob die Nachricht Marketing ist oder transaktional. Das entscheiden der Zweck der Nachricht und die Beziehung zum Empfänger. Ein Beleg und ein Upgrade-Angebot können aus demselben Produkt stammen und trotzdem unterschiedliche Versandregeln brauchen.
Wähle einen Namen, der eine Aktion oder einen geprüften Zustand beschreibt. Deklariere die Felder, die die E-Mail braucht, und teste repräsentative Payloads. Vermeide ein Event, das je nach sendendem Dienst etwas anderes bedeutet.
Ein Event für eine abgeschlossene Bestellung könnte zum Beispiel die Empfängeradresse, die Bestellreferenz und einen Link zur Bestellung enthalten. Lass sensible oder unnötige Daten aus der Payload heraus. Die API-Referenz dokumentiert die unterstützten Formate für Anfragen.
Im Automatisierungsmodell von Brew ist ein Trigger mit Schritten wie dem Versand einer E-Mail verbunden. Erstelle und prüfe den Entwurf und veröffentliche die Automatisierung, bevor du erwartest, dass Events aus dem Produktivbetrieb sie ausführen. Welche Lifecycle-Flows du zuerst bauen solltest, von der Registrierung bis zur Reaktivierung, erklärt der Beitrag KI-E-Mail-Automatisierung.
Eine Willkommenssequenz, die ein Produkt bewirbt, ist Marketing. Ein Bestellbeleg oder eine angeforderte Nachricht zur Kontosicherheit kann transaktional sein. Bei gemischten Nachrichten musst du den Hauptzweck bewerten; ein kleines Werbeelement beantwortet die rechtliche Frage nicht automatisch in die eine oder andere Richtung.
Sorg dafür, dass wesentliche Kontoinformationen leicht zu finden sind. Nutze den passenden Versandzweck der Domain und teste das Abo-Verhalten. Der Leitfaden zu Transaktions-E-Mails erklärt die Unterscheidung und verlinkt die Anforderungen der Anbieter.
Bei Marketing prüfst du die Einwilligung und respektierst Abmelde- und Sperrstatus. Ein passendes Event ist keine Erlaubnis, jeden anzuschreiben, dessen Adresse zufällig in der Payload steht.
Angenommen, du willst einen Testnutzer erinnern, der die Einrichtung nach sechs Tagen noch nicht abgeschlossen hat. Das Registrierungs-Event weiß, was bei der Registrierung galt. Ob die Person morgen fertig wird, kann es nicht vorhersagen.
Für die Prüfung an Tag sechs kann in Brew ein Filter-Knoten oder ein Split-Knoten mit Bedingung über contact.<name> aktuelle Kontaktfelder in Brew lesen. Leg die Felder für Aktivierung und Abo an, synchronisiere sie und prüfe sie nach der Wartezeit. Event-Felder wie payload.activated enthalten weiterhin die ursprünglichen Werte des Events. Liegt der benötigte Status außerhalb von Brew, lass deine Anwendung ihn an Tag sechs prüfen und nur dann ein neues Erinnerungs-Event auslösen, wenn die Person die Bedingungen noch erfüllt.
Dieselbe Regel gilt, wenn die Bedingung „hat nicht gekauft“ oder „ist noch im kostenlosen Plan“ lautet. Der Beitrag zur Testphasen-Sequenz erklärt das Muster auf der Seite der Anwendung.
Teste die Event-Anfrage, die Ausführung der Automatisierung und die empfangene E-Mail. Nimm fehlende Felder, Wiederholungen, private Testempfänger und eine Statusänderung auf, die einen späteren Versand verhindern sollte.
Nutze bei verbundenen Anbietern deren tatsächliche Event-Namen. Die Seite zu Stripe listet die Events auf, die Brew unterstützt, und erklärt, warum die Einstellung „Vollständigen Namen synchronisieren“ nichts mit dem Veröffentlichen einer Automatisierung zu tun hat.
Sobald der Weg funktioniert, halte die Sequenz verständlich. Eine kleine Zahl expliziter Events und geprüfter Nachrichten ist leichter zu pflegen als eine lange Automatisierung, deren Bedingungen niemand erklären kann.
