Baue eine Testphasen-Sequenz, die dem Verhalten im Produkt folgt: Aktivierungs-Event, eine Aufgabe pro E-Mail, Bedingungsprüfungen und Tests der Ausstiege.
Eine E-Mail zur Testphasen-Konversion sollte darauf reagieren, was die Person getan hat. Wer noch kein Projekt angelegt hat, braucht Hilfe bei der Einrichtung. Wer das Produkt täglich nutzt, braucht eine klare Erklärung des kostenpflichtigen Plans. Schickst du beiden denselben Countdown, übergehst du genau diesen Unterschied.
Dieser Leitfaden trennt das Design der Sequenz von der Anwendungslogik, die entscheidet, wer welche E-Mail bekommen soll.
Wähle eine Aktion, die zeigt, dass die Person das erste nützliche Ergebnis im Produkt erreicht hat. Sie sollte so konkret sein, dass dein Backend sie erfassen kann: ein angelegtes Projekt, ein abgeschlossener Import oder ein eingeladenes Teammitglied. Ein Seitenaufruf allein reicht selten aus.
Erfasse Registrierungszeitpunkt, Ende der Testphase, Aktivierung und Zahlungsstatus in dem System, das für diese Fakten maßgeblich ist. Behandle Kontaktfelder in der E-Mail-Plattform als synchronisierte Daten, nicht als Garantie dafür, dass ein bereits laufender Flow aktuelle Daten liest.
| Nachricht | Wann sie sinnvoll ist | Bedingung zum Versandzeitpunkt |
|---|---|---|
| Willkommen | Nach Registrierung oder Verifizierung | Das Konto existiert und darf diese Nachricht erhalten |
| Hilfe bei der Einrichtung | Etwa zwei Tage später, angepasst an dein Produkt | Noch nicht aktiviert |
| Nächste sinnvolle Aktion | Nach der Aktivierung | Aktiviert, diese Aktion aber noch nicht abgeschlossen |
| Testphase endet | Vor dem tatsächlichen Ende der Testphase | Die Testphase läuft noch, und das Konto ist nicht bezahlt |
| Letztes Nachfassen | Nach dem Ende der Testphase, falls passend | Weiterhin nicht bezahlt, erfüllt die Bedingungen und darf Marketing-E-Mails erhalten |
Diese Zeitpunkte sind Ausgangspunkte für einen Test, keine gemessenen optimalen Abstände. Nenne das tatsächliche Ende der Testphase und was danach passiert. Erfinde keine Knappheit und deute keine Abbuchung an, wenn keine Zahlungsmethode hinterlegt ist.
In einem eventbasierten Flow in Brew liest payload.activated das ursprüngliche Event, contact.activated dagegen das aktuelle Kontaktfeld des Empfängers in Brew, sobald ein Filter-Knoten oder ein Split-Knoten mit Bedingung ausgeführt wird. Damit Erinnerungen an die Einrichtung nach der Aktivierung entfallen, deklarierst du dieses boolesche Feld, hältst es aus deinem Produkt heraus synchron und prüfst nach jedem relevanten Schritt „Warten“ contact.activated equals false. Fehlende Werte sind nicht false; teste sie separat.
Dabei liest Brew den gespeicherten Kontakt, nicht die Datenbank deiner Anwendung und auch keine Live-Anfrage an Stripe. Ein eingehendes Aktivierungs- oder Zahlungs-Event bricht eine frühere Ausführung nicht automatisch ab. Der Ablauf braucht vor jedem Versand, der vom Status abhängt, eine Bedingung.
Für Fakten außerhalb von Brew lässt du deine Anwendung einen Job planen. Wird er fällig, liest er das aktuelle Konto oder die aktuelle Rechnung und löst nur dann ein separates eigenes Event in Brew aus, wenn der Empfänger die Bedingungen noch erfüllt. Gib die aktuellen Daten, die du für die Personalisierung brauchst, in diesem neuen Event mit.
Eine Erinnerung, deren Zeitplan deine Anwendung steuert, funktioniert zum Beispiel so:
Signup committed → fire welcome event
Reminder job becomes due → read current account
Already activated or paid → finish without firing an email event
Still eligible → fire setup-reminder event with current dataNutze die tatsächliche Trigger-ID, die Brew zurückgibt, und das deklarierte Schema des Triggers. Halte dich an die Anleitung zum Einrichten von Automatisierungen und an die typisierten Payload-Verträge. Nutze für wiederholte Event-Auslösungen den dokumentierten Idempotenz-Mechanismus.
Wenn Stripe die Testphase verwaltet, liefern seine Abo-Events den Kontext zur Abrechnung. Die Stripe-Integration stellt unterstützte Event-Trigger bereit, darunter customer.subscription.trial_will_end. Für die Aktivierung im Produkt bleibt deine Anwendung maßgeblich, solange du diese Information nicht separat sendest.
Prüfe bei einer späteren Erinnerung, die mit der Zahlung zu tun hat, den aktuellen Datensatz in Stripe. Eine erfolgreich aktualisierte Karte beweist nicht, dass eine Rechnung bezahlt wurde. Stimm dich mit den E-Mails ab, die Stripe selbst versendet, damit der Kunde für jeden Zweck nur einen Hinweis bekommt.
Geh von der tatsächlichen Situation des Empfängers aus. Erkläre eine nützliche Aktion und verlinke direkt dorthin. Eine E-Mail zur Einrichtung kann ein kurzes Beispiel und eine Antwortadresse anbieten. Eine E-Mail zum kostenpflichtigen Plan sollte das relevante Limit oder die relevante Funktion und den echten Preis nennen, mit einem Link zu den aktuellen Preisen.
Marketing-Einwilligung, Abmeldeverhalten und Versandzweck der Domain müssen zur Nachricht passen. Eine Registrierung für die Testphase rechtfertigt keine Werbe-E-Mails, die nichts damit zu tun haben.
Teste, was passiert, wenn ein Kontakt vor einer Bedingungsprüfung aktiviert oder zahlt. Aktualisiere bei Kontaktbedingungen die relevanten Felder in Brew während der Wartezeit und prüfe, ob die Erinnerung übersprungen wird. Bei Prüfungen, die deine Anwendung plant, stellst du sicher, dass Konten, die die Bedingungen nicht erfüllen, kein Erinnerungs-Event erzeugen. Teste außerdem Wiederholungen, verlängerte Testphasen, gelöschte Konten, Abmeldungen und fehlende Felder. Sieh dir sowohl die Logs der Anwendung als auch den Ausführungsverlauf in Brew an.
Bewerte Aktivierung und Konversion zu zahlenden Kunden anhand deiner Produktdaten, Zustellfehler anhand der E-Mail-Plattform. Öffnungsraten allein zeigen nicht, ob die Sequenz einem Testnutzer geholfen hat. Beispiele findest du im Leitfaden zur Willkommensserie, die Aufteilung der Umsetzung in MCP vs. REST.
