Zamieniaj e-maile w przychody dzięki Brew.
Zbuduj sekwencję konwersji okresu próbnego opartą na działaniach w produkcie: zdarzenie aktywacji, jedno zadanie na e-mail, sprawdzanie warunków i testy wyjść.
E-mail, który ma zamienić okres próbny w płatny plan, powinien reagować na to, co użytkownik już zrobił. Ktoś, kto nie utworzył jeszcze projektu, potrzebuje pomocy w konfiguracji. Ktoś, kto korzysta z produktu codziennie, potrzebuje jasnego wyjaśnienia, co daje płatny plan. Jeśli obie osoby dostaną to samo odliczanie, ta różnica przepada.
Ten poradnik oddziela projekt sekwencji od logiki aplikacji, która decyduje, kto powinien dostać każdy e-mail.
Wybierz jedno działanie, które pokazuje, że użytkownik osiągnął w produkcie pierwszy przydatny efekt. Niech będzie na tyle konkretne, żeby Twój backend mógł je zarejestrować: utworzenie projektu, zakończenie importu albo zaproszenie członka zespołu. Samo wyświetlenie strony rzadko wystarcza.
Czas rejestracji, koniec okresu próbnego, aktywację i status płatności zapisuj w systemie, do którego te informacje należą. Pola kontaktu na platformie e-mailowej traktuj jako dane synchronizowane, a nie jako dowód, że wcześniej uruchomiona sekwencja odczytuje aktualny stan.
| Wiadomość | Kiedy się przydaje | Warunek sprawdzany w chwili wysyłki |
|---|---|---|
| Powitanie | Po rejestracji lub weryfikacji | Konto istnieje i może otrzymać tę wiadomość |
| Pomoc w konfiguracji | Około dwóch dni później, zależnie od produktu | Brak aktywacji |
| Kolejne przydatne działanie | Po aktywacji | Konto aktywowane, a to działanie jeszcze niewykonane |
| Koniec okresu próbnego | Przed faktycznym końcem okresu próbnego | Okres próbny nadal trwa, a konto nie jest opłacone |
| Ostatnie pytanie o postępy | Po zakończeniu okresu próbnego, jeśli to stosowne | Nadal bez płatności, spełnia warunki i ma zgodę na komunikację marketingową |
Te terminy to punkty wyjścia do testów, a nie zmierzone, najskuteczniejsze odstępy. Podawaj faktyczny termin końca okresu próbnego i to, co stanie się potem. Nie wymyślaj sztucznego niedoboru i nie sugeruj, że karta zostanie obciążona, jeśli w systemie nie ma żadnej metody płatności.
W sekwencji Brew uruchamianej zdarzeniem payload.activated odczytuje pierwotne zdarzenie, a contact.activated – bieżące pole kontaktu odbiorcy w Brew w chwili wykonania kroku filtra lub kroku podziału warunkowego. Aby pomijać przypomnienia o konfiguracji po aktywacji, zadeklaruj to pole typu prawda/fałsz, synchronizuj je ze swoim produktem i po każdym istotnym kroku „Czekaj” sprawdzaj contact.activated equals false. Brak wartości to nie to samo co false, więc przetestuj ten przypadek osobno.
Te odczyty korzystają z kontaktu zapisanego w Brew, a nie z bazy danych Twojej aplikacji ani z bieżącego zapytania do Stripe. Odebranie zdarzenia aktywacji lub płatności nie anuluje automatycznie wcześniejszego uruchomienia. Przed każdą wysyłką, która zależy od stanu, schemat potrzebuje warunku.
W przypadku danych spoza Brew niech Twoja aplikacja zaplanuje zadanie. Gdy nadejdzie jego pora, odczytaj bieżący stan konta lub faktury i wywołaj osobne własne zdarzenie Brew tylko wtedy, gdy odbiorca nadal spełnia warunki. W nowym zdarzeniu przekaż aktualne dane potrzebne do personalizacji.
Przypomnienie planowane przez aplikację działa na przykład tak: po zapisaniu rejestracji aplikacja wywołuje zdarzenie powitalne, a gdy nadejdzie pora przypomnienia, odczytuje bieżący stan konta. Jeśli konto jest już aktywowane lub opłacone, kończy pracę bez wywoływania zdarzenia e-mailowego. Jeśli nadal spełnia warunki, wywołuje zdarzenie przypomnienia o konfiguracji z aktualnymi danymi:
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 dataUżywaj rzeczywistego identyfikatora wyzwalacza zwróconego przez Brew i zadeklarowanego schematu danych wyzwalacza. Postępuj zgodnie z instrukcją konfiguracji automatyzacji i dokumentacją typowanych schematów danych zdarzeń. Przy ponawianych wywołaniach zdarzeń korzystaj z opisanego w dokumentacji mechanizmu idempotentności.
Jeśli okresem próbnym zarządza Stripe, jego zdarzenia subskrypcji dostarczają kontekstu rozliczeniowego. Integracja ze Stripe udostępnia obsługiwane wyzwalacze zdarzeń, w tym customer.subscription.trial_will_end. Za aktywację w produkcie nadal odpowiada Twoja aplikacja, chyba że przekazujesz tę informację osobno.
Przed późniejszym przypomnieniem dotyczącym płatności sprawdź bieżący rekord w Stripe. Udana aktualizacja karty nie dowodzi, że faktura została opłacona. Zgraj swoje wiadomości z e-mailami, które wysyła Stripe, żeby klient dostał jedno powiadomienie w każdej sprawie.
Zacznij od faktycznej sytuacji odbiorcy. Wyjaśnij jedno przydatne działanie i podlinkuj bezpośrednio do niego. E-mail o konfiguracji może zawierać krótki przykład i adres do odpowiedzi. E-mail o płatnym planie powinien opisywać odpowiedni limit lub funkcję oraz rzeczywistą cenę, z linkiem do aktualnego cennika.
Zgoda marketingowa, obsługa wypisań i przeznaczenie domeny muszą pasować do wiadomości. Rejestracja na okres próbny nie uzasadnia niezwiązanych z nią e-maili promocyjnych.
Przetestuj, co się dzieje, gdy kontakt aktywuje konto lub zapłaci przed każdym sprawdzeniem warunków. W przypadku warunków dotyczących kontaktu zaktualizuj odpowiednie pola w Brew w trakcie oczekiwania i sprawdź, czy przypomnienie zostanie pominięte. W przypadku sprawdzeń planowanych przez aplikację upewnij się, że konta niespełniające warunków nie generują zdarzenia przypomnienia. Przetestuj też ponowienia, przedłużenia okresu próbnego, usunięcie konta, wypisania i brakujące pola. Sprawdź zarówno logi aplikacji, jak i historię uruchomień w Brew.
Aktywację i konwersję na płatny plan oceniaj na podstawie danych z produktu, a nieudane dostarczenia – na podstawie danych z platformy e-mailowej. Sam wskaźnik otwarć nie pokaże, czy sekwencja pomogła użytkownikowi w okresie próbnym. Przykłady znajdziesz w poradniku o projektowaniu sekwencji powitalnej, a podział pracy przy wdrożeniu opisuje wpis MCP kontra REST.
