# Onboarding E-Mail Serie: Auf Ereignisse statt Tage bauen URL: https://notificationharbor.com/de/journal/onboarding-e-mail-serie-ereignisse-statt-tage Type: blog Locale: de Published: 2026-10-27 Updated: 2026-10-28 --- > Ein praktischer Bauplan für eine Onboarding E-Mail Serie mit Ereignissen: die fünf E-Mails, die Auslogik, die Austrittsregeln und die Messung. Eine Onboarding E-Mail Serie funktioniert, wenn sie auf das reagiert, was ein neuer Nutzer getan hat, und nicht darauf, wie viele Tage seit der Anmeldung vergangen sind. Bauen Sie sie um ein einziges Aktivierungsereignis herum, senden Sie jede E-Mail aufgrund eines Signals und geben Sie jeder E-Mail eine Austrittsbedingung. Ein fester Zeitplan mit Tag 1, Tag 3 und Tag 7 ist der Ausweichplan, nicht das Design. Die meisten Teams machen es umgekehrt. Sie schreiben fünf E-Mails, setzen Verzögerungen und liefern aus. Sechs Wochen später hat sich die Aktivierung nicht bewegt, und niemand kann sagen, welche E-Mail dafür verantwortlich ist. ## Mit dem Aktivierungsereignis beginnen, nicht mit der Willkommensmail Die Serie soll eine Anmeldung in genau eine messbare Handlung überführen. Legen Sie diese Handlung fest, bevor Sie eine Zeile Text schreiben. „Projekt angelegt“ oder „erste API-Anfrage gesendet“ qualifizieren sich. „Eingeloggt“ tut es nicht. Definieren Sie auch das Zeitfenster. Unser Standard ist die Aktivierung innerhalb von 14 Tagen nach der Anmeldung, gezählt pro Anmeldekohorte. Ohne Zeitfenster können Sie zwei Versionen der Serie nicht vergleichen. Arbeiten Sie dann rückwärts. Listen Sie die Schritte auf, die ein Nutzer gehen muss, um dieses Ereignis zu erreichen, und geben Sie jedem Schritt höchstens eine E-Mail. Hat ein Schritt keine E-Mail, erledigt der Nutzer ihn allein, oder Sie akzeptieren den Abbruch. ![Notizbuch mit handgezeichnetem Flussdiagramm neben einer Tastatur und einer Tasse Kaffee](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/595e85-img1.webp) Verzichten Sie auf die E-Mail mit dem „Rundgang durch die Funktionen“. Sie beantwortet am zweiten Tag eine Frage, die niemand gestellt hat. Eine E-Mail, eine Handlung, ein Link. ## Wie sieht eine minimale Serie in der Praxis aus? Fünf E-Mails decken die meisten SaaS-Produkte mit Testphase ab. Das ist die Form, die sich in der Praxis bewährt, jeweils mit ihrem Auslöser. - **Willkommen**: wird bei `user.signed_up` sofort gesendet. Bestätigt das Konto, nennt die eine erste Handlung und verlinkt direkt darauf. - **Anstoß zur ersten Handlung**: wird 24 Stunden nach der Anmeldung gesendet, aber nur, wenn das Ereignis des ersten Schritts noch nicht ausgelöst wurde. - **Hilfe bei Blockaden**: wird gesendet, wenn ein bekanntes Fehlersignal auftritt, etwa ein ungültiger API-Schlüssel oder ein abgebrochener Import. Dies ist die wertvollste E-Mail der Serie. - **Beleg**: wird am dritten Tag an Nutzer gesendet, die begonnen, aber nicht abgeschlossen haben. Ein Ergebnis eines Kunden, eine Zahl mit ihrem Kontext. - **Letzter Schritt**: wird gesendet, wenn der Nutzer nur noch ein Ereignis von der Aktivierung entfernt ist, oder am Tag 7 als zeitlicher Ausweichplan. Drei der fünf E-Mails sind an Bedingungen geknüpft. Nur die Willkommensmail geht an alle. Willkommensmails haben außerdem die besten Öffnungsraten, die Sie je sehen werden. Behandeln Sie diese Zahl mit Vorsicht: Die Mail Privacy Protection von Apple lädt Bilder vorab und bläht die Öffnungen für einen großen Teil Ihrer Liste auf. Messen Sie stattdessen Click-to-activate. ## Zeitbasierte Drips scheitern bei den wichtigsten Nutzern Ein rein zeitbasierter Drip schickt die E-Mail vom dritten Tag an einen Nutzer, der schon am ersten Tag aktiviert hat. Diesem Nutzer wird nun etwas empfohlen, das er bereits getan hat. Das wirkt wie Automatisierung, und genau das ist es auch. Er scheitert ebenso in die andere Richtung. Ein Nutzer, der bei Schritt zwei hängt, bekommt eine fröhliche Funktions-E-Mail statt Hilfe. Die Serie erkennt das Problem nicht und kann deshalb nicht reagieren. Die Lösung ist nicht kompliziert, braucht aber eine Ereignisquelle. Verhaltensgesteuerte Serien benötigen drei Dinge: den Ereignisstrom, einen Zustand pro Nutzer und eine Regel, die diesen Zustand vor jedem Versand prüft. `{ "trigger": "user.signed_up", "steps": [ { "id": "welcome", "delay": "0s" }, { "id": "first_action_nudge", "delay": "24h", "send_if": "NOT event(project.created)" }, { "id": "proof", "delay": "72h", "send_if": "event(project.created) AND NOT event(first_send)" }, { "id": "last_step", "delay": "7d", "send_if": "NOT event(activated)" } ], "exit_when": ["activated", "unsubscribed", "account.deleted"] }`Die Prüfung `send_if` läuft zum Zeitpunkt des Versands, nicht bei der Einschreibung. Dieser Unterschied ist wichtig. Werten Sie die Bedingung beim Eintritt in den Flow aus, haben Sie ein statisches Segment gebaut, und der Zustand ist beim Versand veraltet. ## Die Austrittsbedingung ist das Feature, das alle vergessen Jede Serie braucht eine Regel, die sie beendet. Die naheliegende ist die Aktivierung. Zwei weitere werden oft übersehen: die Abmeldung vom Onboarding-Stream sowie die Kontolöschung oder das Ende der Testphase. Wir haben Serien gesehen, die Nutzer weiter anschrieben, nachdem sie zahlende Kunden geworden waren. Das ist ein Fehler bei der Austrittsbedingung, und er kostet mehr als eine verpasste Öffnung. Der Nutzer lernt, dass Ihre E-Mails nicht an sein Konto gebunden sind. Schreiben Sie die Austrittsregeln zuerst und testen Sie sie zuerst. Spielen Sie einige echte Nutzerverläufe in einer Staging-Umgebung durch den Flow und prüfen Sie, ob jeder an der richtigen Stelle endet. Eine Serie mit guten Texten und ohne Austritt ist schlechter als eine Serie mit schlichten Texten und sauberen Austritten. ![Laptop mit Terminal-Ereignisprotokollen in einem dunklen Raum](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/390062-img2.webp) ## Woher die Ereignisdaten kommen Die Qualität der Serie hängt von der Qualität des Signals ab. Es gibt drei übliche Quellen mit unterschiedlicher Latenz und unterschiedlichen Fehlerbildern. Eine Analytics-Pipeline wie Segment leitet Ereignisse innerhalb von Sekunden weiter, aber nur die, die Sie instrumentiert haben. Ein direkter Webhook aus Ihrem Backend ist am zuverlässigsten, weil er aus dem Codepfad feuert, der die eigentliche Arbeit erledigt. Postgres Change Data Capture erfasst alles, was die Zeile berührt, auch Änderungen durch Admin-Skripte. Das kann eine Funktion sein oder ein Fehler. Legen Sie eine einzige Wahrheitsquelle für das Aktivierungsereignis fest und dokumentieren Sie sie direkt neben der Flow-Definition, damit der nächste Entwickler keine zweite hinzufügt. Zwei Quellen, die sich um wenige Minuten unterscheiden, erzeugen E-Mails, die dem Produktzustand widersprechen. So bekommt ein Nutzer „Setup abschließen“ zu lesen, obwohl er das Setup gerade beendet hat. Ebenso wichtig ist die Idempotenz. Ereignispipelines wiederholen Zustellungen, daher kann dasselbe `project.created`-Ereignis zweimal ankommen. Dedupliziert Ihr Versender nicht über einen Schlüssel, bekommt der Nutzer die E-Mail doppelt. Customer.io ist um dieses Modell herum gebaut: Es nimmt Ereignisse über eine API, SDKs oder ein CDP entgegen und löst Workflows über einen visuellen Builder aus. Wenn Sie auf einem anderen Stack laufen, funktioniert dasselbe Muster mit jedem Versender, der einen Auslöser annimmt und Bedingungen zum Zeitpunkt des Versands auswertet. ## Transaktional oder Marketing: die Versandart bewusst wählen Einige Onboarding-E-Mails sind in der Praxis transaktional. Eine Nachricht wie „Ihr API-Schlüssel ist bereit“ oder eine Bestätigung der E-Mail-Adresse sollte nicht hinter einer Marketing-Warteschlange warten und sich nicht die Sendereputation mit einem Werbeversand teilen. Postmark macht diese Trennung zum Grundprinzip und legt Nachrichtenstreams auf getrennte Infrastruktur. Die Begründung stimmt, auch wenn Sie Postmark nicht nutzen: Ein schlechter Werbeversand darf niemals einen Passwort-Reset verzögern. Unsere Regel ist einfach. Kann der Nutzer ohne die E-Mail nicht weitermachen, geht sie über den transaktionalen Stream. Ist die E-Mail eine Ermutigung, geht sie über den Lifecycle-Stream, mit einer Abmeldung, die nur diesen Stream betrifft. ![Messingfarbener Weichenhebel an einer Gleisverzweigung](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/notificationharbor/2026-10/547606-img3.webp) ### Verändert ein entwicklerorientierter Versender den Aufbau? Er verändert den Ausgangspunkt. Bei einem API-first-Versender lebt die Serienlogik in Ihrem Code oder in einem kleinen Worker, und der Anbieter liefert nur aus. Sie erhalten Versionskontrolle, Tests und Code-Review für Ihre Flows, verlieren aber den visuellen Builder. Resend geht diesen Weg mit einer REST-API, offiziellen SDKs und React-Email-Vorlagen. Für ein Team, das E-Mails als Komponenten behandelt, ist das ein passender Ansatz. Für ein Growth-Team, das Texte ohne Deployment ändern will, ist es eine Hürde. Seien Sie ehrlich, wer die Serie bearbeitet. Lautet die Antwort „Growth, wöchentlich“, ist ein Workflow-Builder die richtige Wahl, auch wenn Entwickler das nicht mögen. Lautet sie „Engineering, pro Release“, halten Sie die Serie im Code. ## Click-to-activate messen, nicht Öffnungen Die Öffnungsrate ist für diese Aufgabe ein schwaches Signal. Datenschutzfunktionen blähen sie auf, und eine Öffnung bedeutet nicht, dass der Nutzer etwas getan hat. Drei Kennzahlen sagen mehr aus. - **Click-to-activate**: Von den Nutzern, die auf eine bestimmte E-Mail geklickt haben, wie viele haben das Aktivierungsereignis innerhalb von 24 Stunden erreicht? - **Auslöse-Latenz**: Die Zeit zwischen dem Ereignis und dem Versand. Bei einer Hilfe-E-Mail gegen Blockaden verliert jede Nachricht, die mehr als wenige Minuten braucht, den Moment. - **Aktivierungsrate gegen eine Kontrollgruppe**: Halten Sie eine kleine Gruppe von Anmeldungen von der Serie zurück und vergleichen Sie deren Aktivierung nach 14 Tagen mit dem Rest. Die Kontrollgruppe ist der einzige Weg, zu wissen, ob die Serie wirkt. Ohne sie schreiben Sie den E-Mails Aktivierungen gut, die ohnehin passiert wären. Eine Benchmark-Aktivierungsrate nennen wir hier nicht, denn die veröffentlichten Werte stammen von Anbietern mit unterschiedlichen Definitionen. Messen Sie zuerst Ihre eigene Ausgangsbasis. Ändern Sie dann jeweils eine E-Mail. ### Eine Serie oder mehrere bauen? Teilen Sie nach Eintrittsbedingung auf, nicht nach Persona-Labels. Ein Nutzer, der über eine Einladung kam, hat eine andere erste Handlung als jemand, der sich allein angemeldet hat. Ein Nutzer, der Daten importiert hat, hat bereits eine Schwelle überschritten, die die anderen noch nicht erreicht haben. Zwei oder drei Eintrittspfade reichen meist aus. Bei mehr übersteigt der Wartungsaufwand den Nutzen, denn jeder Pfad braucht eigene Austritte und eigene Tests. Eine All-in-one-Plattform kann den Einrichtungsaufwand senken, wenn das Team klein ist. Brevo bündelt E-Mail, SMS und CRM unter einem Login, was Teams entgegenkommt, die noch keine Ereignispipeline aufbauen wollen. Der Nachteil: Das Marketing-Dashboard steht im Mittelpunkt, und Trigger im Sekundenbereich sind nicht das, worauf es optimiert ist. ## Was wir zuerst ausliefern würden Schreiben Sie das Aktivierungsereignis und das 14-Tage-Fenster in eine Zeile. Bauen Sie die Willkommensmail und den 24-Stunden-Anstoß mit einer `send_if`-Prüfung und einem sauberen Austritt. Legen Sie von Tag eins an eine Kontrollgruppe von 5 bis 10 Prozent an. Den Beleg und den letzten Schritt lassen Sie weg, bis Sie zwei Wochen Daten haben. Die Hilfe-E-Mail gegen Blockaden ergänzen Sie, sobald Sie den häufigsten Fehler in Ihren Logs benennen können. Welches Fehlersignal in Ihrem Produkt würden Sie zuerst anbinden? ## FAQ ### Wie viele E-Mails sollte eine Onboarding E-Mail Serie haben? Vier bis sechs E-Mails über 7 bis 10 Tage sind der übliche Rahmen. Entscheidend sind aber eher die Auslöser als die Anzahl. Jede E-Mail nach der Willkommensmail sollte davon abhängen, was der Nutzer getan oder nicht getan hat, und die Serie sollte mit der Aktivierung enden. ### Worin unterscheidet sich ein Drip von einer Onboarding E-Mail Serie? Ein Drip läuft nach festem Zeitplan an alle. Eine Onboarding E-Mail Serie hängt an einem Aktivierungsereignis, prüft den Nutzerzustand vor jedem Versand und endet, wenn der Nutzer aktiviert, sich abmeldet oder das Konto verlässt. ### Wann sollte die erste Onboarding-E-Mail verschickt werden? Innerhalb von Sekunden nach der Anmeldung. Die Willkommensmail bestätigt das Konto und nennt eine erste Handlung. Schon eine Verzögerung von wenigen Minuten bedeutet, dass sich der Nutzer anderen Dingen zugewendet hat. ### Wie messen Sie, ob eine Onboarding E-Mail Serie funktioniert? Vergleichen Sie die Aktivierung nach 14 Tagen zwischen Nutzern, die die Serie erhalten haben, und einer kleinen Kontrollgruppe ohne Serie. Ergänzen Sie Click-to-activate je E-Mail und die Auslöse-Latenz. Die Öffnungsrate allein ist wegen des Vorladens durch Datenschutzfunktionen unzuverlässig. ### Sollten Onboarding-E-Mails transaktional oder Marketing-E-Mails sein? Beides kommt vor. E-Mails, die der Nutzer zum Weitermachen braucht, etwa eine Bestätigung oder ein API-Schlüssel, gehören in den transaktionalen Stream. Ermutigungen und Tipps gehören in den Lifecycle-Stream mit eigenem Abmeldebereich. ### Welche Daten brauchen Sie, um Onboarding-E-Mails verhaltensbasiert auszulösen? Einen Ereignisstrom mit Ihrem Aktivierungsereignis, einen Zustand pro Nutzer, der festhält, welche Ereignisse ausgelöst wurden, und eine Prüfung zum Versandzeitpunkt. Ereignisse können aus Segment, einem Backend-Webhook oder Postgres Change Data Capture stammen.