Bouw een reeks die proefgebruikers laat converteren op basis van wat ze in je product doen: activatie-event, één taak per e-mail, controles en uitstroomtests.
Een e-mail voor de conversie van proefgebruikers hoort in te spelen op wat de gebruiker heeft gedaan. Wie nog geen project heeft aangemaakt, heeft hulp bij het instellen nodig. Wie het product elke dag gebruikt, heeft een duidelijke uitleg over het betaalde abonnement nodig. Stuur je die twee mensen hetzelfde aftelbericht, dan mis je dat verschil.
Deze gids houdt het ontwerp van de reeks gescheiden van de logica in je applicatie die bepaalt wie welke e-mail krijgt.
Kies één actie waaruit blijkt dat de gebruiker het eerste nuttige resultaat in het product heeft bereikt. Maak die specifiek genoeg om in je backend vast te leggen: een aangemaakt project, een afgeronde import of een uitgenodigde teamgenoot. Een paginaweergave is op zichzelf zelden genoeg.
Leg het moment van aanmelding, het einde van de proefperiode, de activatie en de betaalstatus vast in het systeem dat eigenaar is van die feiten. Zie contactvelden in het e-mailplatform als gesynchroniseerde data, niet als bewijs dat een eerder gestarte flow de actuele status leest.
| Bericht | Wanneer het nuttig is | Voorwaarde op het verzendmoment |
|---|---|---|
| Welkom | Na aanmelding of verificatie | Het account bestaat en mag dit bericht ontvangen |
| Hulp bij het instellen | Ongeveer twee dagen later, afgestemd op je product | Nog niet geactiveerd |
| Volgende nuttige actie | Na activatie | Geactiveerd en die actie nog niet afgerond |
| Einde proefperiode | Vóór de echte einddatum van de proefperiode | De proefperiode loopt nog en het account is niet betaald |
| Laatste check-in | Na het einde van de proefperiode, als dat past | Nog niet betaald, komt in aanmerking en mag marketing ontvangen |
Deze timings zijn startpunten voor een test, geen gemeten best presterende tussenpozen. Noem de echte einddatum van de proefperiode en wat er daarna gebeurt. Verzin geen schaarste en suggereer geen afschrijving als er geen betaalmethode bekend is.
In een eventgestuurde flow in Brew leest payload.activated het oorspronkelijke event, terwijl contact.activated het actuele contactveld van de ontvanger in Brew leest op het moment dat een filterstap of een splitsing op basis van een voorwaarde wordt uitgevoerd. Wil je na de activatie geen herinneringen over het instellen meer sturen, definieer dan dat booleaanse veld, houd het gesynchroniseerd vanuit je product en controleer na elke relevante wachtstap contact.activated equals false. Een ontbrekende waarde is niet hetzelfde als false; test die apart.
Die voorwaarden lezen het opgeslagen contact in Brew, niet de database van je applicatie of een live verzoek aan Stripe. Een binnenkomend activatie- of betaalevent annuleert een eerdere run niet automatisch. De flow heeft een voorwaarde nodig vóór elke verzending die van de status afhangt.
Voor feiten buiten Brew laat je je applicatie een job inplannen. Is die aan de beurt, lees dan het actuele account of de actuele factuur en verstuur alleen een apart aangepast event naar Brew als de ontvanger nog in aanmerking komt. Neem in dat nieuwe event de actuele data op die je voor personalisatie nodig hebt.
Een herinnering die je applicatie inplant, werkt bijvoorbeeld zo:
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 dataGebruik de echte trigger-ID die Brew teruggeeft en het gedeclareerde schema van de trigger. Volg de handleiding voor het opzetten van automatiseringen en de documentatie over getypeerde payloadcontracten. Gebruik het gedocumenteerde idempotentiemechanisme voor events die je opnieuw verstuurt.
Beheert Stripe de proefperiode, dan leveren de abonnementsevents van Stripe de context over facturering. De Stripe-integratie biedt ondersteunde eventtriggers, waaronder customer.subscription.trial_will_end. Je applicatie blijft eigenaar van de activatie in het product, tenzij je die informatie apart doorstuurt.
Controleer voor een latere herinnering over een betaling het actuele record in Stripe. Een geslaagde update van de kaart bewijst niet dat een factuur is betaald. Stem af met de e-mails die Stripe zelf verstuurt, zodat de klant per doel één melding krijgt.
Begin bij de echte situatie van de ontvanger. Leg één nuttige actie uit en link er direct naartoe. Een e-mail over het instellen kan een kort voorbeeld en een antwoordadres bieden. Een e-mail over het betaalde abonnement beschrijft de relevante limiet of functie en de echte prijs, met een link naar de actuele prijzen.
Zorg dat de toestemming voor marketing, de afhandeling van afmeldingen en het doel van het domein passen bij het bericht. Een aanmelding voor een proefperiode rechtvaardigt geen promotionele e-mail die er niets mee te maken heeft.
Test wat er gebeurt als een contact activeert of betaalt vóór elke controle op wie in aanmerking komt. Werk bij contactvoorwaarden tijdens de wachttijd de betreffende velden in Brew bij en controleer of de herinnering wordt overgeslagen. Ga bij controles die je applicatie inplant na of accounts die niet in aanmerking komen geen herinneringsevent opleveren. Test ook nieuwe pogingen, verlengde proefperiodes, verwijderde accounts, afmeldingen en ontbrekende velden. Bekijk zowel de logs van je applicatie als de uitvoeringsgeschiedenis in Brew.
Beoordeel activatie en conversie naar een betaald abonnement met je productdata, en bezorgfouten met het e-mailplatform. Openratio’s alleen laten niet zien of de reeks een proefgebruiker heeft geholpen. Zie het ontwerp van welkomstreeksen voor voorbeelden en MCP versus REST voor de taakverdeling in de implementatie.
