Baue nützliche E-Mail-Automatisierungen mit klaren Triggern, Bedingungsprüfungen, Wartezeiten und Tests, die abbilden, wie sich der Kundenstatus ändert.
Eine E-Mail-Automatisierung ist eine wiederholbare Entscheidung darüber, wann eine Nachricht verschickt wird. Der Editor ist nur ein Teil davon. Das Event, der aktuelle Status des Kunden und die Abbruchregeln zählen genauso viel wie die Texte.
Bevor du eine Sequenz entwirfst, schreib auf, warum es jede Nachricht geben sollte und was sie bis zum Versandzeitpunkt unpassend machen könnte.
Eine Registrierung, ein abgeschlossener Kauf, eine fehlgeschlagene Zahlung oder ein Meilenstein im Produkt kann eine Automatisierung starten. Gib dem Event eine klare Bedeutung. „Nutzer aktiv“ ist mehrdeutig; „erster Bericht exportiert“ kann die Anwendung erfassen und testen.
Nimm nur die Daten auf, die die Nachricht braucht, mit stabilen IDs und, wo relevant, einem Zeitstempel. Leg fest, welches System für welchen Wert maßgeblich ist. Die Zustellung von Events kann wiederholt werden. Nutze deshalb die Idempotenz, die deine Integration unterstützt, und teste doppelte Zustellungen.
Die Stripe-Integration liefert dokumentierte Abo- und Zahlungs-Events. Eigene Events aus deiner Anwendung können Meilensteine abdecken, die es nur in deinem Produkt gibt.
Eine Wartezeit ändert, wann der nächste Schritt ausgeführt wird. Die Fakten, die die Automatisierung kennt, aktualisiert sie für sich genommen nicht.
In einem eventbasierten Flow in Brew unterscheiden Filter-Knoten und Split-Knoten mit Bedingung zwischen Event-Daten und Kontaktdaten. activated oder payload.activated liest das ursprüngliche Event. Eine Payload bei der Registrierung mit activated: false kann morgen schon veraltet sein. contact.activated liest das aktuelle Kontaktfeld des Empfängers in Brew zu dem Zeitpunkt, an dem der Bedingungsknoten ausgeführt wird, auch nach einem Schritt „Warten“.
Für eine Erinnerung an die Einrichtung deklarierst du ein boolesches Kontaktfeld activated, hältst es aus deiner Anwendung heraus synchron und setzt nach der Wartezeit einen Filter contact.activated equals false. Ein fehlender Wert ist nicht dasselbe wie false, teste also beides. Setz vor jede spätere Erinnerung, die von diesem Status abhängt, eine Bedingung; eine Aktualisierung des Kontakts oder ein neues Event bricht eine laufende Ausführung nicht automatisch ab.
Beim Lesen des Kontakts fragt Brew weder deine Produktdatenbank noch deinen Abrechnungsanbieter ab. Hängen die Bedingungen von nicht synchronisierter Aktivität, einer bestimmten Rechnung oder dem aktuellen Warenkorbinhalt ab, plane diese Prüfung in deiner Anwendung ein. Lies zum Fälligkeitszeitpunkt den maßgeblichen Datensatz und löse ein neues Event für die Erinnerung nur aus, wenn sie dann noch sinnvoll ist.
Der Walkthrough zur Testphasen-Konversion behandelt beide Ansätze. Die Referenz zu Automatisierungen erklärt die Feldpfade in Bedingungen.
Eine Willkommens-Automatisierung kann die Ressource oder den nächsten Schritt liefern, die bei der Registrierung versprochen wurden. Eine Zahlungsbenachrichtigung kann ein echtes Abrechnungs-Event erklären. Eine E-Mail zu einem Meilenstein im Produkt kann jemandem helfen, das Ergebnis dessen zu nutzen, was er gerade abgeschlossen hat.
Halte die erste Version so klein, dass du sie noch überblicken kannst. Notiere für jede Nachricht Zielgruppe, Trigger, Pflichtfelder, gewünschte Aktion und die Bedingungen, die einen Versand verhindern sollten. Prüfe dabei auch den Abo-Status und den Umgang mit Sperrlisten.
In Brew steuern veröffentlichte Automatisierungen die Ausführung. Einen Entwurf zu erstellen oder zu bearbeiten ist nicht dasselbe, wie ihn zu veröffentlichen. Integrationseinstellungen und der Status einer Automatisierung haben unterschiedliche Aufgaben: Die Einstellung Vollständigen Namen synchronisieren bei Stripe steuert zum Beispiel, ob Namen aktualisiert werden, nicht, ob Event-Automatisierungen ausgeführt werden.
Teste eine normale Ausführung, fehlende optionale Felder, ein doppeltes Event, einen vom Marketing abgemeldeten Kontakt und einen Kunden, dessen Status sich ändert, bevor eine Erinnerung fällig ist. Aktualisiere bei Kontaktbedingungen das Feld in Brew während der Wartezeit und prüfe, ob die spätere Bedingung die Erinnerung überspringt. Prüfe bei Erinnerungen, die deine Anwendung plant, dass die Anwendung kein neues Event mehr auslöst, sobald der Kunde die Bedingungen nicht mehr erfüllt.
Prüfe neben dem Ausführungsprotokoll auch die echte E-Mail. Kontrolliere Links, Merge-Tags, Versanddomain und die genaue veröffentlichte Version. Eine erfolgreiche Trigger-Anfrage allein beweist nicht, dass die richtige Nachricht im richtigen Posteingang angekommen ist.
Eine Evergreen-Sequenz kann unbemerkt veralten, wenn sich Einrichtungsschritte, Preise oder der Zugang zum Produkt ändern. Gib jeder Sequenz eine verantwortliche Person und prüfe sie nach relevanten Releases.
Miss das gewünschte Ergebnis und die unerwünschten Effekte. Wenn das Ziel eine abgeschlossene Einrichtung ist, erfasse diese Aktion neben Beschwerden und Abmeldungen. Der Leitfaden zu Kennzahlen hilft dir, Öffnungen nicht als Beweis dafür zu werten, dass die Automatisierung geholfen hat.
